Internet Engineering Task Force SIP WG
Internet Draft S.Donovan
dynamicsoft
J.Rosenberg
dynamicsoft
draft-ietf-sip-session-timer-09.txt
July 1, 2002
Expires: January 2003
Session Initiation Protocol Extension for Session Timer
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
This document defines an extension to the Session Initiation Protocol
(SIP). This extension allows for a periodic refresh of SIP sessions
through a re-INVITE or UPDATE request. The refresh allows both user
agents and proxies to determine if the SIP session is still active.
The extension defines two new header fields, Session-Expires, which
conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer.
S.Donovan et. al. [Page 1]
Internet Draft Session Timer July 1, 2002
S.Donovan et. al. [Page 2]
Internet Draft Session Timer July 1, 2002
1 Introduction
The Session Initiation Protocol (SIP) [1], does not define a
keepalive mechanism for the sessions it establishes. Although the
user agents may be able to determine if the session has timed out
using session specific mechanisms, proxies will not be able to do so.
The result is that call stateful proxies will not always be able to
determine whether a session is still active or not. For instance,
when a user agent fails to send a BYE message at the end of a
session, or the BYE message gets lost due to network problems, a call
stateful proxy will not know when the session has ended. In this
situation, the call stateful proxy will retain state for the call and
has no deterministic method of determining when the call state
information no longer applies.
To resolve this problem, this extension defines a keepalive mechanism
for SIP sessions. UAs send periodic re-INVITE or UPDATE [2] requests
(referred to as session refresh requests) to keep the session alive.
The interval for the session refresh requests is determined through a
negotiation mechanism defined here. If a session refresh request is
not received before the interval passes, the session is considered
terminated. Both UAs are supposed to send a BYE, and call stateful
proxies can remove any state for the call.
This refresh mechanism has additional applications. For the same
reasons a call stateful proxy server would like to determine whether
the session is still active, a user agent would like to make this
determination. This determination can be made at a user agent without
the use of SIP level mechanisms; for audio sessions, periodic RTCP
packets serve as an indication of liveness [5]. However, it is
desirable to separate SIP session liveness from the details of the
particular session.
Another application of the session timer is in the construction of a
SIP Network Address Translator (NAT) Application Level Gateway (ALG)
[6]. The ALG embedded in a NAT will need to maintain state for the
duration of a call. This state must eventually be removed. Relying on
a BYE to trigger the removal of state, besides being unreliable,
introduces a potential denial of service attack.
This document proposes an extension to SIP that defines a session
expiration mechanism. Periodic refreshes, through re-INVITEs or
UPDATEs, are used to keep the session active. The extension is
sufficiently backwards compatible with SIP that it works so long as
either one of the two participants in a dialog understand the
extension. Two new header fields, Session-Expires and Min-SE, and a
new response code, 422, are defined. Session-Expires conveys the
duration of the session, and Min-SE conveys the minimum allowed value
S.Donovan et. al. [Page 3]
Internet Draft Session Timer July 1, 2002
for the session expiration. The 422 response code indicates that the
session timer duration was too small.
2 Terminology
In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant SIP implementations.
Additionally, we define the following terms:
Session Interval: The largest amount of time that can occur
between session refresh requests in a dialog before the
session will be considered timed out. The session interval
is conveyed in the Session-Expires header field defined
here. The UAS obtains this value from the Session-Expires
header field in a 2xx response to a session refresh request
that it sends. Proxies and UACs determine this value from
the Session-Expires header field in a 2xx response to a
session refresh request that they receive.
Minimum Timer: Because of the processing load of mid-dialog
requests, all elements (proxy, UAC, UAS) can have a
configured minimum value for the session interval that they
are willing to accept. This value is called the minimum
timer.
Session Expiration: The time at which an element will consider
the session timed out, if no successful session refresh
transaction occurs beforehand.
Session Refresh Request: An INVITE or UPDATE request within a
dialog. If the request generates a 2xx response, the
session expiration is increased to the current time plus
the session interval obtained from the response. A session
refresh request is not to be confused with a target refresh
request, defined in Section 6 of [1], which is a request
that can update the remote target of a dialog.
Refresh: Same as a session refresh request.
3 Overview of Operation
This section provides a brief overview of operation of the extension.
It is tutorial in nature and should not be considered as normative.
Session refreshes are accomplished using SIP INVITE or UPDATE [2]
S.Donovan et. al. [Page 4]
Internet Draft Session Timer July 1, 2002
requests. The initial session refresh request establishes the
duration of the session, which is carried in the Session-Expires
header field in the 2xx response to the session refresh request. The
Session-Expires header field in the 2xx response also indicates which
side will be responsible for generating these refreshes - the UAC or
the UAS. The responsible side generates a refresh (using a re-INVITE
or UPDATE) before the session expires. If the refresher never gets a
response to that session refresh request, it sends a BYE to terminate
the session. Similarly, if the other side never gets the session
refresh request before the session expires, it sends a BYE. All
session refresh requests are processed identically to the initial
session refresh request, so that the 2xx response to a session
refresh request carries the new time at which the session will
expire.
It is an explicit goal of this extension to operate so long as one of
the two UAs in a dialog support the extension. That side, of course,
ends up performing the refreshes. The other side will merely see them
as repetitive re-INVITE or UPDATE requests. This facilitates
interoperability.
The extension supports negotiation of a reasonable value for the
session interval, and negotiation of which side of the dialog is
performing the refreshes. Negotiation of the session interval is
critical. The value must be small enough to provide a useful
expiration, but not so small to overload the proxies with messages.
The goal of the negotiation algorithm is to choose a session interval
that is the smallest of all the values requested by all elements on
the dialog path, but only if that value is larger than the largest
minimum timer requested by all elements. Negotiation of the refresher
role is simpler. If only one side supports the extension, that side
acts as refresher. Otherwise, one side chooses who will refresh. This
negotiation takes place as part of session refresh request
processing, and due to the idempotency of that processing, is redone
each time the session is refreshed.
To negotiate the value of the refresh interval, the Min-SE and
Session-Expires header fields are used. The UAC generates a session
refresh request, and includes a Session-Expires header field if it
wishes to use the session timer. The Session-Expires header field
value contains the session interval. As the session refresh request
traverses proxies, the proxies (and the UAS) can reduce the value of
the session interval, but not lower than the value of the Min-SE
header field. If a proxy or UAS receives a request with a Session-
Expires header field value lower than a configured minimum, it can
reject the request with a 422 response. This response contains a
Min-SE header field with the minimum allowed value. The client
retries the request, inserting a Min-SE header field containing the
S.Donovan et. al. [Page 5]
Internet Draft Session Timer July 1, 2002
maximum value of the Min-SE header fields returned in previous 422
responses for the call. In the case where the UAC isn't aware of the
session timer extension, a proxy that receives a session refresh
request with a Session-Expires lower than the configured minimum
places the Min-SE header field in the proxied request, and increases
the Session-Expires header field value to that minimum. When the
request eventually reaches the UAS (potentially after a few retries
resulting from a 422), it will contain a Session-Expires header field
whose value meets the design criteria described above. The UAS
returns a 200 OK with a Session-Expires header field containing that
value. The header field also contains a parameter, called refresher,
that indicates which side is performing the refreshes.
When only the UAC supports the session timer extension, one of the
proxies "fills the shoes" of the UAS. Specifically, when the UAS does
support session timer, it places the value of the session interval
into the Session-Expires header field in the 2xx response. When the
UAS doesn't support it, the proxy closest to the UAS that asked for a
session expiration performs that job, and inserts the value of the
session interval into the 2xx response as it passes by.
It is worth noting that the session timer refreshes the session, not
the dialog used to establish the session. Of course, the two are
related. If the session expires, a BYE is sent, which terminates the
session and generally, the dialog.
4 Session-Expires Header Field Definition
The Session-Expires header field conveys the session interval for a
SIP session. It is placed only in INVITE or UPDATE requests, and is
allowed in any 2xx response to an INVITE or UPDATE. Like the SIP
Expires header field, it contains a delta-time.
There is no absolute minimum value for the Session-Expires header
field. However, 1800 seconds (30 minutes) is RECOMMENDED. In other
words, SIP entites MUST be prepared to handle Session-Expires header
field values of any duration, but entities that insert the Session-
Expires header field SHOULD NOT choose values less than 30 minutes.
Small session intervals can be destructive to the network. They cause
excessive messaging traffic that affects both user agents and proxy
servers. They increase the possibility of "glare" which can occur
when both user agents send a re-INVITE or UPDATE at the same time.
Since the primary purpose of the session timer is to provide a means
to time out state in SIP elements, very small values won't generally
be needed. 30 minutes was chosen since 95% of phone calls are less
than this duration. However, the 30 minute minimum is listed as a
SHOULD, and not a MUST, since the exact value for this number is
S.Donovan et. al. [Page 6]
Internet Draft Session Timer July 1, 2002
dependent on many network factors, including network bandwidths and
latencies, computing power, memory availability, network topology,
and of course, the application scenario. After all, SIP can set up
any kind of session, not just a phone call. At the time of
publication of this document, 30 minutes seems appropriate. Advances
in technologies may result in the number being excessively large five
years in the future.
The default value of the Session-Expires header field, when not
present, is infinity. This means that absence of the Session-Expires
header field implies no expiration.
The syntax of the Session-Expires header field is:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
Note that a compact form, the letter x, has been reserved for
Session-Expires. The BNF for delta-seconds and generic-param is
defined in Section 25 of RFC 3261 [1].
Table 1 is an extension of Tables 2 and 3 in [1] for the Session-
Expires and Min-SE header fields. The column "PRA" is for the PRACK
method [7], "UPD" is for the UPDATE method [2], "SUB" is for the
SUBSCRIBE method [8], and "NOT" is for the NOTIFY method [8].
Header field where proxy ACK BYE CAN INV OPT REG PRA UPD SUB NOT
_____________________________________________________________________
Session-Expires R amr - - - o - - - o - -
Session-Expires 2xx ar - - - o - - - o - -
Min-SE R amr - - - o - - - o - -
Min-SE 422 - - - m - - - m - -
Table 1: Session-Expires and Min-SE Header Fields
5 Min-SE Header Field Definition
The Min-SE header field indicates the minimum value for the session
interval, in units of delta-seconds. When used in an INVITE or UPDATE
request, it indicates the smallest value of the session interval
which can be used for that session.
S.Donovan et. al. [Page 7]
Internet Draft Session Timer July 1, 2002
When not present, the default value for this header field is zero.
The Min-SE header field MUSTNOT be used in responses except those
with a 422 response code. It indicates the minimum value of the
session interval that the server is willing to accept.
The syntax of the Min-SE header field is:
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
6 422 Response Code Definition
This extension introduces the 422 (Session Interval Too Small)
response code. It is generated by a UAS or proxy when a request
contains a Session-Expires header field with a duration that is below
the minimum timer for the server. The 422 response MUST contain a
Min-SE header field with the minimum timer for that server.
7 UAC Behavior
7.1 Generating a Session Refresh Request
A UAC which supports the session timer extension defined here MUST
include a Supported header field in each request (except ACK),
listing the option tag "timer" [1]. It MUST do so even if the UAC is
not requesting usage of the session timer for this session.
The UAC MAY include a Require header field in the request with the
value "timer" to indicate that the UAS must support the session timer
to participate in the session. This does not mean that the UAC is
requiring the UAS to perform the refreshes, just that it is requiring
the UAS to support the extension. In addition, the UAC MAY include a
Proxy-Require header field in the request with the value "timer" to
indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the
extension. The Supported header field containing "timer" MUST still
be included even if the Require or Proxy-Require header fields are
present containing "timer".
The UAC MUST insert the Min-SE header field into a session refresh
request for a particular dialog if it has ever received a 422
response to a previous session refresh request on the same dialog, or
if it has received a session refresh request on that dialog which
S.Donovan et. al. [Page 8]
Internet Draft Session Timer July 1, 2002
contained a Min-SE header field. Similarly, if no dialog has been
established yet, a UAC MUST insert the Min-SE header field into an
INVITE request if it has ever received a 422 response to a previous
INVITE request with the same Call-ID.
The value of the Min-SE header field present in a session refresh
request MUST be the largest value amongst all Min-SE header field
values returned in all 422 responses, or received in session refresh
requests, on the same dialog, if a dialog has been established. If no
dialog has been established, the Min-SE header field value is set to
the largest value amongst all Min-SE header field values returned in
all 422 responses for an INVITE request with the same Call-ID. A
result of this rule is that the maximum value of the Min-SE is
effectively "cleared" once the dialog is established, and from that
point on, only the values from proxies known to be on the proxy path
will end up being used.
The UAC may have its own opinions about the minimum session interval.
In that case, if the value above is too small, the UAC MAY increase
it.
A UAC MAY include the Min-SE header field in an INVITE request
outside of a dialog, even if it never received a 422 previously.
A UAC MAY include a Session-Expires in an initial session refresh
request request if it wishes for a session timer to be applied to the
session. The value of this header field indicates the session
interval desired by the UAC. In a session refresh request sent within
a dialog with an active session timer, the header field SHOULD be
present. When present, it MUST be equal to the maximum of the Min-SE
header field (recall that its default value when not present is zero)
and the current session interval.
In an initial session refresh request, the UAC MAY include the
refresher parameter with value "uac" if it wishes to perform the
refreshes. However, it is RECOMMENDED that the parameter be omitted,
so that it can be selected by the negotiation mechanisms described
below. If the session refresh request is not the initial one, it is
RECOMMENDED that the refresher parameter be set to "uac" if the
element sending the request is currently performing refreshes, else
"uas" if its peer is performing the refreshes. This way, the role of
refresher does not change on each refresh. However, if it wishes to
explicitly change the roles, it MAY use a value of "uas" if it knows
that the other side supports session timer. It could know this by
having received a request from its peer with a Supported header field
containing the value "timer". If it wishes to reselect the roles, it
MAY omit the parameter.
S.Donovan et. al. [Page 9]
Internet Draft Session Timer July 1, 2002
A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE. If a
UAC knows that its peer supports the UPDATE method, it is RECOMMENDED
that UPDATE be used instead of a re-INVITE. A UA can make this
determination if it has seen an Allow header field from its peer with
the value "UPDATE", or through a mid-dialog OPTIONS request. It is
RECOMMENDED that the UPDATE request not contain an offer [4], but a
re-INVITE SHOULD contain one, even if the details of the session have
not changed. In that case, the offer MUST indicate that it has not
changed. In the case of SDP, this is accomplished by including the
same value for the origin field as previous SDP messages to its peer.
The same is true for an answer exchanged as a result of a session
refresh request; if it has not changed, that MUST be indicated.
7.2 Processing a 2xx Response
Session timer requires a UA to create and maintain state. This state
includes the session interval, the session expiration, and the
identity of the refresher. This state is associated with the dialog
on which the session has been negotiated.
When a 2xx response to a session refresh request arrives, it may or
may not contain a Require header field with the value "timer". If it
does, the UAC MUST look for the Session-Expires header field to
process the response.
If there was a Require header field in the response with the value
"timer", the Session-Expires header field will always be present.
UACs MUST be prepared to receive a Session-Expires header field in a
response even if none were present in the request. The "refresher"
parameter will be present in the Session-Expires header field,
indicating who will be performing the refreshes. The UAC MUST set the
identity of the refresher to the value of this parameter. If the
parameter contains the value "uac", the UAC will perform them. It is
possible that the UAC requested session timer (and thus included a
Session-Expires header field in the request), but there was no
Require or Session-Expires header field in the 2xx response. This
will happen when the UAS doesn't support the session timer extension,
and only the UAC has asked for a session timer (no proxies have
requested it). In this case, if the UAC still wishes to use the
session timer (they are purely for its benefit alone), it has to
perform them. To do this, the UAC follows the procedures defined in
this specification as if the Session-Expires header field were in the
2xx response, and its value was the same as the one in the request,
but with a refresher parameter of "uac".
If the 2xx response did not contain a Session-Expires header field,
there is no session expiration. In this case, no refreshes need to be
S.Donovan et. al. [Page 10]
Internet Draft Session Timer July 1, 2002
sent. A 2xx without a Session-Expires can come for both initial and
mid-dialog session refresh requests.
The UAC remembers the session interval for a session as the value of
the delta-time from the Session-Expires header field in the most
recent 2xx response to a session refresh request on a dialog. It is
explicitly allowed for there to be differing session intervals (or
none at all) on differing dialogs established as a result of a single
INVITE. It also remembers whether it, or its peer, is the refresher
on for the session.
If the UAC must perform the refreshes, it computes the session
expiration for that session. The session expiration is the time of
reception of the last 2xx response to a session refresh request on
that dialog plus the session interval for that session. If UA wishes
to continue with the session beyond the session expiration, it MUST
generate a refresh before the session expiration. It is RECOMMENDED
that this refresh be sent once half the session interval has elapsed.
Additional procedures for this refresh are described in Section 10.
7.3 Processing a 422 Response
If the response to a session refresh request is a 422 (Session
Interval Too Small) response message, then the UAC MAY retry the
request. The procedures for retrying are described in Section 7.1.
8 Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers.
However, a stateful proxy server MAY also follow the rules described
here. Stateless proxies MUST NOT attempt to request session timers.
Proxies which ask for session timers SHOULD record-route, since they
won't receive refreshes if they don't.
The proxy processing rules require the proxy to remember
information between the request and response, ruling out
stateless proxies.
8.1 Processing of Requests
Processing of requests is identical for all session refresh requests.
To request a session timer for a session, a proxy makes sure that a
Session-Expires header field is present in a session refresh request
for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it, if none was present in the
request. This Session-Expires header field may contain any desired
S.Donovan et. al. [Page 11]
Internet Draft Session Timer July 1, 2002
expiration time the proxy would like, but not with a duration lower
than the value in the Min-SE header field in the request, if present.
The proxy MUST NOT include a refresher parameter in the header field
value.
If the request already had a Session-Expires header field, the proxy
MAY reduce its value, but MUST NOT set it to a duration lower than
the value in the Min-SE header field in the request, if present. If
the value of the Session-Expires header field is greater than or
equal to the value in the Min-SE header field (recall that the
default is zero when the Min-SE header field is not present), the
proxy MUST NOT increase the value of the Session-Expires header
field. If the value of the Session-Expires header field is lower than
the value of the Min-SE header field (possibly because the proxy
increased the value of the Min-SE header field, as described below),
the proxy MUST increase the value of the Session-Expires header field
to make it equal to Min-SE header field value. The proxy MUST NOT
insert or modify the value of the "refresher" parameter in the
Session-Expires header field.
If the request contains a Supported header field with a value
"timer", the proxy MAY reject the INVITE request with a 422 (Session
Interval Too Small) response if the session interval in the Session-
Expires header field is smaller than the minimum interval defined by
the proxy's local policy. When sending the 422 response, the proxy
MUST include a Min-SE header field with the value of its minimum
interval.
If the request doesn't indicate support for session timer, but the
request contains a session interval that is too small, the proxy
cannot usefully reject the request, as this would result in a call
failure. Rather, the proxy SHOULD insert a Min-SE header field
containing its minimum interval. If a Min-SE header field is already
present, the proxy SHOULD increase (but MUST NOT decrease) the value
to equal its minimum interval. The proxy MUST then increase the
Session-Expires header field value to be equal to the value in the
Min-SE header field, as described above. A proxy MUST NOT insert a
Min-SE header field, or modify the value of an existing header field,
in a proxied request if that request contains a Supported header
field with the value "timer". This is needed to protect against
certain denial of service attacks, described in Section 11.
Assuming the proxy has requested a session timer (and thus has
possibly inserted the Session-Expires header field or reduced it),
the proxy MUST remember that it is using a session timer, and also
remember the value of the Session-Expires header field from the
proxied request. This MUST be remembered for the duration of the
transaction. The proxy MUST remember, for the duration of the
S.Donovan et. al. [Page 12]
Internet Draft Session Timer July 1, 2002
transaction, whether the request contained the Supported header field
with the value "timer".
If the request did not contain a Supported header field with the
value "timer", the proxy MAY insert a Require header field into the
request, with the value "timer". However, this is NOT RECOMMENDED.
This allows the proxy to insist on session timer for the session.
This header field is not needed if a Supported header field was in
the request; in this case, the proxy can already be sure that the
session timer can be used for the session.
8.2 Processing of Responses
When the final response to the request arrives, it is examined by the
proxy.
If the response does not contain a Session-Expires header field, but
the proxy remembers that it requested a session timer in the request
(by inserting, modifying, or examining and accepting the Session-
Expires header field in the proxied request), this means that the UAS
did not support the session timer. If the proxy remembers that the
UAC did not support session timer either, the proxy forwards the
response upstream normally. There is no session expiration for this
session. If, however, the proxy remembers that the UAC did support
session timer, additional processing is needed.
Because there is no Session-Expires or Require header field in the
response, the proxy knows it is the first session-timer-aware proxy
to receive the response. This proxy MUST insert a Session-Expires
header field into the response with the value it remembered from the
forwarded request. It MUST set the value of the "refresher" parameter
to "uac". The proxy MUST insert the Require header field into the
response, with the value "timer", before forwarding it upstream.
If the received response contains a Session-Expires header field, no
modification of the response is needed.
In all cases, if the 2xx response forwarded upstream by the proxy
contains a Session-Expires header field, its value represents the
session interval for the session associated with that response. The
proxy computes the session expiration as the time when the 2xx
response is forwarded upstream, plus the session interval. This
session expiration MUST update any existing session expiration for
the session. The refresher parameter in the Session-Expires header
field in the 2xx response forwarded upstream will be present, and it
indicates which UA is performing the refreshes. There can be multiple
2xx responses to a single INVITE, each representing a different
dialog, resulting in multiple session expirations, one for each
S.Donovan et. al. [Page 13]
Internet Draft Session Timer July 1, 2002
session associated with each dialog.
The proxy MUST NOT modify the value of the Session-Expires header
field received in the response (assuming one was present) before
forwarding it upstream.
8.3 Session Expiration
When the current time equals or passes the session expiration for a
session, the proxy MAY remove associated call state, and MAY free any
resources associated with the call. Unlike the UA, it MUST NOT send a
BYE.
9 UAS Behavior
When a UAS receives a session refresh request, the processing of that
request can logically be broken into two steps. In the first step,
the UAS acts as a "virtual proxy", and follows the rules specified in
Section 8.1 as if it were a proxy. This means that the same session
timer manipulations that a proxy can do, can also be done by a UAS.
Specifically, this means that it can insert or reduce the session
interval (but not below Min-SE header field value, if present),
reject the request with a 422, and insert/increase the Min-SE header
field value, just as a proxy can. Of course, rather than proxying the
request, the "modified" request is passed into the second step of
processing, which we call the "virtual UAS" processing. Viewing the
UAS as the concatenation of a proxy and a UAS-specific processing
component simplifies the specification of behavior and guarantees
consistency. This separation is for the purposes of defining
behavior. It does not mandate that the implementation work this way.
Once the request is received by the virtual UAS (assuming it is
received; it may have been rejected with a 422 based on the rules in
Section 8.1), virtual UAS processing begins. From this point forward,
the term "UAS" refers to the "virtual UAS". If the UAS wishes to
accept request, it copies the value of the Session-Expires header
field from the request into the 2xx response. Of course, this request
refers to the one received from the "virtual proxy".
The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response. This value
specifies who will perform refreshes for the dialog. The value is
based on the value of this parameter in the request, and on whether
the UAC supports the session timer extension. The UAC supports the
extension if the "timer" option tag was present in a Supported header
field in the request. Table 2 defines how the value in the response
is set. A value of 'none' in the 2nd column means that there was no
refresher parameter in the request. A value of 'NA' in the third
S.Donovan et. al. [Page 14]
Internet Draft Session Timer July 1, 2002
column means that this particular combination shouldn't happen, as
it's disallowed by the protocol.
UAC supports? refresher parameter refresher parameter
in request in response
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
Table 2: UAS Behavior
The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and the UAC did not select who
will perform refreshes. This allows the UAS to decide whether it, or
the UAC, will perform the refreshes. However, as the table indicates,
the UAS cannot overried the UAC's choice of refresher, if it made
one.
If the refresher parameter in the Session-Expires header field in the
2xx response has a value of "uac", the UAS MUST place a Require
header field into the response with the value "timer". This is
because the uac is performing refreshes and the response has to be
processed for the UAC to know this. If the refresher parameter in the
2xx response has a value of "uas", and the Supported header field in
the request contained the value "timer", the UAS SHOULD place a
Require header field into the response with the value "timer". In
this case, the UAC is not refreshing, but it is supposed to send a
BYE if it never receives a refresh. Since the call will still succeed
without the UAC doing this, insertion of the Require is a SHOULD
here, rather than a MUST.
The UAS, just like the UAC, stores state for the session timer. This
state includes the session interval, the session expiration, and the
identity of the refresher. This state is bound to the dialog used to
set up the session. The session interval is set to the value of the
delta-time from the Session-Expires header field in the most recent
2xx response to a session refresh request on that dialog. It also
remembers whether it, or its peer, is the refresher on the leg, based
on the value of the refresher parameter from the most recent 2xx
response to a session refresh request on that dialog. If the most
recent 2xx response had no Session-Expires header field, there is no
session expiration, and no refreshes need to be performed.
S.Donovan et. al. [Page 15]
Internet Draft Session Timer July 1, 2002
If the UAS must refresh the session, it computes the session
expiration. The session expiration is the time of transmission of the
last 2xx response to a session refresh request on that dialog plus
the session interval. If UA wishes to continue with the session
beyond the session expiration, it MUST generate a refresh before the
session expiration. It is RECOMMENDED that this refresh be sent once
half the session interval has elapsed. Additional procedures for this
refresh are described in Section 10.
10 Performing Refreshes
The side generating a refresh does so according to the UAC procedures
defined in Section 7. Note that only a 2xx response to a session
refresh request extends the session expiration. This means that a UA
could attempt a refresh, and receive a 422 response with a Min-SE
header field that contains a value much larger than the current
session interval. The UA will still need to send an session refresh
request before the session expiration (which has not changed), even
though this request will contain a value of the Session-Expires that
is much larger than the current session interval.
If no 2xx response to a session refresh request is received before
the session expiration, the UA SHOULD send a BYE request to terminate
the session. It SHOULD send this BYE slightly before session
expiration. The minimum of ten seconds and one third the session
interval is RECOMMENDED.
For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires.
Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, they SHOULD
send a BYE to terminate the session, slightly before the session
expiration. The minimum of ten seconds and one third the session
interval is RECOMMENDED.
Firewalls and NAT ALGs may be very unforgiving about
allowing SIP traffic to pass after the expiration time of
the session. It is for this reason that the BYE should be
sent before the expiration.
11 Security Considerations
The session timer introduces the capability of a proxy or UA element
S.Donovan et. al. [Page 16]
Internet Draft Session Timer July 1, 2002
to force compliant UAs to send refreshes at a rate of the element's
choosing. This introduces the possibility of denial-of-service
attacks with significant amplification properties. These attacks can
be launched from "outsiders" - elements which attempt to modify
messages in transit, or by "insiders" - elements which are
legitimately in the request path, but are intent on doing harm.
Fortunately, both cases are adequately handled by this specification.
11.1 Inside Attacks
This introduces the possibility of rogue proxies or UAs introducing
denial-of-service attacks. However, the mechanisms in this
specification prevent that from happening.
First, consider the case of a rogue UAC that wishes to force a UAS to
generate refreshes at a rapid rate. To do so, it inserts a Session-
Expires header field into an INVITE with a low duration and a
refresher parameter equal to uas. Assume it places a Supported header
field into the request. Any proxy, or the UAS, which objects to this
low timer will reject the request with a 422, therefore preventing
the attack. If no Supported header field was present, the proxies
will insert a Min-SE header field into the request before forwarding
it. As a result, the UAS will not choose a session timer lower than
the minimum acceptable one to all elements on the path. This too
prevents the attack.
Next, consider the case of a rogue UAS that wishes to force a UAC to
generate refreshes at a rapid rate. In that case, the UAC has to
support session timer. The initial INVITE arrives at the rogue UAS,
which returns a 2xx with a very small session interval. The UAC uses
this timer, and quickly sends a refresh. Section 7.1 requires the UAC
to copy the current session interval into the Session-Expires header
field in the request. This enables the proxies to see the current
value. The proxies will reject this request, and provide a Min-SE
with a higher minimum. The UAC will then use this higher minimum.
Note, that if the proxies did not reject the request, but rather
proxied the request with a Min-SE header field, an attack would still
be possible. The UAS could discard this header field in a 2xx
response, and force the UAC to continue to generate rapid requests.
In a similar fashion, a rogue proxy cannot force either the UAC or
UAS to generate refreshes unless the proxy remains on the signaling
path, and sees every request and response.
11.2 Outside Attacks
An element that can observe and modify a request or response in
transit can force rapid session refreshes. To prevent that, requests
S.Donovan et. al. [Page 17]
Internet Draft Session Timer July 1, 2002
and responses need to be protected by message integrity. Since the
session timer headers are not end-to-end, and are manipulated by
proxies, the SIP S/MIME capabilities are not suitable for this task.
Rather, integrity needs to be protected using hop-by-hop mechanisms.
As a result, it is RECOMMENDED that an element which sends a request
with a Session-Expires header field, or a Supported header field with
the value "timer", do so using IPSec or TLS. Since adequate
protection is obtained only if TLS or IPSec is applied on each hop,
it is RECOMMENDED that the SIPS URI scheme be used in conjunction
with this extension. This means that proxies which record-route and
request session timer, SHOULD record-route with a SIPS URI. A UA
which inserts a Session-Expires header into a request or response
SHOULD include a Contact URI thats a SIPS URI.
12 IANA Considerations
This extension defines two new header fields, a new response code,
and a new option tag. SIP [1] defines IANA procedures for registering
these.
12.1 IANA Registration of Min-SE and Session-Expires Header Fields
The following is the registration for the Min-SE header field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Name: Min-SE
Compact Form: none
The following is the registration for the Session-Expires header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Name: Session-Expires
Compact Form: x
12.2 IANA Registration of the 422 (Session Interval Too Small) Response
Code
The following is the registration for the 422 (Session Interval Too
Small) response code:
Response Code: 422
S.Donovan et. al. [Page 18]
Internet Draft Session Timer July 1, 2002
Default Reason Phrase: Session Interval Too Small
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
12.3 IANA Registration of the "timer" Option Tag
The following is the registration for the "timer" option tag:
Name: timer
Description: This option tag is for support of the session timer
extension. Inclusion in a Supported header field in a
request or response indicates that the UA is capable of
performing refreshes according to that specification.
Inclusion in a Require header in a request means that the
UAS must understand the session timer extension to process
the request. Inclusion in a Require header field in a
response indicates that the UAC must look for the Session-
Expires header field in the response, and process
accordingly.
13 Example Call Flow
Figure 1 gives an example of a call flow that makes use of the
session timer. In this example, both the UAC and UAS support the
session timer extension. The initial INVITE request generated by the
UAC, Alice (message 1), might look like:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
S.Donovan et. al. [Page 19]
Internet Draft Session Timer July 1, 2002
This request indicates that Alice supports the session timer, and is
request session refreshes every 50 seconds. This arrives at the first
proxy, P1. This session interval is below the minimum allowed value
of 3600. So, P1 rejects the request with a 422 (message 2):
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Min-SE: 3600
To: Bob <sip:bob@biloxi.com>;tag=9a8kz
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
This response contains an Min-SE header field with the value of 3600.
Alice then retries the request. This time, the request contains a
Min-SE header, since Alice has received a 422 for other INVITE
requests with the same Call-ID. The new request (message 4) might
look like:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Supported: timer
Session-Expires: 3600
Min-SE: 3600
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Proxy P1 record-routes. Since the session interval is now acceptable
to it, it forwards the request to P2 (message 5). However, the
session interval is below its minimum configured amount of 4000. So,
it rejects the request with a 422 response code (message 6), and
S.Donovan et. al. [Page 20]
Internet Draft Session Timer July 1, 2002
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
| |(5) INVITE | |
| |SE:3600 | |
| |MSE:3600 | |
| |----------->| |
| |(6) 422 | |
| |MSE:4000 | |
| |<-----------| |
| |(7) ACK | |
| |----------->| |
|(8) 422 | | |
|MSE:4000 | | |
|<-----------| | |
|(9) ACK | | |
|----------->| | |
|(10) INVITE | | |
|SE:4000 | | |
|MSE:4000 | | |
|----------->| | |
| |(11) INVITE | |
| |SE:4000 | |
| |MSE:4000 | |
| |----------->| |
| | |(12) INVITE |
| | |SE:4000 |
| | |MSE:4000 |
| | |----------->|
| | |(13) 200 OK |
| | |SE:4000 |
| | |<-----------|
| |(14) 200 OK | |
| |SE:4000 | |
| |<-----------| |
|(15) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
|(16) ACK | | |
|----------->| | |
| |(17) ACK | |
| |------------------------>|
|(18) UPDATE | | |
|SE:4000 | | |
|----------->| | |
| |(19) UPDATE | |
| |SE:4000 | |
| |------------------------>|
| |(20) 200 OK | |
| |SE:4000 | |
| |<------------------------|
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
Figure 1: Example Session Timer Flow
S.Donovan et. al. [Page 21]
Internet Draft Session Timer July 1, 2002
includes a Min-SE header field with the value of 4000. Once more,
Alice retries the INVITE. This time, the Min-SE header field in her
INVITE is the maximum of all Min-SE she has received (3600 and 4000).
Message 10 might look like:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
Supported: timer
Session-Expires: 4000
Min-SE: 4000
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
P1 record-routes once again, but P2 does not (this wouldn't normally
happen; presumably, if it asked for session timer, it would record-
route the subsequent request). The UAS receives the request. It
copies the Session-Expires header from the request to the response,
and adds a refresher parameter with value "uac". This 200 OK is
forwarded back to Alice. The response she receives (message 15) might
look like:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
;received=192.0.2.1
Require: timer
Supported: timer
Record-Route: sip:p1.atlanta.com;lr
Session-Expires: 4000;refresher=uac
To: Bob <sip:bob@biloxi.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
S.Donovan et. al. [Page 22]
Internet Draft Session Timer July 1, 2002
Content-Length: 142
(Bob's SDP not shown)
Alice generates an ACK (message 16), which is routed through P1 and
then to Bob. Since Alice is the refresher, around 3000 seconds later,
Alice sends an UPDATE request to refresh the session. Since this
request is part of an established dialog, and Alice has not received
any 422 responses or requests on that dialog, there is no Min-SE
header field in her request (message 18):
UPDATE sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
Route: sip:p1.atlanta.com;lr
Supported: timer
Session-Expires: 4000;refresher=uac
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sip:alice@pc33.atlanta.com>
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
the Session-Expires header field into the response. This is forwarded
through P1, and arrives at Alice. The response she receives (message
21) might look like:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
;received=192.0.2.1
Require: timer
Session-Expires: 4000;refresher=uac
To: Bob <sip:bob@biloxi.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sip:bob@192.0.2.4>
S.Donovan et. al. [Page 23]
Internet Draft Session Timer July 1, 2002
Shortly afterwards, Alice's UA crashes. As a result, she never sends
an session refresh request. 3990 seconds later, Bob gives up, and
sends a BYE request (message 22). This is sent to P1. P1 attempts to
deliver it, but fails (since Alice's UA has crashed). P1 then returns
a 408 (Request Timeout) to Bob.
14 Acknowledgements
The authors wish to thank Brett Tate for his contributions to this
work.
15 Author's Addresses
Steven R. Donovan
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
email: sdonovan@dynamicsoft.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
16 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[2] J. Rosenberg, "The session initiation protocol UPDATE method,"
Internet Draft, Internet Engineering Task Force, May 2002. Work in
progress.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress.
S.Donovan et. al. [Page 24]
Internet Draft Session Timer July 1, 2002
17 Informative References
[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," RFC 1889, Internet
Engineering Task Force, Jan. 1996.
[6] P. Srisuresh and M. Holdrege, "IP network address translator
(NAT) terminology and considerations," RFC 2663, Internet Engineering
Task Force, Aug. 1999.
[7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
[8] A. Roach, "SIP-specific event notification," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
S.Donovan et. al. [Page 25]
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 4
3 Overview of Operation ............................... 4
4 Session-Expires Header Field Definition ............. 6
5 Min-SE Header Field Definition ...................... 7
6 422 Response Code Definition ........................ 8
7 UAC Behavior ........................................ 8
7.1 Generating a Session Refresh Request ................ 8
7.2 Processing a 2xx Response ........................... 10
7.3 Processing a 422 Response ........................... 11
8 Proxy Behavior ...................................... 11
8.1 Processing of Requests .............................. 11
8.2 Processing of Responses ............................. 13
8.3 Session Expiration .................................. 14
9 UAS Behavior ........................................ 14
10 Performing Refreshes ................................ 16
11 Security Considerations ............................. 16
11.1 Inside Attacks ...................................... 17
11.2 Outside Attacks ..................................... 17
12 IANA Considerations ................................. 18
12.1 IANA Registration of Min-SE and Session-Expires
Header Fields .................................................. 18
12.2 IANA Registration of the 422 (Session Interval Too
Small) Response Code ........................................... 18
12.3 IANA Registration of the "timer" Option Tag ......... 19
13 Example Call Flow ................................... 19
14 Acknowledgements .................................... 24
15 Author's Addresses .................................. 24
16 Normative References ................................ 24
17 Informative References .............................. 25
S.Donovan et. al. [Page 1]
