draft-ietf-sip-session-timer-08.txt   draft-ietf-sip-session-timer-09.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft S.Donovan,J.Rosenberg Internet Draft S.Donovan
draft-ietf-sip-session-timer-08.txt dynamicsoft dynamicsoft
October 6, 2001 J.Rosenberg
Expires: April 2002 dynamicsoft
draft-ietf-sip-session-timer-09.txt
July 1, 2002
Expires: January 2003
The SIP Session Timer Session Initiation Protocol Extension for Session Timer
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 37
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes an extension to the Session Initiation This document defines an extension to the Session Initiation Protocol
Protocol (SIP). This extension allows for a periodic refresh of SIP (SIP). This extension allows for a periodic refresh of SIP sessions
sessions through a re-INVITE. The refresh allows both user agents and through a re-INVITE or UPDATE request. The refresh allows both user
proxies to determine if the SIP session is still active. The agents and proxies to determine if the SIP session is still active.
extension defines two new general headers, Session-Expires, which The extension defines two new header fields, Session-Expires, which
conveys the lifetime of the session, and Min-SE, which conveys the conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer. minimum allowed value for the session timer.
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1], does not define a The Session Initiation Protocol (SIP) [1], does not define a
keepalive mechanism. The result is that call stateful proxies will keepalive mechanism for the sessions it establishes. Although the
not always be able to determine whether a call is still active or user agents may be able to determine if the session has timed out
not. For instance, when a user agent fails to send a BYE message at using session specific mechanisms, proxies will not be able to do so.
the end of a session, or the BYE message gets lost due to network The result is that call stateful proxies will not always be able to
problems, a call stateful proxy will not know when the session has determine whether a session is still active or not. For instance,
ended. In this situation, the call stateful proxy will retain state when a user agent fails to send a BYE message at the end of a
for the call and has no deterministic method of determining when the session, or the BYE message gets lost due to network problems, a call
call state information no longer applies. 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 To resolve this problem, this extension defines a keepalive mechanism
for SIP sessions. UAs send periodic re-INVITEs to keep the session for SIP sessions. UAs send periodic re-INVITE or UPDATE [2] requests
alive. The interval for the re-INVITEs is determined through a (referred to as session refresh requests) to keep the session alive.
negotiation mechanism defined here. If a re-INVITE is not received The interval for the session refresh requests is determined through a
before the interval passes, the session is considered terminated. negotiation mechanism defined here. If a session refresh request is
Both UAs are supposed to send a BYE, and call stateful proxies can not received before the interval passes, the session is considered
remove any state for the call. terminated. Both UAs are supposed to send a BYE, and call stateful
proxies can remove any state for the call.
INVITE is used as a refresh, as opposed to another method,
to allow sessions to be recovered after a crash and restart
of one of the UAs. It makes SIP sessions soft state.
This refresh mechanism has additional applications. For the same This refresh mechanism has additional applications. For the same
reasons a call stateful proxy server would like to determine whether reasons a call stateful proxy server would like to determine whether
the session is still active, a user agent would like to make this the session is still active, a user agent would like to make this
determination. This determination can be made at a user agent without determination. This determination can be made at a user agent without
the use of SIP level mechanisms; for audio sessions, periodic RTCP the use of SIP level mechanisms; for audio sessions, periodic RTCP
packets serve as an indication of liveness [2]. However, it is packets serve as an indication of liveness [5]. However, it is
desirable to separate SIP call liveness from the details of the desirable to separate SIP session liveness from the details of the
particular session. particular session.
Another application of the session timer is in the construction of a Another application of the session timer is in the construction of a
SIP NAT ALG. The ALG embedded in a NAT will need to maintain state SIP Network Address Translator (NAT) Application Level Gateway (ALG)
for the duration of a call. This state must eventually be removed. [6]. The ALG embedded in a NAT will need to maintain state for the
Relying on a BYE to trigger the removal of state, besides being duration of a call. This state must eventually be removed. Relying on
unreliable, introduces a potential denial of service attack. 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 This document proposes an extension to SIP that defines a session
expiration mechanism. Periodic refreshes, through re-INVITEs, are expiration mechanism. Periodic refreshes, through re-INVITEs or
used to keep the session active. The extension is sufficiently UPDATEs, are used to keep the session active. The extension is
backwards compatible with SIP that it works so long as either one of sufficiently backwards compatible with SIP that it works so long as
the two participants in a call leg understand the extension. Two new either one of the two participants in a dialog understand the
general headers, Session-Expires and Min-SE, and a new response code, extension. Two new header fields, Session-Expires and Min-SE, and a
422, are defined. Session-Expires conveys the duration of the new response code, 422, are defined. Session-Expires conveys the
session, and Min-SE conveys the minimum allowed value for the session duration of the session, and Min-SE conveys the minimum allowed value
expiration. The 422 response code indicates that the session timer for the session expiration. The 422 response code indicates that the
duration was too small. session timer duration was too small.
2 Terminology 2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant SIP implementations.
Additionally, we define the following terms: Additionally, we define the following terms:
Session Interval: The largest amount of time that can occur Session Interval: The largest amount of time that can occur
between INVITE requests in a call before it will be between session refresh requests in a dialog before the
considered timed out. The session interval is conveyed in session will be considered timed out. The session interval
the Session-Expires header defined here. The UAS obtains is conveyed in the Session-Expires header field defined
this value from the Session-Expires header of a 2xx INVITE here. The UAS obtains this value from the Session-Expires
response that it sends. Proxies and UACs determine this header field in a 2xx response to a session refresh request
value from the Session-Expires header in a 2xx INVITE that it sends. Proxies and UACs determine this value from
response they receive. 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 INVITE Minimum Timer: Because of the processing load of mid-dialog
requests, all elements (proxy, UAC, UAS) can have a requests, all elements (proxy, UAC, UAS) can have a
configured minimum value for the session interval that they configured minimum value for the session interval that they
are willing to accept. This value is called the minimum are willing to accept. This value is called the minimum
timer. timer.
Session Expiration: The time at which an element will consider Session Expiration: The time at which an element will consider
the call timed out, if no successful INVITE transaction the session timed out, if no successful session refresh
occurs beforehand. transaction occurs beforehand.
Refresh: An INVITE request sent during an active call leg. If Session Refresh Request: An INVITE or UPDATE request within a
the request generates a 2xx response, the session dialog. If the request generates a 2xx response, the
expiration is increased to the current time plus the session expiration is increased to the current time plus
session interval from the response. 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.
3 Protocol Overview Refresh: Same as a session refresh request.
This section provides a brief overview of operation of the protocol. 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. It is tutorial in nature and should not be considered as normative.
Session refreshes are accomplished using SIP INVITEs. The initial Session refreshes are accomplished using SIP INVITE or UPDATE [2]
INVITE establishes the duration of the session, which is carried in requests. The initial session refresh request establishes the
the Session-Expires header in the 2xx response to the INVITE. The duration of the session, which is carried in the Session-Expires
Session-Expires header in the 2xx response also indicates which side header field in the 2xx response to the session refresh request. The
will be responsible for generating these refreshes - the uac or uas. Session-Expires header field in the 2xx response also indicates which
The responsible side then generates a refresh (using a re-INVITE) side will be responsible for generating these refreshes - the UAC or
before the session expires. If the refreshes never gets a response to the UAS. The responsible side generates a refresh (using a re-INVITE
that re-INVITE, it sends a BYE to terminate the call. Similarly, if or UPDATE) before the session expires. If the refresher never gets a
the other side never gets the re-INVITE before the session expires, response to that session refresh request, it sends a BYE to terminate
it sends a BYE. The refreshes themselves are processed identically to the session. Similarly, if the other side never gets the session
a regular INVITE, so that the response to a re-INVITE carries the new refresh request before the session expires, it sends a BYE. All
time at which the session will expire. 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 the protocol to operate so long as one of It is an explicit goal of this extension to operate so long as one of
the two UAs in a call leg support the extension. That side, of the two UAs in a dialog support the extension. That side, of course,
course, ends up performing the refreshes. The other side will merely ends up performing the refreshes. The other side will merely see them
see them as repetitive re-INVITEs. This facilitates interoperability. as repetitive re-INVITE or UPDATE requests. This facilitates
interoperability.
The details of the protocol relate to negotiation of a reasonable The extension supports negotiation of a reasonable value for the
value for the session interval, and negotiation of which side of the session interval, and negotiation of which side of the dialog is
call leg is performing the refreshes. Negotiation of the session performing the refreshes. Negotiation of the session interval is
interval is critical. The value must be small enough to provide a critical. The value must be small enough to provide a useful
useful expiration, but not so small to overload the proxies with re- expiration, but not so small to overload the proxies with messages.
INVITEs. The goal of the protocol is to choose a session interval The goal of the negotiation algorithm is to choose a session interval
that is the smallest of all the values requested by all elements, but that is the smallest of all the values requested by all elements on
only if that value is larger than the largest minimum timer requested the dialog path, but only if that value is larger than the largest
by all elements. Negotiation of the refresher role is simpler. If minimum timer requested by all elements. Negotiation of the refresher
only one side supports the extension, that side acts as refresher. role is simpler. If only one side supports the extension, that side
Otherwise, one side chooses who will refresh. This negotiation takes acts as refresher. Otherwise, one side chooses who will refresh. This
place as part of INVITE processing, and due to the idempotency of negotiation takes place as part of session refresh request
INVITE requests, is effectively redone each time the session is processing, and due to the idempotency of that processing, is redone
refreshed with another re-INVITE. each time the session is refreshed.
To negotiate the value of the refresh interval, the Min-SE and To negotiate the value of the refresh interval, the Min-SE and
Session-Expires headers are used. The UAC generates an INVITE, and Session-Expires header fields are used. The UAC generates a session
includes a Session-Expires if it wishes to use the session timer. As refresh request, and includes a Session-Expires header field if it
the INVITE traverses proxies, the proxies (and the UAS) can reduce wishes to use the session timer. The Session-Expires header field
the value of the session timer, but not lower than the value of the value contains the session interval. As the session refresh request
Min-SE header. If a proxy or UAS receives a request with a Session- traverses proxies, the proxies (and the UAS) can reduce the value of
Expires lower than a configured minimum, it can reject the request the session interval, but not lower than the value of the Min-SE
with a 422 response. This response contains a Min-SE header with the header field. If a proxy or UAS receives a request with a Session-
minimum allowed value. The client retries the request, inserting a Expires header field value lower than a configured minimum, it can
Min-SE header containing the maximum value of the Min-SE headers reject the request with a 422 response. This response contains a
returned in previous 422 responses for the call. In the case where Min-SE header field with the minimum allowed value. The client
the client isn't aware of the session timer extension, a proxy that retries the request, inserting a Min-SE header field containing the
receives a request with a Session-Expires lower than the configured maximum value of the Min-SE header fields returned in previous 422
minimum places the Min-SE header in the proxied request, and responses for the call. In the case where the UAC isn't aware of the
increases the Session-Expires header to that minimum. When 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 request eventually reaches the UAS (potentially after a few retries
from 422), it will do so containing a Session-Expires header that resulting from a 422), it will contain a Session-Expires header field
meets the design criteria described above. The UAS returns a 200 OK whose value meets the design criteria described above. The UAS
with a Session-Expires header containing the final duration of the returns a 200 OK with a Session-Expires header field containing that
session. The header also contains a parameter, called refresher, that value. The header field also contains a parameter, called refresher,
indicates which side is performing the refreshes. that indicates which side is performing the refreshes.
This basic behavior is built upon to handle the case where only one When only the UAC supports the session timer extension, one of the
side supports the extension. When only the UAC supports it, one of proxies "fills the shoes" of the UAS. Specifically, when the UAS does
the proxies "fills the shoes" of the UAS. Specifically, when the UAS support session timer, it places the value of the session interval
does support session timer, it places the value of the session timer into the Session-Expires header field in the 2xx response. When the
into the Session-Expires header in the 2xx response. When the UAS UAS doesn't support it, the proxy closest to the UAS that asked for a
doesn't support it, the proxy closest to the UAS performs that job, session expiration performs that job, and inserts the value of the
and inserts the value of the timer into the 2xx response as it passes session interval into the 2xx response as it passes by.
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 4 Session-Expires Header Field Definition
The Session-Expires general header conveys the session interval for a The Session-Expires header field conveys the session interval for a
SIP call. It is placed only in INVITE requests, and is allowed in any SIP session. It is placed only in INVITE or UPDATE requests, and is
200 class response to an INVITE. Unlike the SIP Expires header, it allowed in any 2xx response to an INVITE or UPDATE. Like the SIP
can only contain a delta-time. The session expiration is defined as Expires header field, it contains a delta-time.
that delta plus the time at which the header is observed in a final
response. For example, if a UAS generates a 200 OK response to a re-
INVITE that contained a Session-Expires header with a value of 3600,
the UAS computes the session expiration as one hour after the time
when the 200 OK was sent. For each proxy, the session expiration is
one hour after the time when the 2xx was received or sent (assuming
these two are sufficiently close together). For the UAC, the
expiration time is one hour after the receipt of the final response.
There is no absolute minimum value for the Session-Expires header. There is no absolute minimum value for the Session-Expires header
However, 1800 seconds (30 minutes) is RECOMMENDED. In other words, field. However, 1800 seconds (30 minutes) is RECOMMENDED. In other
SIP entites MUST be prepared to handle Session-Expires values of any words, SIP entites MUST be prepared to handle Session-Expires header
duration, but entities that insert the Session-Expires header SHOULD field values of any duration, but entities that insert the Session-
NOT choose values less than 30 minutes. Expires header field SHOULD NOT choose values less than 30 minutes.
Small session intervals can be destructive to the network. They cause Small session intervals can be destructive to the network. They cause
excessive messaging traffic that affects both user agents and proxy excessive messaging traffic that affects both user agents and proxy
servers. They increase the possibility of re-INVITE collisions (when servers. They increase the possibility of "glare" which can occur
both parties re-INVITE each other at the same time). Since the when both user agents send a re-INVITE or UPDATE at the same time.
primary purpose of session timer is to provide a means to time out Since the primary purpose of the session timer is to provide a means
state in SIP elements, very small values won't generally be needed. to time out state in SIP elements, very small values won't generally
30 minutes was chosen since 95% of phone calls are less than this be needed. 30 minutes was chosen since 95% of phone calls are less
duration. However, the 30 minute minimum is listed as a SHOULD, and than this duration. However, the 30 minute minimum is listed as a
not a MUST, since the exact value for this number is dependent on SHOULD, and not a MUST, since the exact value for this number is
many network factors, including network bandwidths and latencies, dependent on many network factors, including network bandwidths and
computing power, memory availability, network topology, and of latencies, computing power, memory availability, network topology,
course, the application scenario. After all, SIP can set up any kind and of course, the application scenario. After all, SIP can set up
of session, not just a phone call. At the time of publication of this any kind of session, not just a phone call. At the time of
document, 30 minutes seems appropriate. Advances in technologies may publication of this document, 30 minutes seems appropriate. Advances
result in the number being excessively large five years in the in technologies may result in the number being excessively large five
future. years in the future.
The syntax of the Session-Expires header is:
Session-Expires = ("Session-Expires" | "x") ":" delta-seconds
[refresher]
refresher = ";" "refresher" "=" "uas"|"uac"
The optional refresher parameter indicates who will be doing the
refreshing. It is RECOMMENDED that this parameter not be present in
an initial INVITE, so that the negotiation mechanisms can
successfully determine who will perform them. A 2xx response with the
Session-Expires header MUST contain this parameter, indicating who
will perform the refreshes. If the UAC wishes to insist on performing
the refreshes, it MAY insert the parameter with a value of "uac" in
the INVITE. 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 with a Supported header containing the value "timer" from its
peer, or because a 2xx response received from the peer had a
refresher parameter with the value "uas".
Note that a compact form, the letter 'x', has been reserved for
Session-Expires. The BNF for delta-seconds is defined in Section 6.20
of RFC 2543 [1].
Table 1 is an extension of tables 4 and 5 in [1] for the Session- The default value of the Session-Expires header field, when not
Expires header: present, is infinity. This means that absence of the Session-Expires
header field implies no expiration.
where enc e-e ACK BYE CAN INV OPT REG The syntax of the Session-Expires header field is:
_____________________________________________________
Session-Expires R n h - - - o - -
Session-Expires 2xx n h - - - o - -
Table 1: Summary of header fields. "o": optional "-": not applicable, Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
"R': request header, "r": response header, "g": general header, "*": *(SEMI se-params)
needed if message body is not empty. A numeric value in the "type" se-params = refresher-param / generic-param
column indicates the status code the header field is used with. refresher-param = "refresher" EQUAL ("uas" / "uac")
5 Min-SE Header Field Definition 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].
The Min-SE general header indicates the minimum value for the session Table 1 is an extension of Tables 2 and 3 in [1] for the Session-
interval, in units of delta-seconds. When used in an INVITE request, Expires and Min-SE header fields. The column "PRA" is for the PRACK
it indicates the smallest value of the session interval which can be method [7], "UPD" is for the UPDATE method [2], "SUB" is for the
used for that session. A proxy or UAS MUST NOT reduce the value of SUBSCRIBE method [8], and "NOT" is for the NOTIFY method [8].
the session interval below the value in this header, when present in
an INVITE request.
When not present, the default value for this header is zero. 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 - -
The Min-SE header MUST NOT be used in responses except those with a Table 1: Session-Expires and Min-SE Header Fields
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 is: 5 Min-SE Header Field Definition
Min-SE = "Min-SE" ":" delta-seconds 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.
A UAC MAY include the Min-SE in an INVITE request, even if it never When not present, the default value for this header field is zero.
received a 422 previously.
Table 2 is an extension of tables 4 and 5 in [1] for the Min-SE The Min-SE header field MUSTNOT be used in responses except those
header: with a 422 response code. It indicates the minimum value of the
session interval that the server is willing to accept.
where enc e-e ACK BYE CAN INV OPT REG The syntax of the Min-SE header field is:
____________________________________________
Min-SE R n h - - - o - -
Min-SE 422 n h - - - m - -
Table 2: Summary of header fields. "o": optional, "m": mandatory, "- Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
": not applicable, "R': request header, "r": response header, "g":
general header, "*": needed if message body is not empty. A numeric
value in the "type" column indicates the status code the header field
is used with.
6 422 Response Code Definition 6 422 Response Code Definition
This extension introduces the 422 response code. The default reason This extension introduces the 422 (Session Interval Too Small)
phrase for this code is "Session Timer Too Small". It is generated by response code. It is generated by a UAS or proxy when a request
a UAS or proxy when a request contains a Session-Expires header with contains a Session-Expires header field with a duration that is below
a duration that is below the minimum timer for the server. The 422 the minimum timer for the server. The 422 response MUST contain a
response MUST contain a Min-SE header with the minimum timer for that Min-SE header field with the minimum timer for that server.
server.
7 UAC Behavior 7 UAC Behavior
7.1 Generating an INVITE Request 7.1 Generating a Session Refresh Request
A UAC which supports the session timer extension defined here MUST A UAC which supports the session timer extension defined here MUST
include a Supported header in each request (except ACK), listing the include a Supported header field in each request (except ACK),
option tag "timer" [4]. It MUST do so even if the UAC is not listing the option tag "timer" [1]. It MUST do so even if the UAC is
requesting keepalives for the call. not requesting usage of the session timer for this session.
The UAC MAY include a Require in the request with the value "timer" The UAC MAY include a Require header field in the request with the
to indicate that the UAS must support the session timer to value "timer" to indicate that the UAS must support the session timer
participate in the session. This does not mean that the UAC is 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 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 the UAS to support the extension. In addition, the UAC MAY include a
Proxy-Require header in the request with the value "timer" to Proxy-Require header field in the request with the value "timer" to
indicate that proxies must support session timer in order to indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the since the extension works even when only the UAC supports the
extension. The Supported header containing "timer" MUST still be extension. The Supported header field containing "timer" MUST still
included even if the Require or Proxy-Require headers are present be included even if the Require or Proxy-Require header fields are
containing "timer". present containing "timer".
The UAC MUST insert the Min-SE header into a re-INVITE request for a The UAC MUST insert the Min-SE header field into a session refresh
particular call leg if it has ever received a 422 response to a request for a particular dialog if it has ever received a 422
previous INVITE on the same leg, or if it has received an INVITE on response to a previous session refresh request on the same dialog, or
that call leg which contained a Min-SE header. Similarly, if no call if it has received a session refresh request on that dialog which
leg has been established yet, a UAC MUST insert the Min-SE header contained a Min-SE header field. Similarly, if no dialog has been
into an INVITE request for a particular call if it has ever received established yet, a UAC MUST insert the Min-SE header field into an
a 422 response to a previous INVITE with the same Call-ID. 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 present in the INVITE MUST be the The value of the Min-SE header field present in a session refresh
largest value amongst all Min-SE values returned in all 422 request MUST be the largest value amongst all Min-SE header field
responses, or received in INVITE requests, on the same call leg, if a values returned in all 422 responses, or received in session refresh
call leg has been established. If no leg is established, the Min-SE requests, on the same dialog, if a dialog has been established. If no
header is set to the largest value amongst all Min-SE values returned dialog has been established, the Min-SE header field value is set to
in all 422 responses for the same call. A result of this rule is that the largest value amongst all Min-SE header field values returned in
the maximum value of the Min-SE is effectively "cleared" once the all 422 responses for an INVITE request with the same Call-ID. A
call leg is established, and from that point on, only the values from result of this rule is that the maximum value of the Min-SE is
proxies known to be on the proxy path will end up being used. 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. 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 In that case, if the value above is too small, the UAC MAY increase
it. it.
A UAC MAY include a Session-Expires in an initial INVITE request if A UAC MAY include the Min-SE header field in an INVITE request
it wishes for a session timer to be applied. The value of this header outside of a dialog, even if it never received a 422 previously.
indicates session interval desired by the UAC. In an INVITE that is
within a call leg with an active session timer, the header SHOULD be
present, and SHOULD contain the the larger of the current value of
the session interval and the value of the Min-SE, if present.
If the INVITE is a re-INVITE it is RECOMMENDED that the refresher be
set to "uac" if the element sending the INVITE is currently
performing refreshes, else "uas" if its peer is performing the
refreshes. In an initial INVITE, the UAC MAY include the refresher
parameter with value "uac" if it wishes to perform the refreshes. If
the UAC wishes to leave this decision to the negotiation mechanisms
described below, the refresher parameter is omitted.
A re-INVITE generated to refresh the session is a normal re-INVITE.
It SHOULD contain SDP that describes the session, even if that SDP
has not changed. In that case, the session description MUST somehow
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 messages to its peer. The same is true for the 200 class
response to a re-INVITE used solely for refreshing. The response MUST
contain a session description with an indication that it has not
changed. This is accomplished in the same way as for the request.
It is possible for a UAS to believe that an INVITE is an initial
INVITE, and for the UAC to believe it is a re-INVITE. This happens
when a UA crashes and reboots between refreshes. When the refresh
arrives at the rebooted UA, it decides to reject the call (generally,
it will reject the call unless it explicitly is capable of recovering
lost calls). If From tags are used, the UAS can detect that the re-
INVITE is for an existing call by the existence of the tag in the To
field of the re-INVITE. Therefore, a UAC MUST insert a From tag in an
initial INVITE if it supports session timer. A UAS that wishes to
reject a re-INVITE for a call that it believes is already terminated
SHOULD respond with a 481. A UAC receiving a 481 to a session timer
refresh MUST generate a BYE to terminate that call leg.
If From tags were not mandatory, A could INVITE B without a
From tag. B inserts a tag in the 200 OK. Now, B sends a
re-INVITE to A. Meantime, A has crashed and rebooted. This
re-INVITE has a From tag, but no To tag. It therefore
cannot be distinguished for a new INVITE in which the UAC
inserts a From tag. This ambiguity is resolved by mandating
use of From tag with session timer.
The requirement for From tags and responding with a 481 to
stale re-INVITEs has been added to the updated version of
RFC2543. However, to eliminate a dependency between this
spec and the new version of SIP, these two features are
specified here as well.
7.1.1 Example
As an example, a UAC sends an INVITE with Call-ID 1, and receives a A UAC MAY include a Session-Expires in an initial session refresh
422 with a Min-SE header of 100. There is a tag in the To field, with request request if it wishes for a session timer to be applied to the
a value of 8. The UAC retries the request. It contains a Min-SE session. The value of this header field indicates the session
header. Since no call leg has been established, the Min-SE header interval desired by the UAC. In a session refresh request sent within
contains the largest value amongst all Min-SE values returned in 422 a dialog with an active session timer, the header field SHOULD be
responses to INVITEs with the same Call-ID, in this case, with the present. When present, it MUST be equal to the maximum of the Min-SE
Call-ID of 1. There has only been one such 422, and it had a Min-SE header field (recall that its default value when not present is zero)
header with value 100. So, the retried INVITE contains a Min-SE and the current session interval.
header with value 100, and no tag in the To field, as there is no
call leg established yet.
This INVITE generates another 422, this time with a Min-SE header In an initial session refresh request, the UAC MAY include the
with a value of 200 and a tag in the To field with value 9. Once refresher parameter with value "uac" if it wishes to perform the
again, the UAC retries the request. This time, the INVITE has a Min- refreshes. However, it is RECOMMENDED that the parameter be omitted,
SE with value 200. The call is accepted by the UAS, resulting in a so that it can be selected by the negotiation mechanisms described
200 OK with a tag in the To field of 10. Later, the UAC sends a re- below. If the session refresh request is not the initial one, it is
INVITE to refresh. Since a call leg is established, it looks to see RECOMMENDED that the refresher parameter be set to "uac" if the
whether there had been any Min-SE headers returned in any 422 element sending the request is currently performing refreshes, else
responses on the same leg (that is, with a tag of 10). Since there "uas" if its peer is performing the refreshes. This way, the role of
were none, that refresh doesn't contain a Min-SE header. 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.
Later on, the UA receives a re-INVITE from its peer, containing a A re-INVITE generated to refresh the session is a normal re-INVITE,
Min-SE header with the value of 100. This sets the maximum Min-SE and an UPDATE generated to refresh a session is a normal UPDATE. If a
value on this leg to 100. When the UA refreshes, it includes a Min-SE UAC knows that its peer supports the UPDATE method, it is RECOMMENDED
header with a value of 100. 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 7.2 Processing a 2xx Response
When a 2xx response to the INVITE request arrives, it may or may not Session timer requires a UA to create and maintain state. This state
contain a Require header with the value "timer". If it does, the UAC includes the session interval, the session expiration, and the
MUST look for the Session-Expires header to process the response. identity of the refresher. This state is associated with the dialog
on which the session has been negotiated.
If there was a Require header in the response with the value "timer", When a 2xx response to a session refresh request arrives, it may or
the Session-Expires header will always be present. UACs MUST be may not contain a Require header field with the value "timer". If it
prepared to receive a Session-Expires header in a response even if does, the UAC MUST look for the Session-Expires header field to
none were present in the request. The "refresher" parameter will be process the response.
present, indicating who will be performing the refreshes. If the
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 parameter contains the value "uac", the UAC will perform them. It is
possible that the UAC requested session timer (and thus included a possible that the UAC requested session timer (and thus included a
Session-Expires in the request), but there was no Require or Session-Expires header field in the request), but there was no
Session-Expires in the 200 class response. This will happen when the Require or Session-Expires header field in the 2xx response. This
UAS doesn't support session timer, and only the UAC has asked for will happen when the UAS doesn't support the session timer extension,
session timer (no proxies have requested it). In this case, if the and only the UAC has asked for a session timer (no proxies have
UAC still wishes to use keepalives (they are purely for its benefit requested it). In this case, if the UAC still wishes to use the
alone), it has to perform them. To do this, the UAC follows the session timer (they are purely for its benefit alone), it has to
procedures defined in this specification as if the Session-Expires perform them. To do this, the UAC follows the procedures defined in
header were in the 200 class response, and its value was the same as this specification as if the Session-Expires header field were in the
the one in the request (but with a refresher parameter of "uac"). 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, there If the 2xx response did not contain a Session-Expires header field,
is no session expiration. In this case, no refreshes need to be sent. there is no session expiration. In this case, no refreshes need to be
A 2xx without a Session-Expires can come for both initial and mid- sent. A 2xx without a Session-Expires can come for both initial and
call INVITE requests. mid-dialog session refresh requests.
The UAC remembers the session interval for a call leg as the value of The UAC remembers the session interval for a session as the value of
the delta-time from the Session-Expires header in the most recent 2xx the delta-time from the Session-Expires header field in the most
response to INVITE on that call leg. It is explicitly allowed for recent 2xx response to a session refresh request on a dialog. It is
there to be differing session intervals (or none at all) on differing explicitly allowed for there to be differing session intervals (or
call legs. This happens in the case where there are multiple 2xx OK none at all) on differing dialogs established as a result of a single
responses to an initial INVITE with different tags in the To field. INVITE. It also remembers whether it, or its peer, is the refresher
It also remembers whether it, or its peer, is the refresher on the on for the session.
leg.
If the UAC must refresh a leg, it computes the session expiration for If the UAC must perform the refreshes, it computes the session
that leg. The session expiration is the time of reception of the last expiration for that session. The session expiration is the time of
2xx INVITE response on that leg plus the session interval for that reception of the last 2xx response to a session refresh request on
leg. If UA wishes to continue with the session beyond the session that dialog plus the session interval for that session. If UA wishes
expiration, it MUST generate a refresh before the session expiration. to continue with the session beyond the session expiration, it MUST
It is RECOMMENDED that this refresh be sent once half the session generate a refresh before the session expiration. It is RECOMMENDED
interval has elapsed. Additional procedures for this refresh are that this refresh be sent once half the session interval has elapsed.
described in Section 10. Additional procedures for this refresh are described in Section 10.
7.3 Processing a 422 Response 7.3 Processing a 422 Response
If the response to an INVITE request is a 422 Session Timer Too Small If the response to a session refresh request is a 422 (Session
response message, then the UAC MAY retry the INVITE. The procedures Interval Too Small) response message, then the UAC MAY retry the
for retrying are described in Section 7.1. request. The procedures for retrying are described in Section 7.1.
8 Proxy Behavior 8 Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers. Session timers are mostly of interest to call stateful proxy servers.
However, a stateful proxy server MAY also follow the rules described However, a stateful proxy server MAY also follow the rules described
here. Stateless proxies MUST NOT attempt to request session timers. here. Stateless proxies MUST NOT attempt to request session timers.
Proxies which ask for session timers SHOULD record-route, since they Proxies which ask for session timers SHOULD record-route, since they
won't receive refreshes if they don't. won't receive refreshes if they don't.
The proxy processing rules require the proxy to remember The proxy processing rules require the proxy to remember
information between the request and response, ruling out information between the request and response, ruling out
stateless proxies. stateless proxies.
8.1 Processing of requests 8.1 Processing of Requests
Processing of requests is identical for INVITE and re-INVITE Processing of requests is identical for all session refresh requests.
requests.
To request a session timer for a call (either in progress or To request a session timer for a session, a proxy makes sure that a
initial), a proxy makes sure that a Session-Expires header is present Session-Expires header field is present in a session refresh request
in an INVITE that it proxies for that call. A proxy MAY insert a for that session. A proxy MAY insert a Session-Expires header field
Session-Expires header in the request before forwarding it, if none in the request before forwarding it, if none was present in the
was present in the request. This Session-Expires header may contain request. This Session-Expires header field may contain any desired
any desired expiration time the proxy would like, but not with a expiration time the proxy would like, but not with a duration lower
duration lower than the value in the Min-SE header in the request, if than the value in the Min-SE header field in the request, if present.
present. The proxy MUST NOT insert a refresher parameter with value The proxy MUST NOT include a refresher parameter in the header field
uac. It MAY insert one with value "uas", but this is redundant since value.
the UAS will conclude that it needs to refresh in any case.
If the request already had a Session-Expires header, the proxy MAY If the request already had a Session-Expires header field, the proxy
reduce the value in the Session-Expires header, but MUST NOT set it MAY reduce its value, but MUST NOT set it to a duration lower than
to a duration lower than the value in the Min-SE header in the the value in the Min-SE header field in the request, if present. If
request, if present. If the value of the Session-Expires header is the value of the Session-Expires header field is greater than or
greater than or equal to the value in the Min-SE header (recall that equal to the value in the Min-SE header field (recall that the
the default is zero when Min-SE is not present), the proxy MUST NOT default is zero when the Min-SE header field is not present), the
increase the value of the Session-Expires header. If the value of the proxy MUST NOT increase the value of the Session-Expires header
Session-Expires header is lower than the value of the Min-SE header field. If the value of the Session-Expires header field is lower than
(possibly because the proxy increased the value of the Min-SE header, the value of the Min-SE header field (possibly because the proxy
as described below), the proxy MUST increase the value of the increased the value of the Min-SE header field, as described below),
Session-Expires to make it equal to Min-SE. The proxy MUST NOT insert the proxy MUST increase the value of the Session-Expires header field
or modify the value of the "refresher" parameter in the Session- to make it equal to Min-SE header field value. The proxy MUST NOT
Expires header if the header was present in the received request. insert or modify the value of the "refresher" parameter in the
Session-Expires header field.
If the request contains a Supported header with a value "timer", the If the request contains a Supported header field with a value
proxy MAY reject the INVITE request if the session interval in the "timer", the proxy MAY reject the INVITE request with a 422 (Session
Session-Expires header is smaller than the minimum timer defined in Interval Too Small) response if the session interval in the Session-
the proxies local policy. The proxy does so by sending a 422 Session Expires header field is smaller than the minimum interval defined by
Timer Too Small response message. When sending the 422 response the proxy's local policy. When sending the 422 response, the proxy
message, the proxy MUST include a Min-SE header with the value of its MUST include a Min-SE header field with the value of its minimum
minimum timer. interval.
If the request doesn't indicate support for session timer, but the If the request doesn't indicate support for session timer, but the
request contains a session interval that is too small, the proxy request contains a session interval that is too small, the proxy
cannot usefully reject the request, as this would result in a call cannot usefully reject the request, as this would result in a call
failure. Rather, the proxy SHOULD insert a Min-SE header containing failure. Rather, the proxy SHOULD insert a Min-SE header field
its minimum timer. If a Min-SE header is already present, the proxy containing its minimum interval. If a Min-SE header field is already
SHOULD increase (but MUST NOT decrease) the value to equal its present, the proxy SHOULD increase (but MUST NOT decrease) the value
minimum timer. The proxy MUST then increase the Session-Expires value to equal its minimum interval. The proxy MUST then increase the
to be equal to the value in the Min-SE header, as described above. A Session-Expires header field value to be equal to the value in the
proxy MUST NOT insert a Min-SE header, or modify the value of an Min-SE header field, as described above. A proxy MUST NOT insert a
existing header, in a proxied request if that request contains a Min-SE header field, or modify the value of an existing header field,
Supported header with the value "timer". This is needed to protect in a proxied request if that request contains a Supported header
against certain denial of service attacks, described in Section 11. 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 session timer (and thus has possibly Assuming the proxy has requested a session timer (and thus has
inserted the Session-Expires header or reduced it), the proxy MUST possibly inserted the Session-Expires header field or reduced it),
remember that it is using session timer, and also remember the value the proxy MUST remember that it is using a session timer, and also
of the Session-Expires header from the proxied request. This MUST be remember the value of the Session-Expires header field from the
remembered for the duration of the transaction. The proxy MUST proxied request. This MUST be remembered for the duration of the
remember, for the duration of the transaction, whether the request transaction. The proxy MUST remember, for the duration of the
contained the Supported header with the value "timer". transaction, whether the request contained the Supported header field
with the value "timer".
If the request did not contain a Supported header with the value If the request did not contain a Supported header field with the
"timer", the proxy MAY insert a Require header into the request, with value "timer", the proxy MAY insert a Require header field into the
the value "timer". However, this is NOT RECOMMENDED. This allows the request, with the value "timer". However, this is NOT RECOMMENDED.
proxy to insist on session timer for the session. This header is not This allows the proxy to insist on session timer for the session.
needed if a Supported header was in the request; in this case, the This header field is not needed if a Supported header field was in
proxy can already be sure that the session timer can be used for the the request; in this case, the proxy can already be sure that the
session. session timer can be used for the session.
8.2 Processing of Responses 8.2 Processing of Responses
When the final response to the request arrives, it is examined by the When the final response to the request arrives, it is examined by the
proxy. proxy.
If the response does not contain a Session-Expires header, but the If the response does not contain a Session-Expires header field, but
proxy remembers that it requested a session timer in the request (by the proxy remembers that it requested a session timer in the request
inserting, modifying, or examining and accepting the Session-Expires (by inserting, modifying, or examining and accepting the Session-
in the proxied INVITE), this means that the UAS did not support the Expires header field in the proxied request), this means that the UAS
session timer. If the proxy remembers that the UAC did not support did not support the session timer. If the proxy remembers that the
session timer either, the proxy forwards the response upstream UAC did not support session timer either, the proxy forwards the
normally. There is no session expiration for this call leg. If, response upstream normally. There is no session expiration for this
however, the proxy remembers that the UAC did support session timer, session. If, however, the proxy remembers that the UAC did support
additional processing is needed. session timer, additional processing is needed.
Because there is no Session-Expires or Require in the response, the Because there is no Session-Expires or Require header field in the
proxy knows it is the first session-timer-aware proxy to receive the response, the proxy knows it is the first session-timer-aware proxy
response. This proxy MUST insert a Session-Expires header into the to receive the response. This proxy MUST insert a Session-Expires
response with the value it remembered from the forwarded request. It header field into the response with the value it remembered from the
MUST set the value of the "refresher" parameter to "uac". The proxy forwarded request. It MUST set the value of the "refresher" parameter
MUST also insert the Require header into the response, with the value to "uac". The proxy MUST insert the Require header field into the
"timer", before forwarding it upstream. response, with the value "timer", before forwarding it upstream.
If the response received contains a Session-Expires header, no If the received response contains a Session-Expires header field, no
additional response processing is needed. The response is processed modification of the response is needed.
normally.
In all cases, if the final response forwarded upstream by the proxy In all cases, if the 2xx response forwarded upstream by the proxy
contains a Session-Expires header, its value represents the session contains a Session-Expires header field, its value represents the
interval for the call leg associated with that response. The proxy session interval for the session associated with that response. The
computes the session expiration as the time when the 2xx response is proxy computes the session expiration as the time when the 2xx
forwarded upstream, plus the session interval. This session response is forwarded upstream, plus the session interval. This
expiration MUST update any existing session expiration for the call session expiration MUST update any existing session expiration for
leg. The refresher param in the Session-Expires header in the 2xx the session. The refresher parameter in the Session-Expires header
response forwarded upstream will be present, and it indicates which field in the 2xx response forwarded upstream will be present, and it
UA is performing the refreshes. There can be multiple 200 class indicates which UA is performing the refreshes. There can be multiple
responses to a single INVITE, each representing a different call leg, 2xx responses to a single INVITE, each representing a different
resulting in multiple session expirations, one for each call leg. dialog, resulting in multiple session expirations, one for each
session associated with each dialog.
In all cases, the proxy MUST NOT modify the value of the Session- The proxy MUST NOT modify the value of the Session-Expires header
Expires header received in the response (assuming one was present) field received in the response (assuming one was present) before
before forwarding it upstream. forwarding it upstream.
8.3 Session Expiration 8.3 Session Expiration
When the current time equals or passes the session expiration for a When the current time equals or passes the session expiration for a
call leg, the proxy MAY remove associated call state, and MAY free session, the proxy MAY remove associated call state, and MAY free any
any resources associated with the call. Unlike the UA, it MUST NOT resources associated with the call. Unlike the UA, it MUST NOT send a
send a BYE. BYE.
9 UAS Behavior 9 UAS Behavior
When a UAS receives an INVITE, the processing of that INVITE can When a UAS receives a session refresh request, the processing of that
logically be broken into two steps. In the first step, the UAS acts request can logically be broken into two steps. In the first step,
as a "virtual proxy", and follows the rules specified in Section 8.1 the UAS acts as a "virtual proxy", and follows the rules specified in
as if it were a proxy. This means that the same session timer Section 8.1 as if it were a proxy. This means that the same session
manipulations that a proxy can do, can also be done by a UAS. 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 Specifically, this means that it can insert or reduce the session
timer (but not below Min-SE if present), reject the request with a interval (but not below Min-SE header field value, if present),
422, and insert/increase the Min-SE, just as a proxy can. Of course, reject the request with a 422, and insert/increase the Min-SE header
rather than proxying the request, the "modified" request is passed field value, just as a proxy can. Of course, rather than proxying the
into the second step of processing, which we call the "virtual UAS" request, the "modified" request is passed into the second step of
processing. Viewing the UAS as the concatenation of a proxy and a processing, which we call the "virtual UAS" processing. Viewing the
UAS-specific processing component simplifies the specification of UAS as the concatenation of a proxy and a UAS-specific processing
behavior and guarantees consistency. This separation is for the component simplifies the specification of behavior and guarantees
purposes of defining behavior. It does not mandate that the consistency. This separation is for the purposes of defining
implementation work this way. behavior. It does not mandate that the implementation work this way.
Once the request is received by the virtual UAS (assuming it is 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 received; it may have been rejected with a 422 based on the rules in
Section 8.1), virtual UAS processing begins. If the virtual UAS Section 8.1), virtual UAS processing begins. From this point forward,
wishes to accept the call, it copies the value of the Session-Timer the term "UAS" refers to the "virtual UAS". If the UAS wishes to
from the request received from the first step into the 2xx response. accept request, it copies the value of the Session-Expires header
field from the request into the 2xx response. Of course, this request
The virtual UAS MUST then set the value of the refresher parameter in refers to the one received from the "virtual proxy".
the Session-Expires header present in a 200 class response. This
value specifies who will perform refreshes for the call leg. The
value is set based on the value of this parameter in the request and
on whether the UAC supports session timer. Table 3 defines how the
value in the response MUST be 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 column means that this particular
combination shouldn't happen, as its disallowed by the protocol.
In the fourth row of Table 3, since the UAC supports the session
timer, and so does the UAS, the UAS can elect for itself or the UAC
to perform the refreshes.
Note that the results of the above table are that the UACs choice of The UAS MUST set the value of the refresher parameter in the
refresher cannot be changed by the virtual UAS. 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
column means that this particular combination shouldn't happen, as
it's disallowed by the protocol.
UAC supports? refresher parameter refresher parameter UAC supports? refresher parameter refresher parameter
in request in response in request in response
N none uas N none uas
N uac NA N uac NA
N uas uas N uas NA
Y none uas or uac Y none uas or uac
Y uac uac Y uac uac
Y uas uas Y uas uas
Table 3: UAS Behavior Table 2: UAS Behavior
If the refresher parameter in the Session-Expires header in the 200 The fourth row of Table 2 describes a case where both the UAC and UAS
class response has a value of "uac", the UAS MUST place a Require support the session timer extension, and the UAC did not select who
header into the response with the value "timer". This is because the will perform refreshes. This allows the UAS to decide whether it, or
uac is performing refreshes and the response has to be processed for the UAC, will perform the refreshes. However, as the table indicates,
the UAC to know this. If the refresher parameter in the 200 class the UAS cannot overried the UAC's choice of refresher, if it made
response has a value of "uas", and the Supported header in the one.
request contained the value "timer", the UAS SHOULD place a Require
header 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 remembers the session interval for a call leg as the value of If the refresher parameter in the Session-Expires header field in the
the delta-time from the Session-Expires header in the most recent 2xx 2xx response has a value of "uac", the UAS MUST place a Require
response to INVITE on that call leg. It also remembers whether it, or header field into the response with the value "timer". This is
its peer, is the refresher on the leg. 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.
If the UAS must refresh a leg, it computes the session expiration for The UAS, just like the UAC, stores state for the session timer. This
that leg. The session expiration is the time of transmission of the state includes the session interval, the session expiration, and the
last 2xx INVITE response on that leg plus the session interval for identity of the refresher. This state is bound to the dialog used to
that leg. If UA wishes to continue with the session beyond the set up the session. The session interval is set to the value of the
session expiration, it MUST generate a refresh before the session delta-time from the Session-Expires header field in the most recent
expiration. It is RECOMMENDED that this refresh be sent once half the 2xx response to a session refresh request on that dialog. It also
session interval has elapsed. Additional procedures for this refresh remembers whether it, or its peer, is the refresher on the leg, based
are described in Section 10. 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.
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 10 Performing Refreshes
The side generating a refresh does so according to the UAC procedures The side generating a refresh does so according to the UAC procedures
defined in Section 7. Note that only a 2xx response to the INVITE defined in Section 7. Note that only a 2xx response to a session
extends the session expiration. This means that a UA could attempt a refresh request extends the session expiration. This means that a UA
refresh, and receive a 422 with a Min-SE that contains a value much could attempt a refresh, and receive a 422 response with a Min-SE
larger than the current session interval. The UA will still need to header field that contains a value much larger than the current
send an INVITE before the session expiration (which has not changed), session interval. The UA will still need to send an session refresh
even though this INVITE will contain a value of the Session-Expires request before the session expiration (which has not changed), even
that is much larger than the current session interval. though this request will contain a value of the Session-Expires that
is much larger than the current session interval.
If no response to a refreshing re-INVITE is received before the If no 2xx response to a session refresh request is received before
session expiration, the UA SHOULD send a BYE request to terminate the the session expiration, the UA SHOULD send a BYE request to terminate
call. It SHOULD send this BYE slightly before session expiration. The the session. It SHOULD send this BYE slightly before session
minimum of ten seconds and one third the session interval is expiration. The minimum of ten seconds and one third the session
RECOMMENDED. interval is RECOMMENDED.
For example, if the session interval is 120 seconds, one For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10 third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires. 10 seconds before the session expires.
Similarly, if the side not performing refreshes does not receive a Similarly, if the side not performing refreshes does not receive a
re-INVITE refreshing the session before the session expiration, they session refresh request before the session expiration, they SHOULD
SHOULD send a BYE to terminate the call, slightly before the session send a BYE to terminate the session, slightly before the session
expiration. The minimum of ten seconds and one third the session expiration. The minimum of ten seconds and one third the session
interval is RECOMMENDED. interval is RECOMMENDED.
Firewalls and NATs may be very unforgiving about allowing Firewalls and NAT ALGs may be very unforgiving about
SIP traffic to pass after the expiration time of the allowing SIP traffic to pass after the expiration time of
session. It is for this reason that the BYE should be sent the session. It is for this reason that the BYE should be
before the expiration. sent before the expiration.
11 Security Considerations 11 Security Considerations
The session timer introduces the capability of a proxy or UA element The session timer introduces the capability of a proxy or UA element
to force compliant clients to send refreshes at a rate of the to force compliant UAs to send refreshes at a rate of the element's
element's choosing. This introduces the possibility of rogue proxies choosing. This introduces the possibility of denial-of-service
or UASes introducing denial-of-service attacks. However, the attacks with significant amplification properties. These attacks can
mechanisms in this specification prevent that from happening. 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 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- generate refreshes at a rapid rate. To do so, it inserts a Session-
Expires header into an INVITE with a low duration and a refresher Expires header field into an INVITE with a low duration and a
parameter equal to uas. Assume it places a Supported header into the refresher parameter equal to uas. Assume it places a Supported header
request. Any proxy, or the UAS, which objects to this low timer will field into the request. Any proxy, or the UAS, which objects to this
reject the request with a 422, therefore preventing the attack. If no low timer will reject the request with a 422, therefore preventing
Supported header was present, the proxies will insert a Min-SE header the attack. If no Supported header field was present, the proxies
into the request before forwarding it. As a result, the UAS will not will insert a Min-SE header field into the request before forwarding
choose a session timer lower than the minimum acceptable one to all it. As a result, the UAS will not choose a session timer lower than
elements on the path. This too prevents the attack. 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 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 generate refreshes at a rapid rate. In that case, the UAC has to
support session timer. The initial INVITE arrives at the rogue UAS, support session timer. The initial INVITE arrives at the rogue UAS,
which returns a 2xx with a very small session interval. The UAC uses 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 this timer, and quickly sends a refresh. Section 7.1 requires the UAC
to copy the current session interval into the Session-Expires header to copy the current session interval into the Session-Expires header
in the request. This enables the proxies to see the current value. field in the request. This enables the proxies to see the current
The proxies will reject this request, and provide a Min-SE with a value. The proxies will reject this request, and provide a Min-SE
higher minimum. The UAC will then use this higher minimum. Note, that with a higher minimum. The UAC will then use this higher minimum.
if the proxies did not reject the request, but rather proxied the Note, that if the proxies did not reject the request, but rather
request with a Min-SE header, an attack would still be possible. The proxied the request with a Min-SE header field, an attack would still
UAS could discard this header in a 2xx response, and force the UAC to be possible. The UAS could discard this header field in a 2xx
continue to generate rapid requests. response, and force the UAC to continue to generate rapid requests.
In a similar fashion, a rogue proxy cannot force either the UAC or In a similar fashion, a rogue proxy cannot force either the UAC or
UAS to generate refreshes unless the proxy remains on the signaling UAS to generate refreshes unless the proxy remains on the signaling
path, and sees every request and response. path, and sees every request and response.
It is also RECOMMENDED that IP or transport level security is used 11.2 Outside Attacks
when communicating between proxies, and that requests with Session-
Expires headers only be accepted over these secure transports.
12 Examples
The following examples are meant to illustrate the functionality
associated with the session timer. In the interest of brevity, all
headers except Supported, Session-Expires, Min-SE and Require are
intentionally left out of the SIP messages.
12.1 Basic session timer
In this case, two UAs communicate directly, with no proxies. Both
support the session timer. The call is setup with a one hour
expiration. Half an hour later, the UAC refreshes the session.
Calling UA -> Called UA
INVITE
Supported: timer
Session-Expires: 3600
Calling UA <- Called UA
200 OK
Require: timer
Session-Expires: 3600;refresher=uac Called UA starts timer on send
Calling UA starts timer on receipt
Calling UA -> Called UA
ACK
1800 seconds later:
Calling UA -> Called UA
INVITE
Supported: timer
Session-Expires: 3600;refresher=uac
Calling UA <- Called UA
200 OK
Require: timer
Session-Expires: 3600;refresher=uac Called UA starts timer on send
Calling UA starts timer on receipt
Calling UA -> Called UA
ACK
3550 seconds later the called UA did not receive a re-INVITE. It
therefore considers the call terminated and sends a BYE:
Calling UA <- Called UA
BYE
Calling UA -> Called UA
200 OK
12.2 Basic negotiation of Session Time
In this configuration, two UAs talk through a single proxy server.
Both the proxy and the UAS reduce the session timer.
Calling UA -> proxy
INVITE
Supported: timer
Session-Expires: 3600
proxy -> Called UA
INVITE proxy wants a shorter timer
Supported: timer
Session-Expires: 180
proxy <- Called UA
200 OK Called UA wants a shorter timer
Session-Expires: 120;refresher=uac Called UA starts timer
Require: timer
Calling UA <- proxy
200 OK
Session-Expires: 120;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt
Calling UA -> proxy
ACK
proxy -> Called UA
ACK
For whatever reason, the calling UA decides not to refresh. So, after
110 seconds, it sends a BYE.
Calling UA -> proxy An element that can observe and modify a request or response in
BYE transit can force rapid session refreshes. To prevent that, requests
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.
proxy -> Called UA 12 IANA Considerations
BYE
proxy <- Called UA This extension defines two new header fields, a new response code,
200 OK and a new option tag. SIP [1] defines IANA procedures for registering
these.
Calling UA <- proxy 12.1 IANA Registration of Min-SE and Session-Expires Header Fields
200 OK
12.3 No Session-Expires Header in INVITE The following is the registration for the Min-SE header field:
In this scenario, the UA sends an INVITE without a Session-Expires RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
header and with a Supported header containing the option tag "timer". of this specification.]
Since the proxy wants session timer for the call, it adds the
Session-Expires header.
Calling UA -> proxy Header Name: Min-SE
INVITE No Session-Expires
Supported: timer
proxy -> Called UA Compact Form: none
INVITE
Supported: timer
Session-Expires: 3600 Proxy added Session-Expires
proxy <- Called UA The following is the registration for the Session-Expires header
200 OK field:
Session-Expires: 3600;refresher=uac Called UA starts timer on send
Require: timer
Calling UA <- proxy RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
200 OK of this specification.]
Session-Expires: 3600;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt
Calling UA -> proxy Header Name: Session-Expires
ACK
proxy -> Called UA Compact Form: x
ACK
12.4 Session timer without Calling UA Support 12.2 IANA Registration of the 422 (Session Interval Too Small) Response
Code
In this scenario, the calling UA sends and INVITE without a Session- The following is the registration for the 422 (Session Interval Too
Expires header and without a Supported header containing the option Small) response code:
tag "timer". Since the proxy wants session timer for the call it adds
Session-Expires header before proxying the INVITE to the called UA.
Calling UA -> proxy Response Code: 422
INVITE Default Reason Phrase: Session Interval Too Small
proxy -> Called UA RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
INVITE Proxy adds session expires of this specification.]
Session-Expires: 3600
proxy <- Called UA 12.3 IANA Registration of the "timer" Option Tag
200 OK Called UA wants a shorter timer
Session-Expires: 120;refresher=uas Called UA starts timer on send
Calling UA <- proxy The following is the registration for the "timer" option tag:
200 OK
Session-Expires: 120;refresher=uas Proxy starts timer on send
Called UA starts timer on receipt
Calling UA -> proxy Name: timer
ACK
proxy -> Called UA Description: This option tag is for support of the session timer
ACK 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.
Sixty seconds later, the called UA sends a re-INVITE. Note that the 13 Example Call Flow
called UA does support session timer, so it includes a
header{Supported} header in the request. The proxy adds the
Session-Expires and Require headers into the response from the calling
UA.
proxy <- Called UA Figure 1 gives an example of a call flow that makes use of the
INVITE session timer. In this example, both the UAC and UAS support the
Supported: timer session timer extension. The initial INVITE request generated by the
Session-Expires: 120;refresher=uac UAC, Alice (message 1), might look like:
Calling UA <- proxy INVITE sip:bob@biloxi.com SIP/2.0
INVITE Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Supported: timer Supported: timer
Session-Expires:120;refresher=uac Session-Expires: 50
Max-Forwards: 70
Calling UA -> proxy To: Bob <sip:bob@biloxi.com>
200 OK From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
proxy -> Called UA CSeq: 314159 INVITE
200 OK Contact: <sip:alice@pc33.atlanta.com>
Session-Expires: 120;refresher=uac Proxy updates timer on send Content-Type: application/sdp
Require: timer Called UA updates timer on receipt Content-Length: 142
proxy <- Called UA
ACK
Calling UA <- proxy
ACK
The Calling UA terminates the session for non timer
related reasons:
Calling UA -> proxy
BYE
proxy -> Called UA
BYE
proxy <- Called UA
200 OK
Calling UA <- proxy
200 OK
12.5 Session Timer without Called UA Support
In this scenario, the calling UA indicates that it supports the
session timer, but does not add the Session-Expires header into the
INVITE. The proxy adds it, but session timer is not supported by the
UAS. The call is still set up with a session timer, as all that is
required is for one of the user agents involved in the call leg to
understand the "timer" feature.
Calling UA -> proxy
INVITE
k: timer
proxy -> Called UA
INVITE proxy adds S-E header
k: timer
Session-Expires: 3600
proxy <- Called UA
200 OK Called UA doesn't understand session timer
Calling UA <- proxy
200 OK
Session-Expires: 3600;refresher=uac Proxy adds S-E and Require
Require: timer Proxy starts timer on send
Calling UA starts timer on receipt
Calling UA -> proxy
ACK
proxy -> Called UA
ACK
The UAC then re-invites, which is responded to with a 400 because the
new media streams were rejected. Since this is a re-INVITE, the
session is still active.
Calling UA -> proxy
INVITE
k: timer
Session-Expires: 3600;refresher=uac UA asks for timer this time
This is not mandatory
proxy -> Called UA
INVITE proxy does not reduce Session-Expires header
k: timer
Session-Expires: 3600;refresher=uac
proxy <- Called UA
400 Rejected Media Called UA doesn't understand session timer
Calling UA <- proxy
400 Rejected Media
Calling UA -> proxy
ACK
proxy -> Called UA
ACK
12.6 Neither UA Supports Session Timer
In this case, neither UA supports the session timer. However, one of
the proxies on the call setup path requests (but does not require)
it. The call completes without session timers.
Calling UA -> proxy
INVITE
proxy -> Called UA
INVITE proxy adds S-E header compact form
x: 3600
proxy <- Called UA
200 OK Called UA doesn't understand session timer
Calling UA <- proxy proxy doesn't add S-E since it knows Calling UA
200 OK doesn't support it
Calling UA -> proxy
ACK
proxy -> Called UA
ACK
12.7 Both UAs Support, Change in Roles (Alice's SDP not shown)
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):
In this case, both user agents support session timer. The initial SIP/2.0 422 Session Interval Too Small
INVITE from caller to callee results in refreshes being generated by Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
the caller. A re-INVITE sent from the callee changes that role so ;received=192.0.2.1
that the callee refreshes. 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
Calling UA -> proxy This response contains an Min-SE header field with the value of 3600.
INVITE Alice then retries the request. This time, the request contains a
Supported: timer Min-SE header, since Alice has received a 422 for other INVITE
Session-Expires: 3600 requests with the same Call-ID. The new request (message 4) might
look like:
proxy -> Called UA INVITE sip:bob@biloxi.com SIP/2.0
INVITE Proxy wants timer, no change in value Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Supported: timer Supported: timer
Session-Expires: 3600 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
proxy <- Called UA (Alice's SDP not shown)
200 OK Called UA supports timer
Session-Expires: 3600;refresher=uac Inserts Require, Session-Expires
Require: timer Called UA starts timer on send
Calling UA <- proxy Calling UA sees refresher=uac
200 OK It is refreshing
Session-Expires: 3600;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt
Calling UA -> proxy
ACK
proxy -> Called UA Proxy P1 record-routes. Since the session interval is now acceptable
ACK 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
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 | |
| |------------------------>|
The called UA (which is a UAC for this transaction) now sends a re- Figure 1: Example Session Timer Flow
INVITE. For whatever reason, it decides to switch roles by explicitly includes a Min-SE header field with the value of 4000. Once more,
designating the itself as the refresher. 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:
proxy <- Called UA INVITE sip:bob@biloxi.com SIP/2.0
INVITE Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
Supported: timer
Session-Expires: 3600;refresher=uac
Calling UA <- proxy
INVITE proxy wants timer, no change in value
Supported: timer Supported: timer
Session-Expires: 3600;refresher=uac Session-Expires: 4000
Min-SE: 4000
Calling UA -> proxy Max-Forwards: 70
200 OK Calling UA supports timer To: Bob <sip:bob@biloxi.com>
Session-Expires: 3600;refresher=uac Inserts Session-Expires From: Alice <sip:alice@atlanta.com>;tag=1928301774
Require: timer Calling UA updates timer on send Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
proxy -> Called UA Called UA sees 200 w/refresher=uac Contact: <sip:alice@pc33.atlanta.com>
200 OK It is refreshing Content-Type: application/sdp
Session-Expires: 3600;refresher=uac Proxy updates timer on send Content-Length: 142
Require: timer Called UA updates timer on receipt
proxy <- Called UA
ACK
Calling UA <- proxy
ACK
12.8 Proxy Rejects Timer (Alice's SDP not shown)
In this call flow, the calling UA sends an INVITE with a Session- P1 record-routes once again, but P2 does not (this wouldn't normally
Expires header that is low. This arrives at a proxy, which rejects it happen; presumably, if it asked for session timer, it would record-
with a 422 because it is too low. The proxy offers a larger minimum route the subsequent request). The UAS receives the request. It
timer. The calling UA retries with a new Session-Expires and with a copies the Session-Expires header from the request to the response,
Min-SE header. 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:
Calling UA -> Proxy SIP/2.0 200 OK
INVITE Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
;received=192.0.2.1
Require: timer
Supported: timer Supported: timer
Session-Expires: 10 UAC uses low timer Record-Route: sip:p1.atlanta.com;lr
Session-Expires: 4000;refresher=uac
Calling UA <- Proxy To: Bob <sip:bob@biloxi.com>;tag=9as888nd
422 Timer Too Low From: Alice <sip:alice@atlanta.com>;tag=1928301774
Session-Expires: 200 Proxy says minimum is 200s Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 142
Calling UA -> Proxy (Bob's SDP not shown)
ACK
Calling UA -> Proxy Alice generates an ACK (message 16), which is routed through P1 and
INVITE then to Bob. Since Alice is the refresher, around 3000 seconds later,
Supported: timer Alice sends an UPDATE request to refresh the session. Since this
Session-Expires: 300 UAC chooses larger SE request is part of an established dialog, and Alice has not received
Min-SE: 200 Minimum is 200 any 422 responses or requests on that dialog, there is no Min-SE
header field in her request (message 18):
Proxy -> Called UA UPDATE sip:bob@192.0.2.4 SIP/2.0
INVITE Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
Route: sip:p1.atlanta.com;lr
Supported: timer Supported: timer
Session-Expires: 250 Proxy lowers to 250 Session-Expires: 4000;refresher=uac
Min-SE: 200 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>
Proxy <- Called UA This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
200 the Session-Expires header field into the response. This is forwarded
Require: timer through P1, and arrives at Alice. The response she receives (message
Session-Expires: 200;refresher=uac UAS lowers to 200 21) might look like:
Calling UA <- Proxy SIP/2.0 200 OK
200 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
;received=192.0.2.1
Require: timer Require: timer
Session-Expires: 200;refresher=uac Session-Expires: 4000;refresher=uac
To: Bob <sip:bob@biloxi.com>;tag=9as888nd
Calling UA -> Proxy From: Alice <sip:alice@atlanta.com>;tag=1928301774
ACK Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Proxy -> Called UA Contact: <sip:bob@192.0.2.4>
ACK 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.
13 Acknowledgements 14 Acknowledgements
The authors wish to thank Brett Tate for his contributions to this The authors wish to thank Brett Tate for his contributions to this
work. work.
14 Author's Addresses 15 Author's Addresses
Steven R. Donovan Steven R. Donovan
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, Texas 75024 Plano, Texas 75024
email: sdonovan@dynamicsoft.com email: sdonovan@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
15 Bibliography 16 Normative References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
session initiation protocol," Request for Comments 2543, Internet protocol," Internet Draft, Internet Engineering Task Force, Feb.
Engineering Task Force, Mar. 1999. 2002. Work in progress.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [2] J. Rosenberg, "The session initiation protocol UPDATE method,"
transport protocol for real-time applications," Request for Comments Internet Draft, Internet Engineering Task Force, May 2002. Work in
1889, Internet Engineering Task Force, Jan. 1996. progress.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement [3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "The SIP supported header," [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
progress. Work in progress.
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.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 3
2 Terminology ......................................... 2 2 Terminology ......................................... 4
3 Protocol Overview ................................... 3 3 Overview of Operation ............................... 4
4 Session-Expires Header Field Definition ............. 5 4 Session-Expires Header Field Definition ............. 6
5 Min-SE Header Field Definition ...................... 6 5 Min-SE Header Field Definition ...................... 7
6 422 Response Code Definition ........................ 7 6 422 Response Code Definition ........................ 8
7 UAC Behavior ........................................ 7 7 UAC Behavior ........................................ 8
7.1 Generating an INVITE Request ........................ 7 7.1 Generating a Session Refresh Request ................ 8
7.1.1 Example ............................................. 9
7.2 Processing a 2xx Response ........................... 10 7.2 Processing a 2xx Response ........................... 10
7.3 Processing a 422 Response ........................... 11 7.3 Processing a 422 Response ........................... 11
8 Proxy Behavior ...................................... 11 8 Proxy Behavior ...................................... 11
8.1 Processing of requests .............................. 11 8.1 Processing of Requests .............................. 11
8.2 Processing of Responses ............................. 13 8.2 Processing of Responses ............................. 13
8.3 Session Expiration .................................. 14 8.3 Session Expiration .................................. 14
9 UAS Behavior ........................................ 14 9 UAS Behavior ........................................ 14
10 Performing Refreshes ................................ 15 10 Performing Refreshes ................................ 16
11 Security Considerations ............................. 16 11 Security Considerations ............................. 16
12 Examples ............................................ 17 11.1 Inside Attacks ...................................... 17
12.1 Basic session timer ................................. 17 11.2 Outside Attacks ..................................... 17
12.2 Basic negotiation of Session Time ................... 18 12 IANA Considerations ................................. 18
12.3 No Session-Expires Header in INVITE ................. 19 12.1 IANA Registration of Min-SE and Session-Expires
12.4 Session timer without Calling UA Support ............ 20 Header Fields .................................................. 18
12.5 Session Timer without Called UA Support ............. 22 12.2 IANA Registration of the 422 (Session Interval Too
12.6 Neither UA Supports Session Timer ................... 23 Small) Response Code ........................................... 18
12.7 Both UAs Support, Change in Roles ................... 24 12.3 IANA Registration of the "timer" Option Tag ......... 19
12.8 Proxy Rejects Timer ................................. 25 13 Example Call Flow ................................... 19
13 Acknowledgements .................................... 26 14 Acknowledgements .................................... 24
14 Author's Addresses .................................. 26 15 Author's Addresses .................................. 24
15 Bibliography ........................................ 27 16 Normative References ................................ 24
17 Informative References .............................. 25
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/