draft-ietf-sip-session-timer-01.txt   draft-ietf-sip-session-timer-02.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-01.txt MCI Worldcom,dynamicsoft draft-ietf-sip-session-timer-02.txt dynamicsoft
March 9, 2000 July 14, 2000
Expires: September, 2000 Expires: January 2001
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 The list of Internet-Draft Shadow Directories can be accessed at
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
call stateful proxies to determine in the SIP session is still call stateful proxies to determine if the SIP session is still
active. The extension defines a new general header, Session-Expires, active. The extension defines a new general header, Session-Expires,
which conveys the lifetime of the session. which conveys the lifetime of the session.
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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 important application of the session timer is in NAT and
firewall control. In order for SIP to flow through a NAT or firewall, firewall control [3]. In order for SIP to flow through a NAT or
holes and/or address bindings must be dynamically created to allow firewall, holes and/or address bindings must be dynamically created
the media for the session to flow. These holes and/or address to allow the media for the session to flow. These holes and/or
bindings represent state which must be eventually removed. Relying on address bindings represent state which must be eventually removed.
a BYE to trigger the removal of state, besides being unreliable, Relying on a BYE to trigger the removal of state, besides being
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. A new general header, the Session- used to keep the session active. The extension is sufficiently
Expires header, is defined. It conveys the expiration time of the backwards compatible with SIP that it works so long as one of the two
session. participants in a call leg understand the extension. A new general
header, the Session-Expires header, is defined. It conveys the
expiration time of the session.
2 Protocol Overview 2 Protocol Overview
UACs which support the session timer extension defined here include a UACs which support the session timer extension defined here include a
Supported header in all requests, excepting ACK, containing the Supported header in all requests, excepting ACK, containing the
option tag "timer" [3]. When a UAC makes a call, it MAY include a option tag "timer" [4]. 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.
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 the Supported header in the
request lists the option tag "timer", a proxy can be certain the UAC request lists the option tag "timer", a proxy can be certain the UAC
understands the session timer. In this case, if no Session-Expires understands the session timer. In this case, if no Session-Expires
was present, the proxy can insert one if it so desires. If one was was present, the proxy can insert one if it so desires. If one was
present, the proxy can lower, but not increase, the expiration time present, the proxy can lower, but not increase, the expiration time
of the session. If, however, the Supported header was absent, or was of the session. The proxy remembers the value of Session-Expires it
present but didn't include the tag "timer", the proxy MAY reject the placed into the request, and also remembers that the UAC supported
request with a 421, and indicate in the Require header that the session timer. The UAC will ultimately be responsible for sending the
feature "timer" is needed. As an alternative, the proxy MAY forward refreshes for this call leg.
the request, but MUST NOT add the Session-Expires header. This will
allow the call to proceed without a timer.
Eventually, the initial INVITE reaches the UAS. Like proxies, the UAS If the Supported header was absent from the request, or was present
MAY add a session timer, reduce the session timer, or reject the but didn't include the tag "timer", the proxy knows the UAC cannot
request if the session timer is needed but not supported. If the UAS generate refreshes, but the called party may be able to. If no
accepts the call, it places the final value of the session timer in Session-Expires was present, the proxy can insert one if it so
the Session-Expires in the 200 OK response, and includes a Require desires. If one was present, the proxy can lower, but not increase,
header in the response indicating that the feature "timer" was the expiration time of the session. The proxy remembers the value of
applied to the response. Session-Expires it placed into the request, and also remembers 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".
As the 200 OK traverses the path back towards the UAC, proxies make Eventually, the initial INVITE reaches the UAS. There are two cases -
note of the expiration time in the Session-Expires header in the the UAS supports session timer, or it does not. If it does, the UAS
response. The proxy is safe in destroying call state if a refresh is MAY add a session timer or reduce the session timer from the request.
not received by this expiration time. The UAC then ACKs the INVITE. If the UAS accepts the call, it places the final value of the session
The Session-Expires need not be included in the ACK. timer in the Session-Expires in the 200 OK response. If the request
also contained the Supported header with the value "timer", the UAS
knows the UAC can do refreshes. To make sure the UAC is aware it must
actually do them, the UAS MUST add a Require to the 200 OK response,
with the tag "timer". The UAS does not perform the refreshes in this
case. If the request did not contain the Supported header with the
value "timer", the UAS knows the UAC cannot perform refreshes. So, it
assumes the responsibility. It MUST add the value of the Session-
Timer 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 UAC wishes to keep the session alive, it MUST send a re-INVITE If the UAS does not support session timer, it behaves as a normal
before the expiration time. This re-INVITE MAY contain a Session- UAS. It will, in this case, neither insert Session-Expires in the
Expires header. The processing of this re-INVITE by proxies and UAS response nor a Require header with value "timer".
is identical to that of the initial INVITE.
If the UAS does not receive a re-INVITE refreshing the session, it This response travels backwards through the proxies. When it reaches
SHOULD send a BYE to terminate the call. If the UAC does not receive a proxy which remembers that it asked for session timer, the proxy
a response to the re-INVITE used to refresh the session, it SHOULD examines the response. If the response did not contain a Session-
send a BYE to terminate the call. Similarly, if a proxy doesn't Expires header, but the proxy remembers that the UAC supported
receive a re-INVITE before expiration of the session, it MAY remove session timer, the proxy knows that the UAC supports session timer,
associated call state, and MAY free any resources associated with the but the UAS did not. So, it inserts the Session-Expires header into
call. Unlike the UA, it MUST NOT send a BYE. the response and also adds a Require header with a value of "timer".
If the response the proxy received did have a Session-Expires header,
but no Require header with value "timer", the proxy knows that the
UAS understands session timer, but not the UAC. It simply forwards
this request upstream. If the proxy gets a response without Session-
Expires, and the proxy remembers that the UAC did not support session
timer, the proxy knows that session timer cannot be used, since
neither UAS nor UAC support it. Finally, if the response contains the
Session-Expires and Require header with the value "timer", the proxy
knows that both UAC and UAC support session timer, and that the UAC
will be performing refreshes.
The response then arrives at the UAC. If it contains a Require header
with the value "timer", the UAC knows it is responsible for
refreshes. The response will also contain a Session-Expires header,
and the value of that header is used as the interval for refreshes.
The UAC then ACKs the INVITE. The Session-Expires MUST NOT be
included in the ACK.
If the calling 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.
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.
If the calling UA or the called UA is not performing refreshes, and
does not receive a re-INVITE refreshing the session before the
session expires, they SHOULD send a BYE to terminate the call. If a
refreshing UA does not receive a response to the re-INVITE used to
refresh the session, it SHOULD send a BYE to terminate the call.
Similarly, if a proxy doesn't receive a re-INVITE before expiration
of the session, it MAY remove associated call state, and MAY free any
resources associated with the call. Unlike the UA, it MUST NOT send a
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. It is placed in only in INVITE requests, and is allowed in a session. It is placed in only in INVITE requests, and is allowed in
200 OK response to an INVITE. Like the SIP Expires header, it can any response to an INVITE. Like the SIP Expires header, it can
contain either an absolute time or a delta-time. If it contains an contain either an absolute time or a delta-time. If it contains an
absolute time, this time indicates the time at which a proxy or UA absolute time, this time indicates the time at which a proxy or UA
may safely destroy any state associated with the call. If it contains may safely destroy any state associated with the call. If it contains
a delta time, the expiration time of the session is defined as that a delta time, the expiration time of the session is defined as that
delta plus the time at which the header is observed in a response. delta plus the time at which the header is observed in a response.
For example, if a UAS generates a 200 OK response to a re-INVITE that 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 contained a Session-Expires header with a value of 3600, the UAS
computes the expiration time of the session as one hour after the computes the expiration time of the session as one hour after the
time when the 200 OK was sent. For each proxy, the expiration time is time when the 200 OK was sent. For each proxy, the expiration time is
one hour after the time when the 200 OK was received or sent one hour after the time when the 200 OK was received or sent
(assuming these two are sufficiently close together). For the UAC, (assuming these two are sufficiently close together). For the UAC,
the expiration time is one hour after the receipt of the 200 OK. the expiration time is one hour after the receipt of the 200 OK.
The syntax of the Session-Expires header is: The syntax of the Session-Expires header is:
skipping to change at page 4, line 26 skipping to change at page 5, line 32
delta-seconds ) delta-seconds )
Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC
2543 [1]. 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 200 n h - - - o - - Session-Expires r n h - - - o - -
4 UAC Behavior 4 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" [3]. It MUST do so even if the UAC is not the option tag "timer" [4]. 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 a Require in the request with the value "timer"
to indicate that the UAS must support the session timer to
participate in the session. In addition, the UAC MAY include a
Proxy-Require header in the request with the value "timer" to
indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the
extension.
When the response to the initial INVITE request arrives, it may or When the response to the initial INVITE request arrives, it may or
may not contain a Session-Expires header. UACs MUST be prepared to may not contain a Session-Expires header, and may or may not contain
receive a Session-Expires header in a 200 OK response even if none a Require header with the value "timer". UACs MUST be prepared to
were present in the request. The presence of this header in response receive a Session-Expires header in a response even if none were
to an initial INVITE is only relevant in a 200 OK response. Assuming present in the request.
this is the case, the UAC computes the expiration time of the
session. If the Session-Expires contains an absolute time, that is
the time of expiration. If it contains a delta-time, the expiration
time is the time of reception of the 200 OK plus that delta time. Let
the difference in time between the reception of the 200 OK and the
session expiration time be called the refresh interval. Note that
this expiration applies to the call leg created as a result of that
200 OK. It is explicitly allowed for there to be differing session
timers (or none at all) on differing call legs.
If the 200 OK response to the initial INVITE contained a Session- Table 4 describes the behavior of the UAC after receiving a 200 OK
Expires, and the UAC wishes to continue with the session beyond the response to an initial INVITE, or any final response to a re-INVITE.
expiration, it MUST generate a refresh before the expiration time. It
is RECOMMENDED that this be refresh be sent once half the refresh
interval has elapsed. This refresh is accomplished by sending a re-
INVITE request on the given call leg. The UAC MAY include a Session-
Expires in this re-INVITE, indicating the new desired expiration time
of the session. If the UAC does not place a Session-Expires header in
the request, this means the UAC wishes for the session to have no
expiration time going forward. The 200 OK response to the re-INVITE
contains the actual expiration time. If the 200 OK response to the
re-INVITE does not contain a Session-Expires header, the session no
longer has an expiration. If the response to the re-INVITE was not a
200 OK, the call is still active (as per RFC 2543), but the
expiration time remains unchanged. As with the original INVITE, the
UAC MUST be prepared to receive a Session-Expires header in a 200 OK
response even if it did not place one in the request.
It is important to note that the processing rules for re-INVITEs Require Session-Timer Behavior
parallels that of the initial INVITE. This helps maintain the N N Do nothing.
idempotency of INVITE. N Y Do nothing.
Y N Should never happen. Do nothing.
Y Y UAC SHOULD perform refreshes.
A UAC MAY use the refreshing re-INVITE as a normal SIP re-INVITE; If the UAC must refresh, it follows the following procedure. The UAC
that is, this re-INVITE MAY contain an updated session description. computes the expiration time of the session. If the Session-Expires
In the case where the re-INVITE contains an updated session contains an absolute time, that is the time of expiration. If it
description, the session description MUST somehow indicate that it is contains a delta-time, the expiration time is the time of reception
unchanged. In the case of SDP [4], this is accomplished by using the of the response plus that delta time. Let the difference in time
same value for the origin field. 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 response. It is explicitly
allowed for there to be differing session timers (or none at all) on
differing call legs.
If no 200 OK response to a refreshing re-INVITE is received before If UA wishes to continue with the session beyond the expiration, it
the expiration of the session, the UAC SHOULD send a BYE request to MUST generate a refresh before the expiration time. It is RECOMMENDED
that this refresh be sent once half the refresh interval has elapsed.
This refresh is accomplished by sending a re-INVITE request on the
given call leg. Sending of the refresh (in terms of this extension),
and processing the response are exactly identical to the rules above.
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 still
contains SDP. However, this is exactly the same SDP as sent
previously by the UA.
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 terminate the call. It SHOULD send this BYE slightly before
expiration of the session. Ten seconds is RECOMMENDED. expiration of the session. Ten seconds is RECOMMENDED.
Firewalls and NATs may be very unforgiving about allowing Firewalls and NATs may be very unforgiving about allowing
SIP traffic to pass after the expiration time of the SIP traffic to pass after the expiration time of the
session. It is for this reason that the BYE should be sent session. It is for this reason that the BYE should be sent
before the expiration. 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 refreshses. 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 many times during
a call.
Also note that a non-200 response to an initial INVITE MAY indicate a
session expiration. This happens when a UA crashes and reboots
between refreshes. When the refresh arrives at the rebooted UA, it
decides to reject the call. In order to alert the UAC that it
believes the call is down (the UAC believes this request to be a re-
INVITE, and so a non-200 OK final response will not cause it to
destroy the call), it MAY 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 5 Proxy Behavior
Session expirations are mostly of interest to call stateful proxy Session expirations are mostly of interest to call stateful proxy
servers. However, any proxy server may follow the rules described servers. However, a stateful proxy server may also follow the rules
here. described here. Stateless proxies MUST NOT attempt to request session
timers.
The proxy processing rules require the proxy to remember
information between the request and response, ruling out
stateless proxies.
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 (1) Session-Expires header in the request before forwarding it, if none
none was present in the request, and (2) if the request contained a was present in the request. This Session-Expires header may contain
Supported header with the option tag "timer". This Session-Expires any desired expiration time the proxy would like. If the request
header may contain any desired expiration time the proxy would like. already had a Session-Expires header, the proxy MAY reduce the value
in the Session-Expires header before forwarding the request, but MUST
NOT increase it.
If the initial INVITE had both a Session-Expires header and a Assuming the proxy wishes to use session timer (and thus has possibly
Supported header containing the option tag "timer", the proxy MAY inserted the Session-Expires header or reduced it), the proxy MUST
reduce the value in the Session-Expires header before forwarding the remember that it is using session timer, and also remember the value
request, but MUST NOT increase it. in the request it forwarded, until the final response to the request
arrives, or the transaction times out. If the request also contained
the Supported header with the value "timer", the proxy MUST remember
this as well.
If the initial INVITE did not contain a Supported header with the If the request did not contain a Supported header with the value
option tag "timer", the proxy MUST NOT insert the Session-Expires "timer", the proxy MAY insert a Require header into the request, with
header into the forwarded request. It MAY, however, follow the the value "timer". This allows the proxy to insist on session timer
procedures defined in [3] and reject the request with a 421. for the session. This header is not 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 session.
When a 200 OK response arrives for the call, the actual expiration When the final response to the request arrives, it is examined by the
time for the call leg is contained in the Session-Expires header. The proxy. If it does not contain a Session-Expires header, and the proxy
proxy MUST NOT modify the value of the Session-Expires header when remembers that the UAC supports session timer, the proxy MUST insert
forwarding the response upstream. The expiration of the call will a Session-Timer header into the response with the value it remembered
occur at the time indicated in the Session-Expires header. If the placing into the forwarded request. The proxy MUST also insert the
Session-Expires header contains a delta-time, the expiration time is Require header into the response, with the value "timer", before
the time of receipt of the 200 OK response, plus that delta time. forwarding it upstream. The value of the Session-Timer in the
forwarded response represents the expiration time of the session.
Re-INVITE requests may arrive from the UAC, refreshing the session If the final response to the request arrives without a Session-
Expires header, and the proxy remembers that the proxy did not
support session timer, then session timer is not available for this
session.
If the final response does contain a Session-Expires header, its
value represents the expiration time of the session.
In all cases, the proxy MUST NOT modify the value of the Session-
Expires header received in the response before forwarding it
upstream.
The expiration of the call will occur at the time indicated in the
Session-Expires header. If the Session-Expires header contains a
delta-time, the expiration time is the time of receipt of the final
response, plus that delta time.
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. INVITE.
If the session expires without having seen a 200 OK response to a If the session expires without having seen a response to a re-INVITE,
re-INVITE, the proxy MAY consider the call leg terminated. This means the proxy MAY consider the call leg terminated. This means it MAY
it MAY flush any state associated with that call leg. flush any state associated with that call leg.
6 UAS Behavior 6 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 OK 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 it MUST NOT increase it. If the inital
INVITE did not contain a Session-Expires header, but it did contain a INVITE did not contain a Session-Expires header, but it did contain a
Supported header containing the option tag "timer", the UAS MAY Supported header containing the option tag "timer", the UAS MAY
insert a Session-Expires header into the response. This header MAY insert a Session-Expires header into the response. This header MAY
have any desired expiration time. have any desired expiration time.
If the initial INVITE did not contain a Supported header with the If the UAS places a Session-Expires header into the response, and the
option tag "timer", the UAS MUST NOT insert the Session-Expires request contained a Supported header with the value "timer", the UAS
header into the 200 OK response. It MAY, however, follow the MUST place a Require header into the response with the value "timer".
procedures defined in [3] and reject the request with a 421. In this case, the UAC will generate the refreshes.
If the UAS sends a 200 OK to the initial INVITE, and that 200 OK had
a Sesion-Expires header, the UAS computes the expiration time of the
session. If the Session-Expires contains an absolute time, that is
the time of expiration. If it contains a delta-time, the expiration
time is the time of transmission of the 200 OK plus that delta time.
As described in Section 4, the UAC will send periodic re-INVITEs to If the UAS places a Session-Expires header into the response, and the
refresh the session. The UAS MUST be prepared to receive and process request did not contain a Supported header with the value "timer",
these re-INVITEs. Processing of the re-INVITE, as far as the session the UAS MUST NOT place a Require header into the response with the
timer is concerned, is identical to the rules for the initial INVITE, value "timer". In this case, the UAS will generate the refreshes.
described above. Note that if the 200 OK to the re-INVITE has no
Session-Expires, no expiration time exists for the session.
Since the re-INVITE is a standard re-INVITE, it is possible, for If the UAS is generating refreshes, it computes the expiration time
whatever reason, that the UAS might reject the request. The of the session based on the value of the Session-Expires header in
processing rules for session timer only apply to INVITEs with a 200 the response it sent. The processing from this point is as described
OK response. in section 4 once the UAC determined it was performing refreshses.
If no re-INVITE is received before expiration of the timer, the UAS As described in Section 4, the refreshing UA will send periodic re-
SHOULD send a BYE for the call leg. INVITEs to refresh the session. A UAS MUST be prepared to receive and
process these re-INVITEs. Processing of the re-INVITE, as far as the
session timer is concerned, is identical to the rules for the initial
INVITE, described above. Note that if the 200 OK to the re-INVITE has
no Session-Expires, no expiration time exists for the session.
7 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 introducing denial-of-service attacks. Use of short refresh
intervals allows the proxies to create network load. The session intervals allows the proxies to create network load. The session
timer mechanism allows the proxy to be able to terminate established timer mechanism allows the proxy to be able to terminate established
skipping to change at page 8, line 27 skipping to change at page 10, line 42
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 Called UA starts session timer on send
Calling UA starts session timer on receipt Calling UA starts session timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
60 seconds later: n60 seconds later:
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 Called UA starts session timer on send
Calling UA starts session timer on receipt Calling UA starts session timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
120 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 8.2 Basic negotiation of Session Time
skipping to change at page 10, line 5 skipping to change at page 12, line 22
SPS -> Called UA SPS -> Called UA
BYE BYE
SPS <- Called UA SPS <- Called UA
200 OK 200 OK
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
8.3 No Session-Expires Header Rejection by SPS 8.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 without a Supported header containing the option tag header and with a Supported header containing the option tag "timer".
"timer". Since the proxy requires session timer for the call, it Since the proxy requires session timer for the call, it adds the
rejects the INVITE. Session-Expires header.
Calling UA -> SPS Calling UA -> SPS
INVITE No Session-Expires or Supported header INVITE No Session-Expires
Supported: timer
SPS -> Called UA
INVITE
Supported: timer
Session-Expires: 120
SPS <- Called UA
200 OK
Session-Expires: 120
Require: timer
Calling UA <- SPS Calling UA <- SPS
421 Extension Required 200 OK
Session-Expires: 120
Require: timer Require: timer
Calling UA -> SPS
ACK
SPS -> Called UA
ACK
8.4 Session timer without Calling UA Support
In this scenario, the calling UA sends and INVITE without a Session-
Expires header and without a Supported header containing the option
tag "timer". Since the proxy requires session timer for the call it
adds Session-Expires header before proxying the INVITE to the called
UA.
Calling UA -> SPS
INVITE
SPS -> Called UA
INVITE SPS adds session expires
Session-Expires: 180
SPS <- Called UA
200 OK Called UA wants a shorter timer
Session-Expires: 120 Called UA starts timer
Calling UA <- SPS
200 OK
Session-Expires: 120 Proxy starts timer on send
Calling UA -> SPS Calling UA -> SPS
ACK ACK
8.4 Addition of Session-Expires by UAS SPS -> Called UA
ACK
Sixty seconds later:
SPS <- Called UA
INVITE
Supported: timer
Session-Expires: 120
Calling UA <- SPS
INVITE
Supported: timer
Session-Expires:120
Calling UA -> SPS
200 OK
SPS -> Called UA
200 OK
SPS <- Called UA
ACK
Calling UA <- SPS
ACK
The Calling UA terminates the session for non timer
related reasons:
Calling UA -> SPS
BYE
SPS -> Called UA
BYE
SPS <- Called UA
200 OK
Calling UA <- SPS
200 OK
8.5 Addition of Session-Expires by UAS
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 into the INVITE. session timer, but does not add the Session-Expires into the INVITE.
The UAS, however, adds the header. The UAS, however, adds the header.
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120 Called UA starts timer on send Session-Expires: 120 Called UA starts timer on send
Calling UA starts timer on receipt Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
8.5 Addition of Session-Expires by Proxy 8.6 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 result is that the call is set up without a session timer. 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 -> SPS Calling UA -> SPS
INVITE INVITE
k: timer k: timer
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS adds S-E header
k: timer k: timer
Session-Expires: 180 Session-Expires: 180
SPS <- 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 <- SPS
200 OK 200 OK
Session-Expires: 180 SPS adds Session-Expires and Require
Require: timer
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
9 Changes since -00 8.7 Proxy insists on session timer
Calling UA -> SPS
INVITE
o Changed to make use of the Supported header. SPS -> Called UA
INVITE SPS adds session expires
Require: timer SPS adds Require
Session-Expires: 180
o Conveyance of Session Expires in ACK is no longer needed SPS <- Called UA
(because of usage of the Supported header), and has been 420 Bad Extension
removed. Unsupported: timer
o Session Expires only allowed in INVITE, not in BYE as Calling UA <- SPS
previously specified. Usage in BYE doesn't accomplish 420 Bad Extension
anything, as the call is terminated. Unsupported: timer
o Specified that only UAC sends re-INVITEs for keepalives. Calling UA -> SPS
ACK
o Session Expires only present in 200 OK responses. Doesn't SPS -> Called UA
appear to be needed in any other. ACK
o Session-Expires no longer mandatory in re-INVITEs. This is 8.8 Neither UA Supports Session Timer
done to unify the processing of INVITE and re-INVITE for
session timer. Also means that a previously timed session can
become untimed.
o Changed semantics of delta-time to be relative to the time of In this case, the proxy does not insist on session timer, so the call
message arrival, rather than the time of previous expiration. is set up without it.
This is in line with normal Expires processing.
o The original mechanism allowed a proxy to reject the request Calling UA -> SPS
if the timer was too long, or to reduce the timer. There seems INVITE
to be no clear reason to have both. Rejecting will just cause
the client to resubmit with the shorter expiration, resulting
in the same net effect with additional complexity. Thus, the
notion of rejecting session timers is removed, and with it,
the 488 response code, which is then uneccesary. This seems to
simplify the protocol.
o A mechanism had existed to reject a session timer with a SPS -> Called UA
Session-Expires of 0, meaning the expiration remains INVITE SPS adds S-E header
unchanged. With the new definition of the relative offset for Session-Expires: 180
Expires, this no longer requires special treatment. A proxy or
UAS can set the session timer with an absolute time equal to
the current expiration.
10 Open Issues SPS <- Called UA
200 OK Called UA doesn't understand session timer
o Should we allow Session-Expires in non-INVITE requests, Calling UA <- SPS SPS doesn't add S-E since it knows Calling UA
perhaps INFO (I think no) 200 OK doesn't support it
o Should we allow the UAC to insert a Require header in the Calling UA -> SPS
request, indicating that the UAS must support the session ACK
timer? (I think no) SPS -> Called UA
ACK
o With this draft (and the previous versions), there was no way 9 Changes since -01
for the proxy to reject the call if the calling UA supported
the session timer, but the called UA didn't. Is this a
problem? If so, what can be done about it? (I think there is
nothing we can do, and we should not worry about it)
11 Author's Addresses o Added wording indicating that the UAC can add the Require and
Proxy-Require headers with the "timer" header.
o Added the ability for proxy to include Session-Timer header
when the UAC did not include the Supported with the "timer"
tag.
o Added the ability for a proxy to insert the Session-Timer
header into a response, in the case where the called UA didn't
support session timer, but the calling UA did.
o Added the ability for the called UA to refresh the session
timer. This is only in the case that the calling UA does not
support the "timer" feature.
o Session-Expires can be present in non-200 OK responses to
reINVITEs
o Added wording about getting Session-Expires of zero in non-200
OK response to initial INVITE, handling crash and reboot
cycles.
o Discuss re-INVITEs changing the role of who is doing
refreshes.
10 Author's Addresses
Steven R. Donovan Steven R. Donovan
MCI Worldcom dynamicsoft
1493/678 72 Eagle Rock Avenue
901 International Parkway First Floor
Richardson, Texas 75081 East Hanover, NJ 07936
email: steven.r.donovan@wcom.com email: sdonovan@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
200 Executive Drive 72 Eagle Rock Avenue
Suite 120 First Floor
West Orange, NJ 07052 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
12 Bibliography 11 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 (Proposed session initiation protocol," Request for Comments 2543, Internet
Standard) 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
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 1889, Internet Engineering Task Force, Jan. 1996.
[3] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support
by servers," Internet Draft, Internet Engineering Task Force, Jan.
2000. Work in progress.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, Apr. 1998.
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to [3] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
others, and derivative works that comment on or otherwise explain it firewalls and NATs," Internet Draft, Internet Engineering Task Force,
or assist in its implementation may be prepared, copied, published Feb. 2000. Work in progress.
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 [4] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
revoked by the Internet Society or its successors or assigns. Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in
progress.
This document and the information contained herein is provided on an [5] M. Handley and V. Jacobson, "SDP: session description protocol,"
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Request for Comments 2327, Internet Engineering Task Force, Apr.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1998.
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 ........................................ 1
2 Protocol Overview ................................... 2 2 Protocol Overview ................................... 2
3 Session-Expires Header Field Definition ............. 3 3 Session-Expires Header Field Definition ............. 4
4 UAC Behavior ........................................ 4 4 UAC Behavior ........................................ 5
5 Proxy Behavior ...................................... 6 5 Proxy Behavior ...................................... 7
6 UAS Behavior ........................................ 6 6 UAS Behavior ........................................ 9
7 Security Considerations ............................. 7 7 Security Considerations ............................. 10
8 Examples ............................................ 8 8 Examples ............................................ 10
8.1 Basic session-timer setup with UAS detected 8.1 Basic session-timer setup with UAS detected
timeout ........................................................ 8 timeout ........................................................ 10
8.2 Basic negotiation of Session Time ................... 9 8.2 Basic negotiation of Session Time ................... 11
8.3 No Session-Expires Header Rejection by SPS .......... 10 8.3 No Session-Expires Header in INVITE ................. 12
8.4 Addition of Session-Expires by UAS .................. 10 8.4 Session timer without Calling UA Support ............ 13
8.5 Addition of Session-Expires by Proxy ................ 10 8.5 Addition of Session-Expires by UAS .................. 14
9 Changes since -00 ................................... 11 8.6 Session Timer without Called UA Support ............. 15
10 Open Issues ......................................... 12 8.7 Proxy insists on session timer ...................... 15
11 Author's Addresses .................................. 12 8.8 Neither UA Supports Session Timer ................... 16
12 Bibliography ........................................ 13 9 Changes since -01 ................................... 17
10 Author's Addresses .................................. 17
11 Bibliography ........................................ 18
 End of changes. 

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