draft-ietf-sip-session-timer-04.txt   draft-ietf-sip-session-timer-05.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft S.Donovan,J.Rosenberg Internet Draft S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-04.txt dynamicsoft draft-ietf-sip-session-timer-05.txt dynamicsoft
November 22, 2000 July 20, 2001
Expires: May 2001 Expires: February 2002
The SIP Session Timer The SIP 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
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
The list of Internet-Draft Shadow Directories can be accessed at 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 proposes an extension to the Session Initiation
Protocol (SIP). This extension allows for a periodic refresh of SIP Protocol (SIP). This extension allows for a periodic refresh of SIP
sessions through a re-INVITE. The refresh allows both user agents and sessions through a re-INVITE. The refresh allows both user agents and
proxies to determine if the SIP session is still active. The proxies to determine if the SIP session is still active. The
extension defines a new general header, Session-Expires, which extension defines two new general headers, Session-Expires, which
conveys the lifetime of the session. conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer.
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1], does not currently define The Session Initiation Protocol (SIP) [1], does not currently define
a keepalive mechanism. The result is that call stateful proxies will a keepalive mechanism. The result is that call stateful proxies will
not always be able to determine whether a call is still active or not always be able to determine whether a call is still active or
not. For instance, when a user agent fails to send a BYE message at not. For instance, when a user agent fails to send a BYE message at
the end of a session, or the BYE message gets lost due to network the end of a session, or the BYE message gets lost due to network
problems, a call stateful proxy will not know when the session has problems, a call stateful proxy will not know when the session has
ended. In this situation, the call stateful proxy will retain state ended. In this situation, the call stateful proxy will retain state
skipping to change at page 2, line 30 skipping to change at page 2, line 31
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 [2]. However, it is
desirable to separate SIP call liveness from the details of the desirable to separate SIP call liveness from the details of the
particular session. particular session.
Another important application of the session timer is in NAT and Another application of the session timer is in the construction of a
firewall control [3]. In order for SIP to flow through a NAT or SIP NAT ALG. The ALG embedded in a NAT will need to maintain state
firewall, holes and/or address bindings must be dynamically created for the duration of a call. This state must eventually be removed.
to allow the media for the session to flow. These holes and/or
address bindings represent state which must be eventually removed.
Relying on a BYE to trigger the removal of state, besides being Relying on a BYE to trigger the removal of state, besides being
unreliable, introduces a potential denial of service attack. 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, are
used to keep the session active. The extension is sufficiently used to keep the session active. The extension is sufficiently
backwards compatible with SIP that it works so long as either one of backwards compatible with SIP that it works so long as either one of
the two participants in a call leg understand the extension. A new the two participants in a call leg understand the extension. Two new
general header, the Session-Expires header, is defined. It conveys general headers, Session-Expires and Min-SE, are defined. Session-
the expiration time of the session. Expires conveys the duration of the session, and Min-SE conveys the
minimum allowed value for the session expiration.
2 Protocol Overview 2 Protocol Overview
UACs which support the session timer extension defined here MUST UACs which support the session timer extension defined here MUST
include a Supported header in all requests, excepting ACK, containing include a Supported header in all requests, excepting ACK, containing
the option tag "timer" [4]. When a UAC makes a call, it MAY include a the option tag "timer" [3]. When a UAC makes a call, it MAY include a
Session-Expires header in the INVITE request. The presence of the Session-Expires header in the INVITE request. The presence of the
Session-Expires header indicates that the UAC wishes to use the Session-Expires header indicates that the UAC wishes to use the
session timer for this call. Its value indicates the desired session timer for this call. Its value indicates the desired
expiration time of the session. expiration time of the session. The UAC MAY include the "refresher"
parameter in the Session-Expires header with the value "uac". This
indicates that the caller will perform refreshes for the session.
Proxies on the signaling path may have their own requirements for the Proxies on the signaling path may have their own requirements for the
refresh interval of the session. If the Supported header in the refresh interval of the session. If no Session-Expires was present,
request lists the option tag "timer", a proxy can be certain the UAC the proxy MAY insert one if it so desires. If one was present, the
understands the session timer. In this case, if no Session-Expires proxy can lower its value, but not to a value lower than the value in
was present, the proxy can insert one if it so desires. If one was the Min-SE header in the request, if present. The proxy MUST NOT
present, the proxy can lower, but not increase, the expiration time increase the value of the Session-Expires header. The proxy remembers
of the session. The proxy remembers the value of Session-Expires it the value of Session-Expires that was finally used in the request.
placed into the request, and also remembers that the UAC supported The proxy also notes whether the UAC supports session timer, based on
session timer. The UAC will ultimately be responsible for sending the whether the Supported header was present with the tag "timer". In all
refreshes for this call leg. cases, the proxy MUST NOT insert or modify the value of the
"refresher" parameter in the Session-Expires header.
If the Supported header was absent from the request, or was present If the proxy wishes to insist that the call is only established if
but didn't include the tag "timer", the proxy knows the UAC cannot the UAS supports session timer, it MAY insert a Require header into
generate refreshes, but the called party may be able to. If no the request, with the value "timer", although this is NOT
Session-Expires was present, the proxy can insert one if it so RECOMMENDED, since it eliminates the possibility of call
desires. If one was present, the proxy can lower, but not increase, establishment if the UAS does not support session timers.
the expiration time of the session. The proxy MUST remember the value
of Session-Expires it placed into the request, and also MUST remember
that the UAC did not support the session timer. The UAS may be
responsible for sending the refreshes for this call leg. If the proxy
wishes to insist that the call is only established if the UAS
supports session timer, it MAY insert a Require header into the
request, with the value "timer", although this is NOT RECOMMENDED,
since it eliminates the possibility of call establishment if the UAS
does not support session timers.
Eventually, the initial INVITE reaches the UAS. There are two cases - Eventually, the initial INVITE reaches the UAS. There are two cases -
the UAS supports session timer, or it does not. If it does, and the the UAS supports session timer, or it does not. If it does, and the
response is otherwise acceptable to the UAS, the UAS MUST copy the response is otherwise acceptable to the UAS, the UAS MUST copy the
Session-Expires into the 200 class response, or MAY add one into the Session-Expires into the 200 class response, or MAY add one into the
response if none was present in the request. They UAS MAY reduce the response if none was present in the request. They UAS MAY reduce the
session timer in the 200 class response. If the request also session timer in the 200 class response, but not lower than the value
contained the Supported header with the value "timer", the UAS knows in the Min-SE header, if present. The UAS also sets the value of the
that the UAC can do refreshes. To make sure the UAC is aware it must refresher parameter, based on rules in Section 7, which determines
actually do them, the UAS MUST add a Require header to the 200 class who will be generating the re-INVITEs for the refreshing. If the UAC
response, with the tag "timer", when the request contains a Require is doing refreshes, the UAS additionally inserts a Require header
header with tag "timer". The UAS does not perform the refreshes in into the 200 class response, with the tag "timer". This informs the
this case. If the request did not contain the Supported header with UAC that special processing is needed for this response.
the value "timer", the UAS knows the UAC cannot perform refreshes.
So, it assumes the responsibility. In this case, it MUST add the
value of the Session-Expires to the response, but it MUST NOT add a
Require header with value "timer". This is because the UAC does not
support the extension; the UAS cannot insist on its usage at the UAC,
which is what a Require header in the response would accomplish.
If the UAS does not support session timer, it behaves as a normal If the UAS does not support session timer, it behaves as a normal
UAS. It will, in this case, neither insert Session-Expires in the UAS. Because of this, any 200 class response it generates will not
response nor a Require header with value "timer". contain the Session-Expires or Require header with the tag "timer".
This response travels backwards through the proxies. When it reaches The 200 class response travels backwards through the proxies. When it
a proxy which remembers that it asked for session timer, the proxy reaches a proxy which remembers that it asked for session timer, the
examines the response. If the response did not contain a Session- proxy examines the response. If the response did not contain a
Expires header, but the proxy remembers that the UAC supported Session-Expires header (meaning the UAS does not support session
session timer, the proxy knows that the UAC supports session timer, timer), additional proxy processing is needed. If the proxy remembers
but the UAS does not. So, it inserts the Session-Expires header into that the UAC supported session timer, the proxy must return the value
the response and also adds a Require header with a value of "timer". of the session timer to the UAC. So, it inserts the Session-Expires
If the response the proxy received did have a Session-Expires header, header into the response (using the value it remembered inserting),
but no Require header with value "timer", the proxy knows that the sets the "refresher" parameter to "uac", and adds a Require header
UAS understands session timer, but not the UAC. It simply forwards with a value of "timer". If the proxy remembers that the UAC did not
this request upstream. If the proxy gets a response without Session- support session timer, the proxy knows that session timer cannot be
Expires, and the proxy remembers that the UAC did not support session used, since neither UAS nor UAC support it.
timer, the proxy knows that session timer cannot be used, since
neither UAS nor UAC support it. Finally, if the response contains the If the response received by the proxy does contain the Session-
Session-Expires and Require header with the value "timer", the proxy Expires header, the "refresher" parameter will indicate which side is
knows that both UAC and UAS support session timer, and that the UAC performing refreshes.
will be performing refreshes.
The response then arrives at the UAC. If it contains a Require header The response then arrives at the UAC. If it contains a Require header
with the value "timer", the UAC knows it is responsible for with the value "timer", the UAC knows that special processing of the
refreshes. The response will also contain a Session-Expires header, response is needed. The response will also contain a Session-Expires
and the value of that header is used as the interval for refreshes. header, and the value of that header is used as the interval for
If the response contains no Session-Expires header or Require header, refreshes. The refresher parameter indicates who will be performing
but the UAC had inserted a Session-Expires header into the request the refreshes. If it contains the value "uac", the UAC knows it is
(since it wanted a session timer), the UAC will also be responsible performing them. If it contains the value "uas", it knows that the
for refreshes. UAS is performing them.
The UAC then ACKs the INVITE. The Session-Expires MUST NOT be The UAC then ACKs the INVITE. The Session-Expires MUST NOT be
included in the ACK. included in the ACK.
If the calling UA is supposed to perform refreshes and wishes to keep Whichever side is supposed to perform the refreshes MUST send a re-
the session alive, it MUST send a re-INVITE before the expiration INVITE before the expiration time. This re-INVITE SHOULD contain a
time. This re-INVITE MAY contain a Session-Expires header. The Session-Expires header. The processing of this re-INVITE by proxies
processing of this re-INVITE by proxies and UAS is identical to that and UAS is identical to that of the initial INVITE.
of the initial INVITE, excepting that processing may also take place
for non-200 final responses.
If the called UA is supposed to perform refreshes and wishes to keep
the session alive, it MUST send a re-INVITE before the expiration
time. This re-INVITE MAY contain a Session-Expires header. The
processing of this re-INVITE by proxies and UAS is identical to that
of the initial INVITE, excepting that processing may also take place
for non-200 final responses.
If the calling UA or the called UA is not performing refreshes, and If the side not performing refreshes does not receive a re-INVITE
does not receive a re-INVITE refreshing the session before the refreshing the session before the session expires, they SHOULD send a
session expires, they SHOULD send a BYE to terminate the call. If a BYE to terminate the call. If a refreshing UA does not receive a
refreshing UA does not receive a response to the re-INVITE used to response to the re-INVITE used to refresh the session, it SHOULD send
refresh the session, it SHOULD send a BYE to terminate the call. a BYE to terminate the call. Similarly, if a proxy doesn't receive a
Similarly, if a proxy doesn't receive a re-INVITE before expiration re-INVITE before expiration of the session, it MAY remove associated
of the session, it MAY remove associated call state, and MAY free any call state, and MAY free any resources associated with the call.
resources associated with the call. Unlike the UA, it MUST NOT send a Unlike the UA, it MUST NOT send a BYE.
BYE.
3 Session-Expires Header Field Definition 3 Session-Expires Header Field Definition
The Session-Expires header conveys the expiration time for a SIP The Session-Expires header conveys the expiration time for a SIP
session described in the body of the message. It is placed only in session described in the body of the message. It is placed only in
INVITE requests, and is allowed in any final response to an INVITE. INVITE requests, and is allowed in any 200 class response to an
Like the SIP Expires header, it can contain either an absolute time INVITE. Like the SIP Expires header, it can contain either an
or a delta-time. If it contains an absolute time, this time indicates absolute time or a delta-time. If it contains an absolute time, this
the time at which a proxy or UA may safely destroy any state time indicates the time at which a proxy or UA may safely destroy any
associated with the call. If it contains a delta time, the expiration state associated with the call. If it contains a delta time, the
time of the session is defined as that delta plus the time at which expiration time of the session is defined as that delta plus the time
the header is observed in a final response. For example, if a UAS at which the header is observed in a final response. For example, if
generates a 200 OK response to a re-INVITE that contained a Session- a UAS generates a 200 OK response to a re-INVITE that contained a
Expires header with a value of 3600, the UAS computes the expiration Session-Expires header with a value of 3600, the UAS computes the
time of the session as one hour after the time when the 200 OK was expiration time of the session as one hour after the time when the
sent. For each proxy, the expiration time is one hour after the time 200 OK was sent. For each proxy, the expiration time is one hour
when the 200 OK was received or sent (assuming these two are after the time when the 2xx was received or sent (assuming these two
sufficiently close together). For the UAC, the expiration time is one are sufficiently close together). For the UAC, the expiration time is
hour after the receipt of the final response. Any entity that inserts one hour after the receipt of the final response.
a Session-Expires header with an absolute time MUST also insert a
Date header into the message. This ensures proper operation for Any entity that inserts a Session-Expires header with an absolute
devices that do not have access to absolute time. time MUST also insert a Date header into the message. This ensures
proper operation for devices that do not have access to absolute
time.
There is no absolute minimum session refresh interval. However, 30 There is no absolute minimum session refresh interval. However, 30
seconds is RECOMMENDED. In other words, SIP entites MUST be prepared minutes is RECOMMENDED. In other words, SIP entites MUST be prepared
to handle session refresh intervals of any duration, but entities to handle session refresh intervals of any duration, but entities
that insert the Session-Expires header SHOULD NOT choose times that that insert the Session-Expires header SHOULD NOT choose times that
result in intervals less than 30 seconds. result in intervals less than 30 minutes.
Small session timer values can be destructive to the network. They
cause excessive messaging traffic that affects both user agents and
proxy servers. They increase the possibility of re-INVITE collisions
(when both parties re-INVITE each other at the same time). Since the
primary purpose of session timer is to provide a means to time out
state in SIP elements, very small values won't generally be needed.
30 minutes was chosen since 95% of phone calls are less than this
duration. However, the 30 minute minimum is listed as a SHOULD, and
not a MUST, since the exact value for this number is dependent on
many network factors, including network bandwidths and latencies,
computing power, memory availability, network topology, and of
course, the application scenario. After all, SIP can set up any kind
of session, nut just a phone call. At the time of publication of this
document, 30 minutes seems appropriate. Advances in technologies may
result in the number being excessively large five years in the
future.
The syntax of the Session-Expires header is: The syntax of the Session-Expires header is:
Session-Expires = ("Session-Expires" | "x") ":" ( SIP-date | Session-Expires = ("Session-Expires" | "x") ":" ( SIP-date |
delta-seconds ) delta-seconds ) [refresher]
refresher = ";" "refresher" "=" "uas"|"uac"
OPEN ISSUE: Is there really any reason for absolute times?
It just complicates things, since all operations really
need to be done using the delta-seconds. Plus, it will
require a Date header, so that a proxy will have to
subtract the two to arrive at a delta-time anyway.
RECOMMENDATION: Remove absolute time.
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 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 initial INVITE. It MUST NOT use a value of "uas" in the initial
INVITE, since it doesn't know whether the UAS is capable of
refreshes. However, in a re-INVITE, it MAY use a value of "uas" if it
knows that the other side supports session timer.
Note that a compact form, the letter 'x', has been reserved for Note that a compact form, the letter 'x', has been reserved for
Session-Expires. Both SIP-Date and delta-seconds are defined in Session-Expires. Both SIP-Date and delta-seconds are defined in
Section 6.20 of RFC 2543 [1]. Section 6.20 of RFC 2543 [1].
Table 1 is an extension of tables 4 and 5 in [1] for the Session- Table 1 is an extension of tables 4 and 5 in [1] for the Session-
Expires header: Expires header:
where enc e-e ACK BYE CAN INV OPT REG where enc e-e ACK BYE CAN INV OPT REG
_____________________________________________________ _____________________________________________________
Session-Expires R n h - - - o - - Session-Expires R n h - - - o - -
Session-Expires r n h - - - o - - Session-Expires 2xx n h - - - o - -
Table 1: Summary of header fields. "o": optional "-": not applicable, Table 1: Summary of header fields. "o": optional "-": not applicable,
"R': request header, "r": response header, "g": general header, "*": "R': request header, "r": response header, "g": general header, "*":
needed if message body is not empty. A numeric value in the "type" needed if message body is not empty. A numeric value in the "type"
column indicates the status code the header field is used with. column indicates the status code the header field is used with.
4 UAC Behavior 4 Min-SE Header Field Definition
The Min-SE request header indicates the minimum value for the
duration of the session timer. It is in units of delta-seconds. An
INVITE for a particular call leg which has generated a 422 response
MUST contain the Min-SE header, and the value MUST be the largest
value amongst all Session-Expires values returned in 422 responses on
that leg. A proxy or UAS MUST NOT reduce the value of the session
timer below the value in this header, when present.
The syntax of the Min-SE header is:
Min-SE = "Min-SE" ":" delta-seconds
A UAC MAY include the Min-SE in an INVITE request, even if it never
received a 422 previously.
Table 2 is an extension of tables 4 and 5 in [1] for the Session-
Expires header:
where enc e-e ACK BYE CAN INV OPT REG
____________________________________________
Min-SE R n h - - - o - -
Table 2: Summary of header fields. "o": optional "-": 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.
5 UAC Behavior
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 (excepting ACK), listing include a Supported header in each request (excepting ACK), listing
the option tag "timer" [4]. It MUST do so even if the UAC is not the option tag "timer" [3]. It MUST do so even if the UAC is not
requesting keepalives for the call. requesting keepalives for the call.
If the UAC wishes to request keepalives for this call, it MUST If the UAC wishes to request keepalives for this call, it MUST
include a Session-Expires in the INVITE request used to initiate the include a Session-Expires in the INVITE request used to initiate the
call. The value of this header indicates the time when the UAC will call. The value of this header indicates the time when the UAC will
consider the call expired if no refresh is sent. If the request is consider the call expired if no refresh is sent. If the request is
being authenticated, the Session-Expires header MUST appear before being authenticated, the Session-Expires header MUST appear before
the Authorization or Proxy-Authorization headers. the Authorization or Proxy-Authorization headers. The UAC MAY include
the refresher parameter with value "uac" if it wishes to perform the
refreshes.
The UAC MAY include a Require in the request with the value "timer" The UAC MAY include a Require in the request with the value "timer"
to indicate that the UAS must support the session timer to to indicate that the UAS must support the session timer to
participate in the session. In addition, the UAC MAY include a participate in the session. In addition, the UAC MAY include a
Proxy-Require header in the request with the value "timer" to Proxy-Require header 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. extension. The Supported header containing "timer" MUST still be
included even if the Require or Proxy-Require headers are present
When the response to the initial INVITE request arrives, it may or containing "timer".
may not contain a Session-Expires header, and may or may not contain
a Require header with the value "timer". UACs MUST be prepared to
receive a Session-Expires header in a response even if none were
present in the request.
Table 2 describes the behavior of the UAC (in terms of handling
refreshes) after receiving a 200 class response to an initial INVITE,
or any final response to a re-INVITE, based on the headers present in
that response.
Require Session-Expires Behavior When a 2xx response to the initial INVITE request arrives, it may or
N N If request contained Session-Expires, may not contain a Require header with the value "timer". If it does,
UAC is performing refreshes. Otherwise, do nothing. the UAC MUST look for the Session-Expires header to process the
N Y UAS is performing refreshes. Do nothing. response.
Y N Should never happen. Do nothing.
Y Y UAC MUST perform refreshes.
Table 2: UAC Behavior If there was a Require header in the response with the value "timer",
the Session-Expires header will always be present. UACs MUST be
prepared to receive a Session-Expires header in a response even if
none were present in the request. The "refresher" parameter will be
present, indicating who will be performing the refreshes. If the
parameter contains the value "uac", the UAC will perform them. It is
possible that the UAC requested session timer (and thus included a
Session-Expires in the request, but there was no Require or Session-
Expires in the 200 class response. This will happen when only the UAC
supports session timer. In this case, the UAC needs to perform
keepalives. To do this, the UAC follows the procedures defined in
this specification as if the Session-Expires header were in the 200
class response, and its value was the same as the one in the request
(but with a refresher parameter of "uac").
If the UAC must refresh, it follows the following procedure. The UAC If the UAC must refresh, it computes the expiration time of the
computes the expiration time of the session. This is based on the session. This is based on the value of the Session-Expires in the
value of the Session-Expires in the response. If there is no response. If the Session-Expires contains an absolute time, that is
Session-Expires in the response, but the UAC is refreshing, the value the time of expiration. If it contains a delta-time, the expiration
from the request is used (this only happens when the UAC wants time is the time of reception of the response plus that delta time.
session timers, but none of the proxies, nor the UAS, want or support Let the difference in time between the reception of the response and
it). If the Session-Expires contains an absolute time, that is the the session expiration time be called the refresh interval. Note that
time of expiration. If it contains a delta-time, the expiration time
is the time of reception of the response plus that delta time. Let
the difference in time between the reception of the response and the
session expiration time be called the refresh interval. Note that
this expiration applies only to the call leg associated with the this expiration applies only to the call leg associated with the
response. It is explicitly allowed for there to be differing session response. It is explicitly allowed for there to be differing session
timers (or none at all) on differing call legs, in the case where timers (or none at all) on differing call legs, in the case where
there are multiple 2xx OK responses to an initial INVITE with there are multiple 2xx OK responses to an initial INVITE with
different tags in the To field. different tags in the To field.
If UA wishes to continue with the session beyond the expiration, it If UA wishes to continue with the session beyond the expiration, it
MUST generate a refresh before the expiration time. It is RECOMMENDED MUST generate a refresh before the expiration time. It is RECOMMENDED
that this refresh be sent once half the refresh interval has elapsed. that this refresh be sent once half the refresh interval has elapsed.
This refresh is accomplished by sending a re-INVITE request on the The procedures for performing this refresh are described in Section
given call leg. Sending of the refresh (in terms of this extension), 8.
and processing the response are exactly identical to the rules above,
excepting that the processing applies to non-200 final responses, as
well as 200 class final responses.
A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that
is, this re-INVITE MAY contain an updated session description. In the
case where the re-INVITE contains an updated session description, the
session description MUST somehow indicate that it has changed. In the
case of SDP [5], this is accomplished by using a different value for
the origin field.
If the refreshing re-INVITE is used solely for refreshing, it MUST
still contain a session description, unchanged from the previous
INVITE. 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.
If no response to a refreshing re-INVITE is received before the
expiration of the session, the UA SHOULD send a BYE request to
terminate the call. It SHOULD send this BYE slightly before
expiration of the session. The minimum of ten seconds and one third
the session interval is RECOMMENDED.
For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires.
Firewalls and NATs may be very unforgiving about allowing
SIP traffic to pass after the expiration time of the
session. It is for this reason that the BYE should be sent
before the expiration.
Note that it is possible that the calling UA is generating refreshes,
and then it receives a re-INVITE. After following the rules for UAS
described below, the calling UA now determines it is not supposed to
generate refreshes. The UA SHOULD cease generating refreshes in this
case, and let the other UA perform them. This also implies that the
responsibility for generating refreshes may change during a call.
This happens commonly in one specific case - both caller and callee
support session timer. The caller will be doing re-INVITEs initially.
If the callee re-INVITEs, it becomes the UAC for this transaction,
and the rules defined in this specification will result in a change
in refresh responsibility to the called party. In general, when both
parties support session timer, refreshes become the responsibility of
the party which performed the last INVITE transaction.
Note that it is possible for a UAS to believe that an INVITE is an If the response to the initial INVITE request is a 422 Session Timer
initial INVITE, and for the UAC to believe it is a re-INVITE. This Too Small response message then the UAC MAY retry the INVITE with a
happens when a UA crashes and reboots between refreshes. When the longer session timer value in the Session-Expires header. The UAC
refresh arrives at the rebooted UA, it decides to reject the call. MUST use a value that is bigger than any value returned in a
The UAS can detect that the re-INVITE is for an existing call by the Session-Expires header in any 422 response within the call leg. This
existence of the tag in the To field of the re-INVITE. In order to requires the UA to store the largest session timer duration returned
alert the UAC that it believes the call is now down (the UAC believes in any 422 for the duration of the call leg. This behavior is needed
this request to be a re-INVITE, and so a non-200 OK final response to prevent certain denial of service attacks, described in Section 9.
will not cause it to destroy the call), the UAS SHOULD include a
Session-Expires and Require into the non-200 response (assuming
session timer is supported by the UAC), with an immediate expiration
time.
5 Proxy Behavior 6 Proxy Behavior
Session expirations are mostly of interest to call stateful proxy Session expirations are mostly of interest to call stateful proxy
servers. However, a stateful proxy server MAY also follow the rules servers. However, a stateful proxy server MAY also follow the rules
described here. Stateless proxies MUST NOT attempt to request session described here. Stateless proxies MUST NOT attempt to request session
timers. In general, proxies which ask for session timers will timers. Proxies which ask for session timers SHOULD record-route,
record-route, since they won't receive refreshes if they don't. since they 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.
5.1 Processing of requests 6.1 Processing of requests
Due to local policy, a proxy may have guidelines about the desired Due to local policy, a proxy may have guidelines about the desired
maximum lifetime for a call initiated through it. When an initial maximum lifetime for a call initiated through it. When an initial
INVITE is received to establish a call, a proxy MAY insert a INVITE is received to establish a call, a proxy MAY insert a
Session-Expires header in the request before forwarding it, if none Session-Expires header in the request before forwarding it, if none
was present in the request. This Session-Expires header may contain was present in the request. This Session-Expires header may contain
any desired expiration time the proxy would like. If the request any desired expiration time the proxy would like, but not with a
already had a Session-Expires header, the proxy MAY reduce the value duration lower than the value in the Min-SE header in the request, if
in the Session-Expires header before forwarding the request, but MUST present.
NOT increase it.
If the request already had a Session-Expires header, the proxy MAY
reduce the value in the Session-Expires header, but MUST NOT set it
to a duration lower than the value in the Min-SE header in the
request, if present. The proxy MUST NOT increase the value of the
duration.
The proxy MAY reject the INVITE request if the requested session
timer value in the Session-Expires header is smaller than the minimum
value defined in the proxies local policy. The proxy does so by
sending a 422 Session Timer Too Small response message. When sending
the 422 response message, the proxy MUST include a Session-Expires
header with a value for the session timer that is acceptable to the
proxy.
Assuming the proxy wishes to use session timer (and thus has possibly Assuming the proxy wishes to use session timer (and thus has possibly
inserted the Session-Expires header or reduced it), the proxy MUST inserted the Session-Expires header or reduced it), the proxy MUST
remember that it is using session timer, and also remember the value remember that it is using session timer, and also remember the value
in the request it forwarded, until the final response to the request of the Session-Expires header it placed in the proxied request. This
arrives, or the transaction times out. If the request also contained MUST be remembered for the duration of the transaction. The proxy
the Supported header with the value "timer", the proxy MUST remember MUST remember, for the duration of the transaction, whether the
this as well. request contained the Supported header 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 with the value
"timer", the proxy MAY insert a Require header into the request, with "timer", the proxy MAY insert a Require header into the request, with
the value "timer". However, this is NOT RECOMMENDED. This allows the the value "timer". However, this is NOT RECOMMENDED. This allows the
proxy to insist on session timer for the session. This header is not proxy to insist on session timer for the session. This header is not
needed if a Supported header was in the request; in this case, the needed if a Supported header was in the request; in this case, the
proxy can already be sure that the session timer can be used for the proxy can already be sure that the session timer can be used for the
session. session.
5.2 Processing of Responses 6.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. There are four cases. proxy. There are four cases.
CASE I: UAC supports, UAS doesn't. In this case, the request CASE I: UAC supports, UAS doesn't. In this case, the request
forwarded by the proxy contained a Session-Expires header forwarded by the proxy contained a Session-Expires header
(possibly inserted by the proxy). Recall that all proxies (possibly inserted by the proxy). Recall that all proxies
interested in session timer MUST remember the value of the interested in session timer MUST remember the value of the
timer in the forwarded request, in addition to whether the timer in the forwarded request, in addition to whether the
UAC supports it. Handling of the response for this scenario UAC supports it. Handling of the response for this scenario
depends on whether the session timer aware proxy is the one depends on whether the session timer aware proxy is the one
closest to the UAS. For the proxy closest to the UAS, the closest to the UAS, amongst all proxies which requested
final response to the INVITE does not contain a Session- session timer.
Expires header, nor does it contain a Require header with
the option tag "timer". The proxy MUST insert a Session- When the UAS sends the response, it will not contain a
Expires header into the response with the value it Session-Expires or Require header. This response is
remembered from the forwarded request. The proxy MUST also forwarded upstream, and it will eventually arrive at a
insert the Require header into the response, with the value proxy which was interested in session timers. Because there
is no Session-Expires or Require in the response, the proxy
knows it is the first session-timer-aware proxy to receive
the response. This proxy MUST insert a Session-Expires
header into the response with the value it remembered from
the forwarded request. It MUST set the value of the
"refresher" parameter to "uac". The proxy MUST also insert
the Require header into the response, with the value
"timer", before forwarding it upstream. The value of the "timer", before forwarding it upstream. The value of the
Session-Expires in the forwarded response represents the Session-Expires in the forwarded response represents the
expiration time of the session. For other proxies, the expiration time of the session. For other proxies, the
response will already contain the Session-Expires and response will already contain the Session-Expires and
Require header, so that this cae is indistinguishable from Require header, so that this case is indistinguishable from
CASE IV. CASE IV.
CASE II: UAC doesn't support, UAS doesn't support. In this case, CASE II: UAC doesn't support, UAS doesn't support. In this case,
the final response has no Session-Expires header, and the the final response has no Session-Expires header, and the
proxy remembers that the UAC did not support the session proxy remembers that the UAC did not support the session
timer. The proxy forwards the response upstream normally. timer. The proxy forwards the response upstream normally.
There are no session timers for this call leg. There are no session timers for this call leg.
CASE III: UAS supports, UAC doesn't. In this case, the final CASE III: UAS supports, UAC doesn't. In this case, the final
response contains a Session-Expires header, but no Require response contains a Session-Expires header with the
header with the tag "timer". The proxy remembers that the refresher parameter set to "uas". The proxy forwards the
UAC did not support session timers. The UAS will perform response upstream.
refreshes in this case. The proxy forwards the response
upstream.
CASE IV: UAC supports, UAS supports. In this case, the final CASE IV: UAC supports, UAS supports. In this case, the final
response contains a Session-Expires header and a Require response contains a Session-Expires header. The refresher
header with the tag "timer". The UAC performs refreshes in parameter indicates who is performing the refreshes. This
this case. This case will also occur when the UAC supports case will also occur when the UAC supports session timer,
session timer, and the UAS doesn't, but a downstream proxy and the UAS doesn't, but a downstream proxy had recognized
had recognized this as CASE I and inserted the Session- this as CASE I and inserted the Session-Expires and Require
Expires and Require headers into the response. The proxy headers into the response. The proxy forwards the response
forwards the response upstream. upstream.
In all cases, if the final response forwarded upstream by the proxy In all cases, if the final response forwarded upstream by the proxy
contains a Session-Expires header, its value represents the contains a Session-Expires header, its value represents the
expiration time of the session for the call leg associated with that expiration time of the session for the call leg associated with that
response. Note that there can be multiple 200 class responses to a response. There can be multiple 200 class responses to a single
single INVITE, each representing a different call leg, resulting in INVITE, each representing a different call leg, resulting in multiple
multiple session timers, one for each call leg. session timers, one for each call leg.
In all cases, the proxy MUST NOT modify the value of the Session- In all cases, the proxy MUST NOT modify the value of the Session-
Expires header received in the response (assuming one was present) Expires header received in the response (assuming one was present)
before forwarding it upstream. before forwarding it upstream.
The expiration of the call leg will occur at the time indicated in The expiration of the call leg will occur at the time indicated in
the Session-Expires header. If the Session-Expires header contains a the Session-Expires header. If the Session-Expires header contains a
delta-time, the expiration time is the time of receipt of the final delta-time, the expiration time is the time of receipt of the final
response, plus that delta time. response, plus that delta time.
Re-INVITE requests may arrive from either UA, refreshing the session Re-INVITE requests may arrive from either UA, refreshing the session
and extending the expiration time. Processing of these re-INVITEs by and extending the expiration time. Processing of these re-INVITEs by
a proxy is identical to the procedure for processing the initial a proxy is identical to the procedure for processing the initial
INVITE, except for the fact that processing includes any final INVITE.
response, not just 200 class.
If the session expires without having seen a response to a re-INVITE, If the session expires without having seen a response to a re-INVITE,
the proxy MAY consider the call leg terminated. This means it MAY the proxy MAY consider the call leg terminated. This means it MAY
flush any state associated with that call leg. flush any state associated with that call leg.
Note that a proxy MUST NOT send a BYE request once the session Note that a proxy MUST NOT send a BYE request once the session
expires. expires.
6 UAS Behavior 7 UAS Behavior
When a UAS receives an INVITE for a new call, and that INVITE When a UAS receives an INVITE for a new call, and that INVITE
contains a Session-Expires header, the UAS MUST place a Session- contains a Session-Expires header, the UAS MUST place a Session-
Expires header in a 200 OK response (assuming the UAS accepts the Expires header in a 200 class response (assuming the UAS accepts the
call). The UAS MAY reduce the expiration time when it places this call). The UAS MAY reduce the expiration time when it places this
header into the response, but it MUST NOT increase it. If the inital header into the response, but MUST NOT set it to a duration lower
INVITE did not contain a Session-Expires header, but it did contain a than the value in the Min-SE header in the request, if present. The
Supported header containing the option tag "timer", the UAS MAY UAS MUST NOT increase the value of the duration.
insert a Session-Expires header into the response. This header MAY
have any desired expiration time.
If the UAS places a Session-Expires header into the response, and the The UAS MAY reject the INVITE request if the requested session timer
request contained a Supported header with the value "timer", the UAS value in the Session-Expires header is smaller than the minimum value
MUST place a Require header into the response with the value "timer". defined in UAS local policy. The UAS does so by sending a 422 Session
In this case, the UAC will generate the refreshes. Timer Too Small response message. When sending the 422 response
message, the UAS MUST include a Session-Expires header with a value
that is acceptable to it.
If the UAS places a Session-Expires header into the response, and the If the inital INVITE did not contain a Session-Expires header, and
request did not contain a Supported header with the value "timer", the UAS wishes to use refreshes for the session, it MUST insert a
the UAS MUST NOT place a Require header into the response with the Session-Expires header into the response. This header MAY have any
value "timer". In this case, the UAS will generate the refreshes. desired expiration time greater than the value in the Min-SE header
from the request, if present.
These cases are summarized in Table 3. The table indicates the The UAS MUST set the value of the refresher parameter in the
behavior of the UAS, assuming it supports session timers, as a Session-Expires header present in a 200 class response. This value
function of the presence of the headers in the received request. 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 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 its disallowed by the protocol.
Supported Session-Expires Behavior UAC supports? refresher parameter refresher parameter
N N If response contains Session-Expires, UAS refreshing. in request in response
Otherwise, do nothing. N none uas
N Y Copy Session-Expires to response. N uac NA
May reduce. UAS refreshing. N uas NA
Y N MAY add Session-Expires to response. Y none uas or uac
If added, MUST add Require to response. Y uac uac
UAC refreshing. Y uas uas
Y Y Copy Session-Expires to response.
May reduce. Add Require to response.
UAC refreshing.
Table 3: UAS Behavior Table 3: UAS Behavior
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.
If the refresher parameter in the Session-Expires header in the 200
class response has a value of "uac", the UAS MUST place a Require
header into the response with the value "timer".
If the UAS is generating refreshes, it computes the expiration time If the UAS is generating refreshes, it computes the expiration time
of the session based on the value of the Session-Expires header in of the session based on the value of the Session-Expires header in
the response it sent. This expiration applies only to the call leg the response it sent. If the Session-Expires contains an absolute
associated with that final response. The processing from this point time, that is the time of expiration. If it contains a delta-time,
is as described in section 4 once the UAC determined it was the expiration time is the time of transmission of the response plus
performing refreshes. that delta time. Let the difference in time between the transmission
of the response and the session expiration time be called the refresh
interval. Note that this expiration applies only to the call leg
associated with the response.
As described in Section 4, the refreshing UA will send periodic re- If the UA wishes to continue with the session beyond the expiration,
INVITEs to refresh the session. A UAS MUST be prepared to receive and it MUST generate a refresh before the expiration time. It is
process these re-INVITEs. Processing of the re-INVITE, as far as the RECOMMENDED that this refresh be sent once half the refresh interval
session timer is concerned, is identical to the rules for the initial has elapsed. The procedures for performing this refresh are described
INVITE, described above, except that processing applies to any final in Section 8.
response, not just 200 OK. Note that if the 200 OK to the re-INVITE
has no Session-Expires, no expiration time exists for the session. 8 Performing Refreshes
This can happen if the proxies and/or UAS change their mind about
session timers, and decide they no longer wish to use them. Since The refresh is accomplished by sending a re-INVITE request on the
each INVITE is treated independently, the proxies or UAS do not need given call leg. Sending of the refresh (in terms of this extension),
to continue requesting session timer event though they did so the and processing the response are exactly identical to the rules in
first time. Sections 5 and 7. However, as discussed in Section 4, if the UAC
received any 422 responses for this call leg, the re-INVITE MUST
contain a Min-SE header with the largest of all durations returned in
all 422 responses on that call leg. The re-INVITE SHOULD contain a
Session-Expires header, with an duration equal to the last duration.
For example, if the initial INVITE sequence results in a session
timer of 200 seconds, the re-INVITE SHOULD contain a session timer
with a value of 200 seconds. The re-INVITE MAY contain a different
expiration, but this should only be done if the UA wishes to change
the session expiration.
If the Session-Timer is placed in the re-INVITE, the refresher
parameter SHOULD be present, and SHOULD identify the element
currently responsible for refreshes. This means that a re-INVITE may
have a refresher parameter with value "uas", if the element not
performing refreshes sends a re-INVITE for some other, non-session-
timer reason. The refresher parameter MAY be set to identify the
element not performing refreshes at this time. This will result in a
change of roles.
If the 200 OK to the re-INVITE has no Session-Expires, no expiration
time exists for the session. This can happen if the proxies and/or
UAS change their mind about session timers, and decide they no longer
wish to use them. Since each INVITE is treated independently, the
proxies or UAS do not need to continue requesting session timer even
though they did so the first time.
A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that
is, this re-INVITE MAY contain an updated session description. In the
case where the re-INVITE contains an updated session description, the
session description MUST somehow indicate that it has changed. In the
case of SDP [4], this is accomplished by using a different value for
the origin field.
If the refreshing re-INVITE is used solely for refreshing, it SHOULD
still contain a session description, unchanged from the previous
INVITE. 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.
If no response to a refreshing re-INVITE is received before the
expiration of the session, the UA SHOULD send a BYE request to
terminate the call. It SHOULD send this BYE slightly before
expiration of the session. The minimum of ten seconds and one third
the session interval is RECOMMENDED.
For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires.
Firewalls and NATs may be very unforgiving about allowing
SIP traffic to pass after the expiration time of the
session. It is for this reason that the BYE should be sent
before the expiration.
It is possible that the calling UA is generating refreshes, and then
it receives a re-INVITE. After following the rules for UAS described
above, the calling UA now determines it is not supposed to generate
refreshes. The UA SHOULD cease generating refreshes in this case, and
let the other UA perform them. This also implies that the
responsibility for generating refreshes may change during a call.
This happens commonly in one specific case - both caller and callee
support session timer. The caller will be doing re-INVITEs initially.
If the callee re-INVITEs, it becomes the UAC for this transaction,
and the rules defined in this specification may result in a change in
refresh responsibility to the called party. In general, when both
parties support session timer, refreshes become the responsibility of
the party which performed the last INVITE transaction.
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.
Without From tags, 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.
9 Security Considerations
7 Security Considerations
The session timer introduces the capability of a proxy to effectively The session timer introduces the capability of a proxy to effectively
force clients to send refreshes at a rate of the proxies choosing. It force clients to send refreshes at a rate of the proxies choosing. It
can also force the clients to send a BYE by setting the expirations can also force the clients to send a BYE by setting the expirations
to times that are too short. This introduces the possibility of rogue to times that are too short. This introduces the possibility of rogue
proxies introducing denial-of-service attacks. Use of short refresh proxies or UASes introducing denial-of-service attacks. Use of short
intervals allows the proxies to create network load. The session refresh intervals allows the proxies or UAS to create network load.
timer mechanism allows the proxy to be able to terminate established This is preventable using the 422 response and Min-SE header
calls - a capability a normal proxy doesn't have in [1]. mechanism. Any proxy or the UAS can reject an INVITE with a low
session timer, and the UAC will then include this minimum in the
Min-SE header in subsequent requests. No compliant proxy will then
use a session timer with a lower value. Rogue proxies could strip the
Min-SE, but in this case, UA configuration should ideall prevent the
attacks by refusing to use a session timer lower than a specific
value (30 minutes is recommended here).
As a result of these potential attacks, it is RECOMMENDED that IP or It is also RECOMMENDED that IP or transport level security is used
transport level security is used when communicating between proxies, when communicating between proxies, and that requests with Session-
and that requests with Session-Expires headers only be accepted over Expires headers only be accepted over these secure transports.
these secure transports.
8 Examples 10 Examples
The following examples are meant to illustrate the functionality The following examples are meant to illustrate the functionality
associated with the session timer. In the interest of brevity, all associated with the session timer. In the interest of brevity, all
headers excepting Supported, Session-Expires and Require are headers excepting Supported, Session-Expires, Min-SE and Require are
intentionally left out of the SIP messages. intentionally left out of the SIP messages.
8.1 Basic session timer 10.1 Basic session timer
In this case, two UAs communicate directly, with no proxies. Both In this case, two UAs communicate directly, with no proxies. Both
support the session timer. The call is setup with a two minute support the session timer. The call is setup with a two minute
session expiration. One minute later, the UAC refreshes the session. session expiration. One minute later, the UAC refreshes the session.
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120 Called UA starts session timer on send Session-Expires: 120;refresher=uac Called UA starts timer on send
Calling UA starts session timer on receipt Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
60 seconds later: 60 seconds later:
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120;refresher=uac
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120 Called UA starts session timer on send Session-Expires: 120;refresher=uac Called UA starts timer on send
Calling UA starts session timer on receipt Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
110 seconds later the called UA did not receive a re-INVITE. It 110 seconds later the called UA did not receive a re-INVITE. It
therefore considers the call terminated and sends a BYE: therefore considers the call terminated and sends a BYE:
Calling UA <- Called UA Calling UA <- Called UA
BYE BYE
Calling UA -> Called UA Calling UA -> Called UA
200 OK 200 OK
8.2 Basic negotiation of Session Time 10.2 Basic negotiation of Session Time
In this configuration, two UAs talk through a single stateful proxy In this configuration, two UAs talk through a single proxy server.
server (SPS). Both the SPS and the UAS reduce the session timer. Both the proxy and the UAS reduce the session timer.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 240
SPS -> Called UA proxy -> Called UA
INVITE SPS wants a shorter timer INVITE proxy wants a shorter timer
Supported: timer Supported: timer
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA proxy <- Called UA
200 OK Called UA wants a shorter timer 200 OK Called UA wants a shorter timer
Session-Expires: 120 Called UA starts timer Session-Expires: 120;refresher=uac Called UA starts timer
Require: timer Require: timer
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
Session-Expires: 120 Proxy starts timer on send Session-Expires: 120;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt Require: timer Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
For whatever reason, the calling UA decides not to refresh. So, after For whatever reason, the calling UA decides not to refresh. So, after
110 seconds, it sends a BYE. 110 seconds, it sends a BYE.
Calling UA -> SPS Calling UA -> proxy
BYE BYE
SPS -> Called UA proxy -> Called UA
BYE BYE
proxy <- Called UA
SPS <- Called UA
200 OK 200 OK
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
8.3 No Session-Expires Header in INVITE 10.3 No Session-Expires Header in INVITE
In this scenario, the UA sends an INVITE without a Session-Expires In this scenario, the UA sends an INVITE without a Session-Expires
header and with a Supported header containing the option tag "timer". header and with a Supported header containing the option tag "timer".
Since the proxy wants session timer for the call, it adds the Since the proxy wants session timer for the call, it adds the
Session-Expires header. Session-Expires header.
Calling UA -> SPS Calling UA -> proxy
INVITE No Session-Expires INVITE No Session-Expires
Supported: timer Supported: timer
SPS -> Called UA proxy -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Proxy added Session-Expires Session-Expires: 120 Proxy added Session-Expires
SPS <- Called UA proxy <- Called UA
200 OK 200 OK
Session-Expires: 120 Session-Expires: 120;refresher=uac Called UA starts timer on send
Require: timer Require: timer
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
Session-Expires: 120 Session-Expires: 120;refresher=uac Proxy starts timer on send
Require: timer Require: timer Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
8.4 Session timer without Calling UA Support 10.4 Session timer without Calling UA Support
In this scenario, the calling UA sends and INVITE without a Session- In this scenario, the calling UA sends and INVITE without a Session-
Expires header and without a Supported header containing the option Expires header and without a Supported header containing the option
tag "timer". Since the proxy wants session timer for the call it adds tag "timer". Since the proxy wants session timer for the call it adds
Session-Expires header before proxying the INVITE to the called UA. Session-Expires header before proxying the INVITE to the called UA.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
SPS -> Called UA proxy -> Called UA
INVITE SPS adds session expires INVITE Proxy adds session expires
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA proxy <- Called UA
200 OK Called UA wants a shorter timer 200 OK Called UA wants a shorter timer
Session-Expires: 120 Called UA starts timer Session-Expires: 120;refresher=uas Called UA starts timer on send
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
Session-Expires: 120 Proxy starts timer on send Session-Expires: 120;refresher=uas Proxy starts timer on send
Called UA starts timer on receipt
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
Sixty seconds later, the called UA sends a re-INVITE. Note that the Sixty seconds later, the called UA sends a re-INVITE. Note that the
called UA does support session timer, so it includes a called UA does support session timer, so it includes a
header{Supported} header in the request. The SPS adds the header{Supported} header in the request. The proxy adds the
Session-Expires and Require headers into the response from the calling Session-Expires and Require headers into the response from the calling
UA. UA.
SPS <- Called UA proxy <- Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120;refresher=uac
Calling UA <- SPS Calling UA <- proxy
INVITE INVITE
Supported: timer Supported: timer
Session-Expires:120 Session-Expires:120;refresher=uac
Calling UA -> SPS Calling UA -> proxy
200 OK 200 OK
SPS -> Called UA proxy -> Called UA
Session-Expires: 120
Require: timer
200 OK 200 OK
Session-Expires: 120;refresher=uac Proxy updates timer on send
Require: timer Called UA updates timer on receipt
SPS <- Called UA proxy <- Called UA
ACK ACK
Calling UA <- SPS Calling UA <- proxy
ACK ACK
The Calling UA terminates the session for non timer The Calling UA terminates the session for non timer
related reasons: related reasons:
Calling UA -> SPS Calling UA -> proxy
BYE BYE
SPS -> Called UA proxy -> Called UA
BYE BYE
SPS <- Called UA proxy <- Called UA
200 OK 200 OK
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
8.5 Session Timer without Called UA Support 10.5 Session Timer without Called UA Support
In this scenario, the calling UA indicates that it supports the In this scenario, the calling UA indicates that it supports the
session timer, but does not add the Session-Expires header into 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 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 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 required is for one of the user agents involved in the call leg to
understand the "timer" feature. understand the "timer" feature.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
k: timer k: timer
SPS -> Called UA proxy -> Called UA
INVITE SPS adds S-E header INVITE proxy adds S-E header
k: timer k: timer
Session-Expires: 180 Session-Expires: 180
proxy <- Called UA
SPS <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
Calling UA <- SPS Calling UA <- proxy
200 OK 200 OK
Session-Expires: 180 SPS adds Session-Expires and Require Session-Expires: 180;refresher=uac Proxy adds S-E and Require
Require: timer Require: timer Proxy starts timer on send
Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
The UAC then re-invites, which is responded to with a 400 because the 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 new media streams were rejected. Since this is a re-INVITE, the
session is still active, and thus the processing of the response to session is still active.
re-INVITE still occurs in the proxy.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
k: timer k: timer
Session-Expires: 180 UA asks for specific timer this time Session-Expires: 180;refresher=uac UA asks for timer this time
This is not mandatory This is not mandatory
SPS -> Called UA proxy -> Called UA
INVITE SPS does not reduce Session-Expires header INVITE proxy does not reduce Session-Expires header
k: timer k: timer
Session-Expires: 180 Session-Expires: 180;refresher=uac
SPS <- Called UA proxy <- Called UA
400 Rejected Media Called UA doesn't understand session timer 400 Rejected Media Called UA doesn't understand session timer
Calling UA <- SPS Calling UA <- proxy
400 Rejected Media 400 Rejected Media
Session-Expires: 180 SPS adds Session-Expires and Require
Require: timer
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
8.6 Proxy insists on session timer 10.6 Proxy insists on session timer
In this scenario, the calling UA does not support the session timer, In this scenario, the calling UA does not support the session timer,
but the SPS on the setup path insists on it by inserting a Require but the proxy on the setup path insists on it by inserting a Require
header. The UAS does not support the session timer either, so it header. The UAS does not support the session timer either, so it
rejects the request with a 420 as per standard RFC2543 extension rejects the request with a 420 as per standard RFC2543 extension
handling. This response is forwarded upstream towards the UAC. The handling. This response is forwarded upstream towards the UAC. The
UAC treats it as a normal 400 class response, and then ACKs it. In UAC treats it as a normal 400 class response, and then ACKs it. In
this case, the call cannot be established. this case, the call cannot be established.
It is slightly odd that a UAC will send a request without a It is slightly odd that a UAC will send a request without a
Require header, and yet get a 420 response back with an Require header, and yet get a 420 response back with an
Unsupported header. Normal UAs that don't support session Unsupported header. Normal UAs that don't support session
timer should handle this case correctly, treating it just timer should handle this case correctly, treating it just
as a normal 400 class response. as a normal 400 class response.
Note that proxy insertion of Require is NOT RECOMMENDED. Note that proxy insertion of Require is NOT RECOMMENDED.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
SPS -> Called UA proxy -> Called UA
INVITE SPS adds session expires INVITE proxy adds session expires
Require: timer SPS adds Require Require: timer proxy adds Require
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA proxy <- Called UA
420 Bad Extension 420 Bad Extension
Unsupported: timer Unsupported: timer
Calling UA <- SPS Calling UA <- proxy
420 Bad Extension 420 Bad Extension
Unsupported: timer Unsupported: timer
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
8.7 Neither UA Supports Session Timer 10.7 Neither UA Supports Session Timer
In this case, neither UA supports the session timer. However, one of In this case, neither UA supports the session timer. However, one of
the proxies on the call setup path requests (but does not require) the proxies on the call setup path requests (but does not require)
it. The call completes without session timers. it. The call completes without session timers.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
SPS -> Called UA proxy -> Called UA
INVITE SPS adds S-E header compact form INVITE proxy adds S-E header compact form
x: 180 x: 180
SPS <- Called UA proxy <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
Calling UA <- SPS SPS doesn't add S-E since it knows Calling UA Calling UA <- proxy proxy doesn't add S-E since it knows Calling UA
200 OK doesn't support it 200 OK doesn't support it
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
8.8 Both UAs Support, Change in Roles 10.8 Both UAs Support, Change in Roles
In this case, both user agents support session timer. The initial In this case, both user agents support session timer. The initial
INVITE from caller to callee results in refreshes being generated by INVITE from caller to callee results in refreshes being generated by
the caller. A re-INVITE sent from the callee changes that role so the caller. A re-INVITE sent from the callee changes that role so
that the callee refreshes. that the callee refreshes.
Calling UA -> SPS Calling UA -> proxy
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 240
SPS -> Called UA proxy -> Called UA
INVITE SPS wants timer, no change in value INVITE Proxy wants timer, no change in value
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 240
SPS <- Called UA proxy <- Called UA
200 OK Called UA supports timer 200 OK Called UA supports timer
Session-Expires: 240 Inserts Require, Session-Expires Session-Expires: 240;refresher=uac Inserts Require, Session-Expires
Require: timer Require: timer Called UA starts timer on send
Calling UA <- SPS Calling UA gets response with Require:timer Calling UA <- proxy Calling UA sees refresher=uac
200 OK It is refreshing 200 OK It is refreshing
Session-Expires: 240 Session-Expires: 240;refresher=uac Proxy starts timer on send
Require: timer Require: timer Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> proxy
ACK ACK
SPS -> Called UA proxy -> Called UA
ACK ACK
The called UA (which is a UAC for this transaction) now sends a re- The called UA (which is a UAC for this transaction) now sends a re-
INVITE: INVITE. For whatever reason, it decides to switch roles by explicitly
designating the itself as the refresher.
SPS <- Called UA proxy <- Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 240;refresher=uac
Calling UA <- SPS Calling UA <- proxy
INVITE SPS wants timer, no change in value INVITE proxy wants timer, no change in value
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 240;refresher=uac
Calling UA -> SPS Calling UA -> proxy
200 OK Calling UA supports timer 200 OK Calling UA supports timer
Session-Expires: 240 Inserts Require, Session-Expires Session-Expires: 240;refresher=uac Inserts Session-Expires
Require: timer Require: timer Calling UA updates timer on send
SPS -> Called UA Called UA gets response with Require:timer
proxy -> Called UA Called UA sees 200 w/refresher=uac
200 OK It is refreshing 200 OK It is refreshing
Session-Expires: 240 Session-Expires: 240;refresher=uac Proxy updates timer on send
Require: timer Called UA updates timer on receipt
proxy <- Called UA
ACK
Calling UA <- proxy
ACK
10.9 Proxy Rejects Timer
In this call flow, the calling UA sends an INVITE with a Session-
Expires header that is low. This arrives at a proxy, which rejects it
with a 422 because it is too low. The proxy offers a larger minimum
timer. The calling UA retries with a new Session-Expires and with a
Min-SE header.
Calling UA -> Proxy
INVITE
Supported: timer
Session-Expires: 10 UAC uses low timer
Calling UA <- Proxy
422 Timer Too Low
Session-Expires: 200 Proxy says minimum is 200s
Calling UA -> Proxy
ACK
Calling UA -> Proxy
INVITE
Supported: timer
Session-Expires: 300 UAC chooses larger SE
Min-SE: 200 Minimum is 200
Proxy -> Called UA
INVITE
Supported: timer
Session-Expires: 250 Proxy lowers to 250
Min-SE: 200
Proxy <- Called UA
200
Require: timer Require: timer
Session-Expires: 250;refresher=uac UAS lowers to 200
SPS <- Called UA Calling UA <- Proxy
200
Require: timer
Session-Expires: 250;refresher=uac
Calling UA -> Proxy
ACK ACK
Calling UA <- SPS Proxy -> Called UA
ACK ACK
9 Changes since -03 11 Acknowledgements
o Now handle the case where the UAC wants refreshes, but none of The authors wish to thank Brett Tate for his contributions to this
the proxies, nor the UAS, support it. Same in the reverse - work.
case where UAS wants it, but the UAC nor any of the proxies
want it.
o Added note about proxy insertion of Require resulting in a 420 12 Changes since -04
even though UAC didn't ask for any extensions.
o Added compact form o Added requirement for From tags with session timer, to handle
this crash and reboot case. Discussed when a UA would want to
recover calls this way.
o Specified conditions under which refresh responsibilities o Removed text about inserting Session-Expires:0 when you want
change. Also added an example showing this case. to indicate that the call is down. Rather, send a 481.
10 Author's Addresses o Made handling of a 481 a MUST for UAC.
o Added clarification to call flows on when timer is started and
updated.
o Added wording indicating that it is bad to do usage billing
using SIP.
o Added wording indicating that the UAS should not change the
SDP for a re-INVITE that is used solely for refreshing the
session timer.
o Added text about using 422 Session Timer Too Small message to
reject an INVITE with a session expiration value that is
smaller that policy at a proxy or UAC.
o Changed SPS to proxy in call flows
o Mentioned that low session timer values can lead to re-INVITE
glare.
o Added discussion of why minimum of 30 minutes is a SHOULD and
not a MUST.
o Added Min-SE header and related processing.
o Added refresher parameter to Session-Expires, which has
simplified processing.
13 Author's Addresses
Steven R. Donovan Steven R. Donovan
dynamicsoft dynamicsoft
5100 Tennyson Parkway, Suite 1200 5100 Tennyson Parkway
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
11 Bibliography 14 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments transport protocol for real-time applications," Request for Comments
1889, Internet Engineering Task Force, Jan. 1996. 1889, Internet Engineering Task Force, Jan. 1996.
[3] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through [3] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
firewalls and NATs," Internet Draft, Internet Engineering Task Force, Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in
Feb. 2000. Work in progress.
[4] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in
progress. progress.
[5] M. Handley and V. Jacobson, "SDP: session description protocol," [4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr. Request for Comments 2327, Internet Engineering Task Force, Apr.
1998. 1998.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
2 Protocol Overview ................................... 2 2 Protocol Overview ................................... 2
3 Session-Expires Header Field Definition ............. 5 3 Session-Expires Header Field Definition ............. 4
4 UAC Behavior ........................................ 6 4 Min-SE Header Field Definition ...................... 6
5 Proxy Behavior ...................................... 9 5 UAC Behavior ........................................ 7
5.1 Processing of requests .............................. 9 6 Proxy Behavior ...................................... 9
5.2 Processing of Responses ............................. 9 6.1 Processing of requests .............................. 9
6 UAS Behavior ........................................ 11 6.2 Processing of Responses ............................. 10
7 Security Considerations ............................. 12 7 UAS Behavior ........................................ 11
8 Examples ............................................ 13 8 Performing Refreshes ................................ 13
8.1 Basic session timer ................................. 13 9 Security Considerations ............................. 15
8.2 Basic negotiation of Session Time ................... 14 10 Examples ............................................ 16
8.3 No Session-Expires Header in INVITE ................. 15 10.1 Basic session timer ................................. 16
8.4 Session timer without Calling UA Support ............ 16 10.2 Basic negotiation of Session Time ................... 17
8.5 Session Timer without Called UA Support ............. 17 10.3 No Session-Expires Header in INVITE ................. 18
8.6 Proxy insists on session timer ...................... 19 10.4 Session timer without Calling UA Support ............ 18
8.7 Neither UA Supports Session Timer ................... 20 10.5 Session Timer without Called UA Support ............. 20
8.8 Both UAs Support, Change in Roles ................... 20 10.6 Proxy insists on session timer ...................... 22
9 Changes since -03 ................................... 22 10.7 Neither UA Supports Session Timer ................... 22
10 Author's Addresses .................................. 22 10.8 Both UAs Support, Change in Roles ................... 23
11 Bibliography ........................................ 23 10.9 Proxy Rejects Timer ................................. 25
11 Acknowledgements .................................... 26
12 Changes since -04 ................................... 26
13 Author's Addresses .................................. 27
14 Bibliography ........................................ 27
 End of changes. 

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