Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
Session Timers in the Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 whether 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the ’timer’ Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
The Session Initiation Protocol (SIP) [2] does not define a keepalive
mechanism for the sessions it establishes. Although the user agents
may be able to determine whether the session has timed out by 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. For instance, when a
user agent fails to send a BYE message at the end of a session, or
when 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 method to determine 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 [3] 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. A user agent
would like to determine whether the session is still active for the
same reasons a call stateful proxy server would. 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 indications of
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 provides 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 backward compatible with SIP that it works as long as
either one of the two participants in a dialog understands 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
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’, ’MUST NOT’, ’REQUIRED’,
’SHALL’, ’SHALL NOT’, ’SHOULD’, ’SHOULD NOT’, ’RECOMMENDED’, ’MAY’,
and ’OPTIONAL’ are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP implementations.
Additionally, we define the following terms:
Session Interval: The maximum 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, which is 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 processed
according to the rules of this specification. 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 [2], which is a
request that can update the remote target of a dialog.
Initial Session Refresh Request: The first session refresh request
sent with a particular Call-ID value.
Subsequent Session Refresh Request: Any session refresh request sent
with a particular Call-ID after the initial session refresh
request.
Refresh: Same as a session refresh request.
3. Overview of Operation
This section provides a brief overview of the operation of the
extension. It is tutorial in nature and should not be considered
normative.
This extension has the property that it works even when only one UA
in a dialog supports it. The processing steps differ for handling
each of the four cases (the UAC does or doesn’t support it, and the
UAS does or doesn’t support it). For simplicity’s sake, this section
will describe basic operation in the case where both sides support
the extension.
A UAC starts by sending an INVITE. This includes a Supported header
field with the option tag ’timer’, indicating support for this
extension.
This request passes through proxies, any one of which may have an
interest in establishing a session timer. Each proxy can insert a
Session-Expires header field and a Min-SE header field into the
request (if none is already there) or alter the value of existing
Session-Expires and Min-SE header fields as described below.
The Min-SE header field establishes the lower bound for the session
refresh interval; i.e., the fastest rate any proxy servicing this
request will be allowed to require. The purpose of this header field
is to prevent hostile proxies from setting arbitrarily short refresh
intervals so that their neighbors are overloaded. Each proxy
processing the request can raise this lower bound (increase the
period between refreshes) but is not allowed to lower it.
The Session-Expires header field establishes the upper bound for the
session refresh interval; i.e., the time period after processing a
request for which any session-stateful proxy must retain its state
for this session. Any proxy servicing this request can lower this
value, but it is not allowed to decrease it below the value specified
in the Min-SE header field.
If the Session-Expires interval is too low for a proxy (i.e., lower
than the value of Min-SE that the proxy would wish to assert), the
proxy rejects the request with a 422 response. That response
contains a Min-SE header field identifying the minimum session
interval it is willing to support. The UAC will try again, this time
including the Min-SE header field in the request. The header field
contains the largest Min-SE header field it observed in all 422
responses previously received. This way, the minimum timer meets the
constraints of all proxies along the path.
After several INVITE/422 iterations, the request eventually arrives
at the UAS. The UAS can adjust the value of the session interval as
if it were a proxy; when done, it places the final session interval
into the Session-Expires header field in a 2xx response. The
Session-Expires header field also contains a ’refresher’ parameter,
which indicates who is doing the refreshing -- the UA that is
currently the UAC, or the UA that is currently the UAS. As the 2xx
response travels back through the proxy chain, each proxy can observe
the final session interval but can’t change it.
From the Session-Expires header field in the response, both UAs know
that a session timer is active, when it will expire, and who is
refreshing. At some point before the expiration, the currently
active refresher generates a session refresh request, which is a
re-INVITE or UPDATE [3] request. 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.
The refresh requests sent once the session is established are
processed identically to the initial requests, as described above.
This means that a successful session refresh request will extend the
session, as desired.
The extension introduces additional complications beyond this basic
flow to support cases where only one of the UAs supports it. One
such complication is that a proxy may need to insert the
Session-Expires header field into the response, in the event that the
UAS doesn’t support the extension. The negotiation of the role of
refresher is also affected by this capability; it takes into
consideration which participants support the extension.
Note 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, as well
as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires
header field, it contains a delta-time.
The absolute minimum for the Session-Expires header field is 90
seconds. This value represents a bit more than twice the duration
that a SIP transaction can take in the event of a timeout. This
allows sufficient time for a UA to attempt a refresh at the halfpoint
of the session interval, and for that transaction to complete
normally before the session expires. However, 1800 seconds (30
minutes) is RECOMMENDED as the value for the Session-Expires header
field. In other words, SIP entities MUST be prepared to handle
Session-Expires header field values of any duration greater than 90
seconds, but entities that insert the Session-Expires header field
SHOULD NOT choose values of 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’ that 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 because 95% of phone
calls are shorter than this duration. However, the 30 minute minimum
is listed as a SHOULD, and not as a MUST, since the exact value for
this number is 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 is undefined.
This means that the absence of the Session-Expires header field
implies no expiration of the session, using the mechanism defined in
this specification. Note that other mechanisms not defined in this
specification, such as locally configured timers, may apply.
The syntax of the Session-Expires header field is as follows:
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 [2].
Table 1 is an extension of Tables 2 and 3 in [2] for the
Session-Expires and Min-SE header fields. The column ’PRA’ is for
the PRACK method [7], ’UPD’ is for the UPDATE method [3], ’SUB’ is
for the SUBSCRIBE method [8], and ’NOT’ is for the NOTIFY method [8].
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| Header |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 that can be used for that session. When present in a
request or response, its value MUST NOT be less than 90 seconds.
When the header field is not present, its default value for is 90
seconds.
The Min-SE header field MUST NOT be used in responses except for
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 as follows:
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 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 an Initial Session Refresh Request
A UAC that supports the session timer extension defined here MUST
include a Supported header field in each request (except ACK),
listing the option tag ’timer’ [2]. 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, only 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 the 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’.
A UAC MAY include the Min-SE header field in the initial INVITE
request.
A UAC MAY include a Session-Expires header field in an initial
session refresh request if it wants a session timer applied to the
session. The value of this header field indicates the session
interval desired by the UAC. If a Min-SE header is included in the
initial session refresh request, the value of the Session-Expires
MUST be greater than or equal to the value in Min-SE.
The UAC MAY include the refresher parameter with value ’uac’ if it
wants 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.
7.2. Processing a 2xx Response
The 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 perform 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 the session timer (and thus included
a Session-Expires header field in the request) and that 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 (which is 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 that 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 sent. A 2xx without a Session-Expires can come for both initial
and subsequent session refresh requests. This means that the session
timer can be ’turned-off’ in mid dialog by receiving a response
without a Session-Expires header field.
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