Internet Engineering Task Force                                   SIP WG
Internet Draft                                     S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-05.txt
draft-ietf-sip-session-timer-06.txt                          dynamicsoft
July 20,
August 24, 2001
Expires: February 2002

                         The SIP Session Timer

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   This document proposes an extension to the Session Initiation
   Protocol (SIP). This extension allows for a periodic refresh of SIP
   sessions through a re-INVITE. The refresh allows both user agents and
   proxies to determine if the SIP session is still active. The
   extension defines two new general headers, Session-Expires, which
   conveys the lifetime of the session, and Min-SE, which conveys the
   minimum allowed value for the session timer.

1 Introduction

   The Session Initiation Protocol (SIP) [1], does not currently define 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. For instance, when a user agent fails to send a BYE message at
   the end of a session, or the BYE message gets lost due to network
   problems, a call stateful proxy will not know when the session has
   ended. In this situation, the call stateful proxy will retain state
   for the call and has no deterministic method of determining when the
   call state information no longer applies.

   To resolve this problem, this extension defines a keepalive mechanism
   for SIP sessions. UAs send periodic re-INVITEs to keep the session
   alive. The interval for the re-INVITEs is determined through a
   negotiation mechanism defined here. If a re-INVITE is not received
   before the interval passes, the session is considered terminated.
   Both UAs are supposed to send a BYE, and call stateful proxies can
   remove any state for the call.

        INVITE is used as a refresh, as opposed to another method,
        to allow sessions to be recovered after a crash and restart
        of one of the UAs. It makes SIP sessions soft state.

   This refresh mechanism has additional applications. For the same
   reasons a call stateful proxy server would like to determine whether
   the session is still active, a user agent would like to make this
   determination. This determination can be made at a user agent without
   the use of SIP level mechanisms; for audio sessions, periodic RTCP
   packets serve as an indication of liveness [2]. However, it is
   desirable to separate SIP call liveness from the details of the
   particular session.

   Another application of the session timer is in the construction of a
   SIP NAT ALG. The ALG embedded in a NAT will need to maintain state
   for the duration of a call. This state must eventually be removed.
   Relying on a BYE to trigger the removal of state, besides being
   unreliable, introduces a potential denial of service attack.

   This document proposes an extension to SIP that defines a session
   expiration mechanism. Periodic refreshes, through re-INVITEs, are
   used to keep the session active. The extension is sufficiently
   backwards compatible with SIP that it works so long as either one of
   the two participants in a call leg understand the extension. Two new
   general headers, Session-Expires and Min-SE, and a new response code,
   422, are defined. Session-
   Expires Session-Expires conveys the duration of the
   session, and Min-SE conveys the minimum allowed value for the session
   expiration.

2 Protocol Overview

   UACs which support The 422 response code indicates that the session timer extension defined here MUST
   include a Supported header
   duration was too small.

2 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in all requests, excepting ACK, containing RFC 2119 [3] and
   indicate requirement levels for compliant SIP implementations.

   Additionally, we define the option tag "timer" [3]. When a UAC makes following terms:

        Session Interval: The largest amount of time that can occur
             between INVITE requests in a call, call before it MAY include a
   Session-Expires header will be
             considered timed out. The session interval is conveyed in
             the INVITE request. Session-Expires header defined here. The presence of UAS obtains
             this value from the Session-Expires header indicates of a 2xx INVITE
             response that the UAC wishes to use the
   session timer for it sends. Proxies and UACs determine this call. Its
             value indicates the desired
   expiration time of the session. The UAC MAY include the "refresher"
   parameter in from the Session-Expires header with the value "uac". This
   indicates that the caller will perform refreshes for the session.

   Proxies on in a 2xx INVITE
             response they receive.

        Minimum Timer: Because of the signaling path may processing load of INVITE
             requests, all elements (proxy, UAC, UAS) can have their own requirements a
             configured minimum value for the
   refresh session interval of that they
             are willing to accept. This value is called the session. If no Session-Expires was present, minimum
             timer.

        Session Expiration: The time at which an element will consider
             the proxy MAY insert one call timed out, if it so desires. no successful INVITE transaction
             occurs beforehand.

        Refresh: An INVITE request sent during an active call leg. If one was present,
             the
   proxy can lower its value, but not to request generates a value lower than 2xx response, the value in session
             expiration is increased to the Min-SE header in current time plus the request, if present. The proxy MUST NOT
   increase
             session interval from the value response.

3 Protocol Overview

   This section provides a brief overview of operation of the Session-Expires header. protocol.
   It is tutorial in nature and should not be considered as normative.

   Session refreshes are accomplished using SIP INVITEs. The proxy remembers initial
   INVITE establishes the value duration of Session-Expires that was finally used the session, which is carried in
   the request.
   The proxy also notes whether Session-Expires header in the UAC supports session timer, based on
   whether 2xx response to the Supported INVITE. The
   Session-Expires header was present with in the tag "timer". In all
   cases, 2xx response also indicates which side
   will be responsible for generating these refreshes - the proxy MUST NOT insert uac or modify the value of the
   "refresher" parameter in uas.
   The responsible side then generates a refresh (using a re-INVITE)
   before the Session-Expires header. session expires. If the proxy wishes refreshes never gets a response to insist
   that the call is only established if
   the UAS supports session timer, re-INVITE, it MAY insert sends a Require header into
   the request, with the value "timer", although this is NOT
   RECOMMENDED, since it eliminates BYE to terminate the possibility of call
   establishment call. Similarly, if
   the UAS does not support session timers.

   Eventually, the initial INVITE reaches other side never gets the UAS. There are two cases - re-INVITE before the UAS supports session timer, or it does not. If expires,
   it does, and sends a BYE. The refreshes themselves are processed identically to
   a regular INVITE, so that the response is otherwise acceptable to a re-INVITE carries the UAS, the UAS MUST copy new
   time at which the
   Session-Expires into session will expire.

   It is an explicit goal of the 200 class response, or MAY add protocol to operate so long as one into of
   the
   response if none was present two UAs in a call leg support the request. They UAS MAY reduce the
   session timer in the 200 class response, but not lower than the value
   in the Min-SE header, if present. The UAS also sets the value extension. That side, of
   course, ends up performing the
   refresher parameter, based on rules in Section 7, which determines
   who refreshes. The other side will be generating merely
   see them as repetitive re-INVITEs. This facilitates interoperability.

   The details of the re-INVITEs protocol relate to negotiation of a reasonable
   value for the refreshing. If session interval, and negotiation of which side of the UAC
   call leg is doing refreshes, the UAS additionally inserts a Require header
   into the 200 class response, with the tag "timer". This informs performing the
   UAC that special processing is needed for this response.

   If refreshes. Negotiation of the UAS does not support session timer, it behaves as
   interval is critical. The value must be small enough to provide a normal
   UAS. Because of this, any 200 class response it generates will
   useful expiration, but not
   contain so small to overload the Session-Expires or Require header proxies with the tag "timer". re-
   INVITEs. The 200 class response travels backwards through goal of the proxies. When it
   reaches protocol is to choose a proxy which remembers that it asked for session timer, interval
   that is the
   proxy examines smallest of all the response. If values requested by all elements, but
   only if that value is larger than the response did not contain a
   Session-Expires header (meaning largest minimum timer requested
   by all elements. Negotiation of the UAS does not support session
   timer), additional proxy processing refresher role is needed. simpler. If
   only one side supports the proxy remembers extension, that side acts as refresher.
   Otherwise, one side chooses who will refresh. This negotiation takes
   place as part of INVITE processing, and due to the UAC supported session timer, the proxy must return the value idempotency of
   INVITE requests, is effectively redone each time the session timer to the UAC. So, it inserts the Session-Expires
   header into the response (using is
   refreshed with another re-INVITE.

   To negotiate the value it remembered inserting),
   sets of the "refresher" parameter to "uac", refresh interval, the Min-SE and adds a Require header
   with
   Session-Expires headers are used. The UAC generates an INVITE, and
   includes a Session-Expires if it wishes to use the session timer. As
   the INVITE traverses proxies, the proxies (and the UAS) can reduce
   the value of "timer". If the proxy remembers that the UAC did not
   support session timer, but not lower than the proxy knows that session timer cannot be
   used, since neither UAS nor UAC support it.

   If the response received by value of the
   Min-SE header. If a proxy does contain the or UAS receives a request with a Session-
   Expires header, lower than a configured minimum, it can reject the "refresher" parameter will indicate which side is
   performing refreshes.

   The request
   with a 422 response. This response then arrives at the UAC. If it contains a Require Min-SE header with the value "timer", the UAC knows that special processing of the
   response is needed.
   minimum allowed value. The response will also contain client retries the request, inserting a Session-Expires
   header, and
   Min-SE header containing the maximum value of that header is used as the interval Min-SE headers
   returned in previous 422 responses for
   refreshes. The refresher parameter indicates who will be performing the refreshes. If it contains call. In the value "uac", case where
   the UAC knows it is
   performing them. If it contains client isn't aware of the value "uas", it knows session timer extension, a proxy that
   receives a request with a Session-Expires lower than the
   UAS is performing them.

   The UAC then ACKs configured
   minimum places the INVITE. The Session-Expires MUST NOT be
   included Min-SE header in the ACK.

   Whichever side is supposed to perform the refreshes MUST send a re-
   INVITE before proxied request, and
   increases the expiration time. This re-INVITE SHOULD contain Session-Expires header to that minimum. When the
   request eventually reaches the UAS (potentially after a few retries
   from 422), it will do so containing a Session-Expires header. header that
   meets the design criteria described above. The processing of this re-INVITE by proxies
   and UAS returns a 200 OK
   with a Session-Expires header containing the final duration of the
   session. The header also contains a parameter, called refresher, that
   indicates which side is identical performing the refreshes.

   This basic behavior is built upon to that handle the case where only one
   side supports the extension. When only the UAC supports it, one of
   the initial INVITE.

   If proxies "fills the side not performing refreshes does not receive a re-INVITE
   refreshing shoes" of the UAS. Specifically, when the UAS
   does support session before timer, it places the value of the session expires, they SHOULD send a
   BYE to terminate timer
   into the call. If a refreshing UA does not receive a
   response to Session-Expires header in the re-INVITE used to refresh 2xx response. When the session, it SHOULD send
   a BYE to terminate UAS
   doesn't support it, the call. Similarly, if a proxy doesn't receive a
   re-INVITE before expiration of closest to the session, it MAY remove associated
   call state, UAS performs that job,
   and MAY free any resources associated with inserts the call.
   Unlike value of the UA, timer into the 2xx response as it MUST NOT send a BYE.

3 passes
   by.

4 Session-Expires Header Field Definition

   The Session-Expires general header conveys the expiration time session interval for a
   SIP
   session described in the body of the message. call. It is placed only in INVITE requests, and is allowed in any
   200 class response to an INVITE. Like Unlike the SIP Expires header, it
   can only 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 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 delta plus The session expiration is defined as
   that delta plus the time at which the header is observed in a final
   response. For example, if a UAS generates a 200 OK response to a re-INVITE re-
   INVITE that contained a Session-Expires header with a value of 3600,
   the UAS computes the
   expiration time of the session expiration as one hour after the time
   when the 200 OK was sent. For each proxy, the session expiration time is
   one hour after the time when the 2xx was received or sent (assuming
   these two are sufficiently close together). For the UAC, the
   expiration time is one hour after the receipt of the final response.

   Any entity that inserts a Session-Expires header with an absolute
   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. value for the Session-Expires header.
   However, 30
   minutes 1800 seconds (30 minutes) is RECOMMENDED. In other words,
   SIP entites MUST be prepared to handle session refresh intervals Session-Expires values of any
   duration, but entities that insert the Session-Expires header SHOULD
   NOT choose times that
   result in intervals values less than 30 minutes.

   Small session timer values intervals can be destructive to the network. They cause
   excessive messaging traffic that affects both user agents and proxy
   servers. They increase the possibility of 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 not just a phone call. At the time of publication of this
   document, 30 minutes seems appropriate. Advances in technologies may
   result in the number being excessively large five years in the
   future.

   The syntax of the Session-Expires header is:

        Session-Expires  =  ("Session-Expires" | "x") ":" ( SIP-date | 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 2xx response with the
   Session-Expires header MUST contain this parameter, indicating who
   will perform the refreshes. If the UAC wishes to insist on performing
   the refreshes, it MAY insert the parameter with a value of "uac" in
   the 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. It could know this by having received a
   request with a Supported header containing the value "timer" from its
   peer, or because a 2xx response received from the peer had a
   refresher parameter with the value "uas".

   Note that a compact form, the letter 'x', has been reserved for
   Session-Expires. Both SIP-Date and The BNF for delta-seconds are is defined in Section 6.20
   of RFC 2543 [1].

   Table 1 is an extension of tables 4 and 5 in [1] for the Session-
   Expires header:

                           where enc e-e ACK BYE CAN INV OPT REG
           _____________________________________________________
           Session-Expires   R    n   h   -   -   -   o   -   -
           Session-Expires  2xx   n   h   -   -   -   o   -   -

   Table 1: 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.

4

5 Min-SE Header Field Definition

   The Min-SE request general header indicates the minimum value for the
   duration of the session timer. It is
   interval, in units of delta-seconds. An When used in an INVITE for a particular call leg which has generated a 422 response
   MUST contain the Min-SE header, and request,
   it indicates the smallest value MUST of the session interval which can be the largest
   value amongst all Session-Expires values returned in 422 responses on
   that leg. A proxy or UAS MUST NOT reduce
   used for that session. A proxy or UAS MUST NOT reduce the value of
   the session
   timer interval below the value in this header, when present. present in
   an INVITE request.

   When not present, the default value for this header is zero.

   The Min-SE header MUST NOT be used in responses except those with a
   422 response code. It indicates the minimum value of the session
   interval that the server is willing to accept.

   The syntax of the Min-SE header 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 Min-SE
   header:

                      where enc e-e ACK BYE CAN INV OPT REG
               ____________________________________________
               Min-SE   R    n   h   -   -   -   o   -   -
               Min-SE  422   n   h   -   -   -   m   -   -

   Table 2: Summary of header fields. "o": optional "-": optional, "m": mandatory,  "-
   ":  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

6 422 Response Code Definition

   This extension defined here MUST
   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
   requesting keepalives for the call.

   If introduces the UAC wishes to request keepalives 422 response code. The default reason
   phrase for this call, it MUST
   include code is "Session Timer Too Small". It is generated by
   a Session-Expires in the INVITE request used to initiate the
   call. The value of this header indicates the time UAS or proxy when the UAC will
   consider the call expired if no refresh is sent. If the a request is
   being authenticated, the contains a Session-Expires header MUST appear before
   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"
   to indicate duration that is below the UAS must support the session minimum timer to
   participate in the session. In addition, for the UAC MAY include server. The 422
   response MUST contain a
   Proxy-Require Min-SE header in the request with the value "timer" to
   indicate that proxies must support session minimum timer in order for that
   server.

7 UAC Behavior

7.1 Generating an INVITE Request

   The rules for an initial INVITE are identical to
   correctly process the request. However, usage of either Require or
   Proxy-Require by those for a re-
   INVITE. An re-INVITE generated to refresh the UAC session is NOT RECOMMENDED. They are not needed,
   since a normal
   re-INVITE. It SHOULD contain SDP that describes the extension works session, even when only if
   that SDP has not changed. In that case, the UAC supports session description MUST
   somehow indicate that it has not changed. In the
   extension. case of SDP, this is
   accomplished by including the same value for the origin field as
   previous messages to its peer. The Supported header containing "timer" MUST still be
   included even if same is true for the Require or Proxy-Require headers are present
   containing "timer".

   When a 2xx 200 class
   response to the initial INVITE request arrives, it may or
   may not a re-INVITE used solely for refreshing. The response MUST
   contain a Require header session description with the value "timer". If an indication that it does, has not
   changed. This is accomplished in the UAC MUST look same way as for the Session-Expires header request.

   It is possible for a UAS to process believe that an INVITE is an initial
   INVITE, and for the
   response.

   If there was UAC to believe it is a Require header in re-INVITE. This happens
   when a UA crashes and reboots between refreshes. When the response with refresh
   arrives at the value "timer", rebooted UA, it decides to reject the Session-Expires header call (generally,
   it will always be present. UACs 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 be
   prepared to receive insert a Session-Expires header From tag in a response even an
   initial INVITE if
   none were present 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 request. The "refresher" parameter will be
   present, indicating who will 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 performing the refreshes. If the
   parameter contains the value "uac",
        distinguished for a new INVITE in which the UAC will perform them. It inserts a
        From tag. This ambiguity is
   possible that 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.

   A UAC requested which supports the session timer (and thus included extension defined here MUST
   include a
   Session-Expires in the request, but there was no Require or Session-
   Expires Supported header in each request (except ACK), listing the 200 class response. This will happen when only the UAC
   supports session timer. In this case, the UAC needs to perform
   keepalives. To
   option tag "timer" [4]. It MUST do this, so even if the UAC follows the procedures defined in
   this specification as if is not
   requesting keepalives for the call.

   A UAC MAY include a Session-Expires header were in the 200
   class response, and its an initial INVITE request if
   it wishes for a session timer to be applied. The value was of this header
   indicates session interval desired by the same as UAC. In an INVITE that is
   within a call leg with an active session timer, the one in header SHOULD be
   present, and SHOULD contain the request
   (but with a refresher parameter current value of "uac"). the session
   interval.

   If the UAC must refresh, INVITE is a re-INVITE it computes is RECOMMENDED that the expiration time of refresher be
   set to "uac" if the
   session. This element sending the INVITE is based on currently
   performing refreshes, else "uas" if its peer is performing the value of
   refreshes. In an initial INVITE, the Session-Expires in UAC MAY include the
   response. refresher
   parameter with value "uac" if it wishes to perform the refreshes. If
   the Session-Expires contains an absolute time, that is UAC wishes to leave this decision to the time of expiration. If it contains a delta-time, negotiation mechanisms
   described below, the expiration
   time refresher parameter is omitted.

   The UAC MAY include a Require in the time of reception of request with the response plus value "timer"
   to indicate that delta time.
   Let the difference UAS must support the session timer to
   participate in time between the reception of session. This does not mean that the response and UAC is
   requiring the session expiration time be called UAS to perform the refresh interval. Note refreshes, just that
   this expiration applies only it is requiring
   the UAS to support the call leg associated extension. In addition, the UAC MAY include a
   Proxy-Require header in the request with the
   response. It is explicitly allowed for there value "timer" to be differing
   indicate that proxies must support session
   timers (or none at all) on differing call legs, timer in order to
   correctly process the case where
   there request. However, usage of either Require or
   Proxy-Require by the UAC is NOT RECOMMENDED. They are multiple 2xx OK responses to an initial INVITE with
   different tags in not needed,
   since the To field.

   If UA wishes to continue with extension works even when only the session beyond UAC supports the expiration, it
   extension. The Supported header containing "timer" MUST generate a refresh before the expiration time. It is RECOMMENDED
   that this refresh still be sent once half
   included even if the refresh interval has elapsed.
   The procedures for performing this refresh Require or Proxy-Require headers are described in Section
   8.

   If present
   containing "timer".

   The UAC MUST insert the Min-SE header into an re-INVITE request for a
   particular call leg if it has ever received a 422 response to a
   previous INVITE on the initial same leg, or if it has received an INVITE on
   that call leg which contained a Min-SE header. Similarly, if no call
   leg has been established yet, a UAC MUST insert the Min-SE header
   into an INVITE request is for a particular call if it has ever received
   a 422 Session Timer
   Too Small response message then the UAC MAY retry the to a previous INVITE with a
   longer session timer the same Call-ID.

   The value of the Min-SE header present in the Session-Expires header.  The UAC INVITE MUST use a value that is bigger than any be the
   largest value amongst all Min-SE values returned in a
   Session-Expires header in any all 422 response within
   responses, or received in INVITE requests, on the same call leg. This
   requires leg, if a
   call leg has been established. If no leg is established, the UA Min-SE
   header is set to store the largest session timer duration value amongst all Min-SE values returned
   in any all 422 responses for the duration same call. A result of the call leg. This behavior this rule is needed
   to prevent certain denial of service attacks, described in Section 9.

6 Proxy Behavior

   Session expirations are mostly of interest to call stateful proxy
   servers. However, a stateful proxy server MAY also follow the rules
   described here. Stateless proxies MUST NOT attempt to request session
   timers. Proxies which ask for session timers SHOULD record-route,
   since they won't receive refreshes if they don't.

        The proxy processing rules require the proxy to remember
        information between the request and response, ruling out
        stateless proxies.

6.1 Processing of requests

   Due to local policy, a proxy may have guidelines about that
   the desired maximum lifetime for a call initiated through it. When an initial
   INVITE is received to establish a call, a proxy MAY insert a
   Session-Expires header in the request before forwarding it, if none
   was present in the request. This Session-Expires header may contain
   any desired expiration time the proxy would like, but not with a
   duration lower than the value in of the Min-SE header in is effectively "cleared" once the request, if
   present.

   If
   call leg is established, and from that point on, only the request already had a Session-Expires header, values from
   proxies known to be on the proxy MAY
   reduce the value in path are used. If the UAC inserts a
   Session-Expires header, but MUST NOT set into an INVITE, it
   to MUST have a duration lower value greater than or
   equal to the value in placed into the Min-SE header in the
   request, header, if present. The proxy MUST NOT increase

7.1.1 Example

   As an example, a UAC sends an INVITE with Call-ID 1, and receives a
   422 with a Min-SE header of 100. There is a tag in the To field, with
   a value of the
   duration. 8. The proxy MAY reject the INVITE request if UAC retries the requested session
   timer value in request. It contains a Min-SE
   header. Since no call leg has been established, the Session-Expires Min-SE header is smaller than
   contains the minimum largest value defined amongst all Min-SE values returned in the proxies local policy. The proxy does so by
   sending a 422 Session Timer Too Small response message. When sending
   responses to INVITEs with the 422 response message, same Call-ID, in this case, with the proxy MUST include
   Call-ID of 1. There has only been one such 422, and it had a Session-Expires Min-SE
   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
   inserted 100. So, the Session-Expires retried INVITE contains a Min-SE
   header or reduced it), with value 100, and no tag in the proxy MUST
   remember that it To field, as there is using session timer, no
   call leg established yet.

   This INVITE generates another 422, this time with a Min-SE header
   with a value of 200 and also remember a tag in the To field with value
   of 9. Once
   again, the Session-Expires header it placed in UAC retries the proxied request. This
   MUST be remembered for the duration of time, the transaction. INVITE has a Min-
   SE with value 200. The proxy
   MUST remember, for call is accepted by the duration UAS, resulting in a
   200 OK with a tag in the To field of 10. Later, the transaction, UAC sends a re-
   INVITE to refresh. Since a call leg is established, it looks to see
   whether there had been any Min-SE headers returned in any 422
   responses on the
   request contained same leg (that is, with a tag of 10). Since there
   were none, that refresh doesn't contain a Min-SE header.

   Later on, the Supported UA receives a re-INVITE from its peer, containing a
   Min-SE header with the value "timer".

   If of 100. This sets the maximum Min-SE
   value on this leg to 100. When the UA refreshes, it includes a Min-SE
   header with a value of 100.

7.2 Processing a 2xx Response

   When a 2xx response to the INVITE request did arrives, it may or may not
   contain a Supported Require header with the value
   "timer", "timer". If it does, the proxy MAY insert UAC
   MUST look for the Session-Expires header to process the response.

   If there was a Require header into in the request, response with the value "timer". However, this is NOT RECOMMENDED. This allows the
   proxy to insist on session timer for "timer",
   the session. This Session-Expires header is not
   needed if will always be present. UACs MUST be
   prepared to receive a Supported Session-Expires header was in the request; a response even if
   none were present in this case, the
   proxy can already request. The "refresher" parameter will be sure
   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 can be used for (and thus included a
   Session-Expires in the
   session.

6.2 Processing of Responses

   When request), but there was no Require or
   Session-Expires in the final response to 200 class response. This will happen when the request arrives, it is examined by
   UAS doesn't support session timer, and only the
   proxy. There are four cases.

        CASE I: UAC supports, UAS doesn't. has asked for
   session timer (no proxies have requested it). In this case, if the request
             forwarded by
   UAC still wishes to use keepalives (they are purely for its benefit
   alone), it has to perform them. To do this, the UAC follows the
   procedures defined in this specification as if the proxy contained a Session-Expires
   header
             (possibly inserted by the proxy). Recall that all proxies
             interested were in session timer MUST remember the 200 class response, and its value of was the
             timer in same as
   the forwarded request, one in addition to whether the
             UAC supports it. Handling request (but with a refresher parameter of "uac").

   If the 2xx response for this scenario
             depends on whether the session timer aware proxy is the one
             closest to the UAS, amongst all proxies which requested
             session timer.

             When the UAS sends the response, it will did not contain a Session-Expires or Require header. This response is
             forwarded upstream, and it will eventually arrive at a
             proxy which was interested in session timers. Because header, there
   is no Session-Expires or Require in the response, the proxy
             knows it is the first session-timer-aware proxy session expiration. In this case, no refreshes need to receive
             the response. This proxy MUST insert be sent.
   A 2xx without a Session-Expires
             header into the response with the value it remembered from can come for both initial and mid-
   call INVITE requests.

   The UAC remembers the forwarded request. It MUST set session interval for a call leg as the value of
   the
             "refresher" parameter to "uac". The proxy MUST also insert delta-time from the Require Session-Expires header into in the response, most recent 2xx
   response to INVITE on that call leg. It is explicitly allowed for
   there to be differing session intervals (or none at all) on differing
   call legs. This happens in the case where there are multiple 2xx OK
   responses to an initial INVITE with different tags in the value
             "timer", before forwarding it upstream. The value of To field.
   It also remembers whether it, or its peer, is the
             Session-Expires in refresher on the forwarded response represents
   leg.

   If the UAC must refresh a leg, it computes the session expiration for
   that leg. The session expiration is the time of reception of the session. For other proxies, the last
   2xx INVITE response will already contain on that leg plus the Session-Expires and
             Require header, so session interval for that this case
   leg. If UA wishes to continue with the session beyond the session
   expiration, it MUST generate a refresh before the session expiration.
   It is indistinguishable from
             CASE IV.

        CASE II: UAC doesn't support, UAS doesn't support. In RECOMMENDED that this case, refresh be sent once half the final response session
   interval has no Session-Expires header, and elapsed. Additional procedures for this refresh are
   described in Section 10.

7.3 Processing a 422 Response

   If the
             proxy remembers that response to an INVITE request is a 422 Session Timer Too Small
   response message, then the UAC did not support MAY retry the INVITE. The procedures
   for retrying are described in Section 7.1.

8 Proxy Behavior

   Session timers are mostly of interest to call stateful proxy servers.
   However, a stateful proxy server MAY also follow the rules described
   here. Stateless proxies MUST NOT attempt to request session
             timer. timers.
   Proxies which ask for session timers SHOULD record-route, since they
   won't receive refreshes if they don't.

        The proxy forwards processing rules require the response upstream normally.
             There are no proxy to remember
        information between the request and response, ruling out
        stateless proxies.

8.1 Processing of requests

   Processing of requests is identical for INVITE and re-INVITE
   requests.

   To request a session timers timer for this a call leg.

        CASE III: UAS supports, UAC doesn't. In this case, the final
             response contains (either in progress or
   initial), a proxy makes sure that a Session-Expires header with the
             refresher parameter set to "uas". The is present
   in an INVITE that it proxies for that call. A proxy forwards the
             response upstream.

        CASE IV: UAC supports, UAS supports. In this case, the final
             response contains MAY insert a
   Session-Expires header. The refresher
             parameter indicates who is performing header in the refreshes. This
             case will also occur when request before forwarding it, if none
   was present in the UAC supports session timer,
             and request. This Session-Expires header may contain
   any desired expiration time the UAS doesn't, proxy would like, but not with a downstream proxy had recognized
             this as CASE I and inserted
   duration lower than the Session-Expires and Require
             headers into value in the response. The proxy forwards Min-SE header in the response
             upstream.

   In all cases, request, if the final response forwarded upstream by the
   present. The proxy
   contains MUST NOT insert a Session-Expires header, its refresher parameter with value represents the
   expiration time of the session for the call leg associated
   uac. It MAY insert one with value "uas", but this is redundant since
   the UAS will conclude that
   response. There can be multiple 200 class responses to a single
   INVITE, each representing a different call leg, resulting it needs to refresh in multiple
   session timers, one for each call leg.

   In all cases, any case.

   If the request already had a Session-Expires header, the proxy MUST NOT modify MAY
   reduce the value of the Session-
   Expires header received in the response (assuming one was present)
   before forwarding Session-Expires header, but MUST NOT set it upstream.

   The expiration of
   to a duration lower than the call leg will occur at value in the time indicated Min-SE header in the Session-Expires header.
   request, if present. If the value of the Session-Expires header contains a
   delta-time, the expiration time is
   greater than or equal to the time of receipt of value in the final
   response, plus Min-SE header (recall that delta time.

   Re-INVITE requests may arrive from either UA, refreshing
   the session
   and extending default is zero when Min-SE is not present), the expiration time. Processing of these re-INVITEs by
   a proxy is identical to MUST NOT
   increase the procedure for processing value of the initial
   INVITE. Session-Expires header. If the session expires without having seen a response to a re-INVITE, value of the proxy MAY consider
   Session-Expires header is lower than the value of the Min-SE header
   (possibly because the call leg terminated. This means it MAY
   flush any state associated with that call leg.

   Note that a proxy MUST NOT send a BYE request once increased the session
   expires.

7 UAS Behavior

   When a UAS receives an INVITE for a new call, and that INVITE
   contains a Session-Expires value of the Min-SE header,
   as described below), the UAS proxy MUST place a Session-
   Expires header in a 200 class response (assuming the UAS accepts increase the
   call). The UAS MAY reduce value of the expiration time when
   Session-Expires to make it places this
   header into the response, but equal to Min-SE. The proxy MUST NOT set it to a duration lower
   than insert
   or modify the value of the "refresher" parameter in the Min-SE Session-
   Expires header if the header was present in the request, if present. The
   UAS MUST NOT increase received request.

   If the request contains a Supported header with a value of "timer", the duration.

   The UAS
   proxy MAY reject the INVITE request if the requested session timer
   value interval in the
   Session-Expires header is smaller than the minimum value timer defined in UAS
   the proxies local policy. The UAS proxy does so by sending a 422 Session
   Timer Too Small response message. When sending the 422 response
   message, 422 response
   message, the proxy MUST include a Min-SE header with the value of its
   minimum timer.

   If the request doesn't indicate support for session timer, but the
   request contains a session interval that is too small, the proxy
   cannot usefully reject the request, as this would result in a call
   failure. Rather, the proxy SHOULD insert a Min-SE header containing
   its minimum timer. If a Min-SE header is already present, the proxy
   SHOULD increase (but MUST NOT decrease) the value to equal its
   minimum timer. The proxy MUST then increase the Session-Expires value
   to be equal to the value in the Min-SE header, as described above. A
   proxy MUST NOT insert a Min-SE header, or modify the value of an
   existing header, in a proxied request if that request contains a
   Supported header with the value "timer". This is needed to protect
   against certain denial of service attacks, described in Section 11.

   Assuming the has requested session timer (and thus has possibly
   inserted the Session-Expires header or reduced it), the proxy MUST
   remember that it is using session timer, and also remember the value
   of the Session-Expires header from the proxied request. This MUST be
   remembered for the duration of the transaction. The proxy MUST
   remember, for the duration of the transaction, whether the request
   contained the UAS MUST include a Session-Expires Supported header with a the value
   that is acceptable to it. "timer".

   If the inital INVITE request did not contain a Session-Expires header, and Supported header with the UAS wishes to use refreshes for value
   "timer", the session, it MUST proxy MAY insert a
   Session-Expires Require header into the response. This header MAY have any
   desired expiration time greater than the value in the Min-SE header
   from the request, if present.

   The UAS MUST set with
   the value of the refresher parameter in the
   Session-Expires header present in a 200 class response. "timer". However, this is NOT RECOMMENDED. This value
   specifies who will perform refreshes allows the
   proxy to insist on session timer for the call leg. The value session. This header is
   set based on not
   needed if a Supported header was in the value of this parameter request; in this case, the request and on
   whether
   proxy can already be sure that the UAC supports session timer. Table 3 defines how timer can be used for the value
   in
   session.

8.2 Processing of Responses

   When the final response to the request arrives, it is set. A value of 'none' in examined by the 2nd column means
   proxy.

   If the response does not contain a Session-Expires header, but the
   proxy remembers that there was no refresher parameter it requested a session timer in the request. A value of 'NA' request (by
   inserting, modifying, or examining and accepting the Session-Expires
   in the third column proxied INVITE), this means that this particular combination shouldn't
   happen, as its disallowed by the protocol.

         UAC supports?  refresher parameter  refresher parameter
                        in request           in response
         N              none                 uas
         N              uac                  NA
         N              uas                  NA
         Y              none                 uas or uac
         Y              uac                  uac
         Y              uas                  uas

   Table 3: UAS Behavior

   In did not support the fourth row of Table 3, since
   session timer. If the UAC supports proxy remembers that the UAC did not support
   session
   timer, and so does timer either, the UAS, proxy forwards the UAS can elect response upstream
   normally. There is no session expiration for itself or this call leg. If,
   however, the proxy remembers that the UAC
   to perform did support session timer,
   additional processing is needed.

   Because there is no Session-Expires or Require in the refreshes.

   If response, the refresher parameter in
   proxy knows it is the first session-timer-aware proxy to receive the
   response. This proxy MUST insert a Session-Expires header in into the 200
   class
   response has a with the value it remembered from the forwarded request. It
   MUST set the value of "uac", the UAS "refresher" parameter to "uac". The proxy
   MUST place a also insert the Require header into the response response, with the value "timer".
   "timer", before forwarding it upstream.

   If the UAS response received contains a Session-Expires header, no
   additional response processing is generating refreshes, it needed. The response is processed
   normally.

   In all cases, if the final response forwarded upstream by the proxy
   contains a Session-Expires header, its value represents the session
   interval for the call leg associated with that response. The proxy
   computes the session expiration as the time
   of when the 2xx response is
   forwarded upstream, plus the session based on interval. This session
   expiration MUST update any existing session expiration for the value of call
   leg. The refresher param in the Session-Expires header in the 2xx
   response forwarded upstream will be present, and it sent. If the Session-Expires contains an absolute
   time, that indicates which
   UA is performing the time of expiration. If it contains refreshes. There can be multiple 200 class
   responses to a single INVITE, each representing a delta-time, different call leg,
   resulting in multiple session expirations, one for each call leg.

   In all cases, the expiration time is proxy MUST NOT modify the time of transmission value of the response plus
   that delta time. Let the difference Session-
   Expires header received in time between the transmission
   of the response and (assuming one was present)
   before forwarding it upstream.

8.3 Session Expiration

   When the session expiration current time be called equals or passes the refresh
   interval. Note that this session expiration applies only to for a
   call leg, the proxy MAY remove associated call leg state, and MAY free
   any resources associated with the response.

   If the UA wishes to continue with the session beyond call. Unlike the expiration, UA, it MUST generate NOT
   send a refresh before BYE.

9 UAS Behavior

   When a UAS receives an INVITE, the expiration time. It is
   RECOMMENDED processing of that this refresh INVITE can
   logically be sent once half broken into two steps. In the refresh interval
   has elapsed. The procedures for performing this refresh are described first step, the UAS acts
   as a "virtual proxy", and follows the rules specified in Section 8.

8 Performing Refreshes

   The refresh is accomplished by sending 8.1
   as if it were a re-INVITE request on the
   given call leg. Sending of proxy. This means that the refresh (in terms of same session timer
   manipulations that a proxy can do, can also be done by a UAS.
   Specifically, this extension),
   and processing means that it can insert or reduce the response are exactly identical to session
   timer (but not below Min-SE if present), reject the rules in
   Sections 5 request with a
   422, and 7. However, insert/increase the Min-SE, just as discussed in Section 4, if a proxy can. Of course,
   rather than proxying the UAC
   received any 422 responses for this request, the "modified" request is passed
   into the second step of processing, which we call leg, the re-INVITE MUST
   contain "virtual UAS"
   processing. Viewing the UAS as the concatenation of a proxy and a Min-SE header with
   UAS-specific processing component simplifies the largest specification of all durations returned in
   all 422 responses on
   behavior and guarantees consistency. This separation is for the
   purposes of defining behavior. It does not mandate that call leg. The re-INVITE SHOULD contain a
   Session-Expires header, with an duration equal to the last duration.
   For example, if
   implementation work this way.

   Once the initial INVITE sequence results in a session
   timer of 200 seconds, request is received by the re-INVITE SHOULD contain a session timer virtual UAS (assuming it is
   received; it may have been rejected with a value of 200 seconds. The re-INVITE MAY contain a different
   expiration, but this should only be done if 422 based on the UA rules in
   Section 8.1), virtual UAS processing begins. If the virtual UAS
   wishes to change accept the session expiration.

   If call, it copies the value of the Session-Timer is placed in
   from the re-INVITE, request received from the first step into the 2xx response.

   The virtual UAS MUST then set the value of the refresher parameter SHOULD be present, and SHOULD identify in
   the element
   currently responsible for refreshes. This means that a re-INVITE may
   have Session-Expires header present in a refresher parameter with 200 class response. This
   value "uas", if the element not
   performing specifies who will perform refreshes sends a re-INVITE for some other, non-session-
   timer reason. the call leg. The refresher parameter MAY be
   value is set to identify based on the
   element not performing refreshes at value of this time. This will result parameter in a
   change of roles.

   If the 200 OK to request and
   on whether the re-INVITE has no Session-Expires, no expiration
   time exists for UAC supports session timer. Table 3 defines how the session. This can happen if
   value in 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, response MUST be set. A value of 'none' in the
   proxies or UAS do not need to continue requesting session timer even
   though they did so 2nd
   column means that there was no refresher parameter in the first time. request. A UA MAY use
   value of 'NA' in the refreshing re-INVITE as a normal SIP re-INVITE; third column means that
   is, this re-INVITE MAY contain an updated session description. particular
   combination shouldn't happen, as its disallowed by the protocol.

   In the
   case where fourth row of Table 3, since the re-INVITE contains an updated session description, UAC supports the session description MUST somehow indicate that it has changed. In
   timer, and so does the
   case of SDP [4], this is accomplished by using a different value UAS, the UAS can elect for itself or the origin field.

   If UAC
   to perform the refreshing re-INVITE is used solely for refreshing, it SHOULD
   still contain a session description, unchanged from refreshes.

   Note that the previous
   INVITE. The session description MUST somehow indicate results of the above table are that it has not
   changed. In the case UACs choice of SDP, this is accomplished
   refresher cannot be changed by including the
   same value for virtual UAS.

         UAC supports?  refresher parameter  refresher parameter
                        in request           in response
         N              none                 uas
         N              uac                  NA
         N              uas                  uas
         Y              none                 uas or uac
         Y              uac                  uac
         Y              uas                  uas

   Table 3: UAS Behavior

   If the origin field as previous messages to its peer. The
   same is true for refresher parameter in the Session-Expires header in the 200
   class response to has a re-INVITE used solely
   for refreshing. The response value of "uac", the UAS MUST contain place a session description Require
   header into the response with
   an indication that it has not changed. the value "timer". This is accomplished in because the
   uac is performing refreshes and the
   same way as response has to be processed for
   the request. UAC to know this. If no the refresher parameter in the 200 class
   response to has a refreshing re-INVITE is received before the
   expiration value of "uas", and the session, Supported header in the UA SHOULD send a BYE
   request to
   terminate contained the call. It value "timer", the UAS SHOULD send this BYE slightly before
   expiration of place a Require
   header into the session. The minimum of ten seconds and one third response with the session interval is RECOMMENDED.

        For example, if value "timer". In this case, the session interval
   UAC is 120 seconds, one
        third of this not refreshing, but it is 40 seconds. supposed to send a BYE if it never
   receives a refresh. Since the minimum call will still succeed without the UAC
   doing this, insertion of 10
        seconds and 40 seconds is 10 seconds, the BYE would be sent
        10 seconds before Require is a SHOULD here, rather than a
   MUST.

   The UAS remembers the session expires.

        Firewalls and NATs may be very unforgiving about allowing
        SIP traffic to pass after interval for a call leg as the expiration time value of
   the
        session. It is for this reason that delta-time from the BYE should be sent
        before Session-Expires header in the expiration.

   It is possible most recent 2xx
   response to INVITE on that the calling UA call leg. It also remembers whether it, or
   its peer, 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 refresher on the other UA perform them. This also implies that leg.

   If the
   responsibility for generating refreshes may change during UAS must refresh a call.
   This happens commonly in one specific case - both caller and callee
   support leg, it computes the session timer. expiration for
   that leg. The caller will be doing re-INVITEs initially.
   If session expiration is the callee re-INVITEs, it becomes time of transmission of the UAC for this transaction,
   and
   last 2xx INVITE response on that leg plus the rules defined in this specification may result in a change in
   refresh responsibility session interval for
   that leg. If UA wishes to continue with the called party. In general, when both
   parties support session timer, refreshes become the responsibility of beyond the party which performed
   session expiration, it MUST generate a refresh before the last INVITE transaction. session
   expiration. It is possible RECOMMENDED that this refresh be sent once half the
   session interval has elapsed. Additional procedures for this refresh
   are described in Section 10.

10 Performing Refreshes

   The side generating a UAS refresh does so according to believe that an INVITE is an initial
   INVITE, and for the UAC procedures
   defined in Section 7.

   If no response to believe it is a re-INVITE. This happens
   when a UA crashes and reboots between refreshes. When refreshing re-INVITE is received before the refresh
   arrives at
   session expiration, the rebooted UA, it decides UA SHOULD send a BYE request to reject the call (generally,
   it will reject terminate the call unless it explicitly is capable
   call. It SHOULD send this BYE slightly before session expiration. The
   minimum of recovering
   lost calls). If From tags are used, the UAS can detect that ten seconds and one third the re-
   INVITE session interval is for an existing call by
   RECOMMENDED.

        For example, if the existence session interval is 120 seconds, one
        third of this is 40 seconds. Since the tag in the To
   field minimum of 10
        seconds and 40 seconds is 10 seconds, the BYE would be sent
        10 seconds before 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 expires.

   Similarly, if the side not performing refreshes does not receive a
   re-INVITE for a call that it believes is already terminated
   SHOULD respond with a 481. A UAC receiving a 481 to a refreshing the session timer
   refresh MUST generate before the session expiration, they
   SHOULD send 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 call, slightly before the UAC inserts a
        From tag. This ambiguity is resolved by mandating use of
        From tag with session timer.
   expiration. The requirement for From tags minimum of ten seconds and responding with a 481 to
        stale re-INVITEs has been added one third the session
   interval is RECOMMENDED.

        Firewalls and NATs may be very unforgiving about allowing
        SIP traffic to pass after the updated version expiration time of
        RFC2543. However, to eliminate a dependency between the
        session. It is for this
        spec and reason that the new version of SIP, these two features are
        specified here as well.

9 BYE should be sent
        before the expiration.

11 Security Considerations

   The session timer introduces the capability of a proxy or UA element
   to effectively force compliant clients to send refreshes at a rate of the proxies
   element's choosing. It
   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 proxies
   or UASes introducing denial-of-service attacks. Use of short
   refresh intervals allows However, the proxies or
   mechanisms in this specification prevent that from happening.

   First, consider the case of a rogue UAC that wishes to force a UAS to create network load.
   This is preventable using the 422 response
   generate refreshes at a rapid rate. To do so, it inserts a Session-
   Expires header into an INVITE with a low duration and Min-SE a refresher
   parameter equal to uas. Assume it places a Supported header
   mechanism. into the
   request. Any proxy proxy, or the UAS can UAS, which objects to this low timer will
   reject an the request with a 422, therefore preventing the attack. If no
   Supported header was present, the proxies will insert a Min-SE header
   into the request before forwarding it. As a result, the UAS will not
   choose a session timer lower than the minimum acceptable one to all
   elements on the path. This too prevents the attack.

   Next, consider the case of a rogue UAS that wishes to force a UAC to
   generate refreshes at a rapid rate. In that case, the UAC has to
   support session timer. The initial INVITE arrives at the rogue UAS,
   which returns a 2xx with a low very small session interval. The UAC uses
   this timer, and quickly sends a refresh. Section 7.1 requires the UAC will then include this minimum in
   to copy the
   Min-SE current session interval into the Session-Expires header
   in subsequent requests. No compliant proxy the request. This enables the proxies to see the current value.
   The proxies will then
   use reject this request, and provide a session timer Min-SE with a lower value. Rogue
   higher minimum. The UAC will then use this higher minimum. Note, that
   if the proxies did not reject the request, but rather proxied the
   request with a Min-SE header, an attack would still be possible. The
   UAS could strip the
   Min-SE, but in discard this case, UA configuration should ideall prevent header in a 2xx response, and force the
   attacks by refusing UAC to use
   continue to generate rapid requests.

   In a session timer lower than similar fashion, a specific
   value (30 minutes is recommended here). rogue proxy cannot force either the UAC or
   UAS to generate refreshes unless the proxy remains on the signaling
   path, and sees every request and response.

   It is also RECOMMENDED that IP or transport level security is used
   when communicating between proxies, and that requests with Session-
   Expires headers only be accepted over these secure transports.

10

12 Examples

   The following examples are meant to illustrate the functionality
   associated with the session timer. In the interest of brevity, all
   headers excepting except Supported, Session-Expires, Min-SE and Require are
   intentionally left out of the SIP messages.

10.1

12.1 Basic session timer

   In this case, two UAs communicate directly, with no proxies. Both
   support the session timer. The call is setup with a two minute
   session expiration. One minute later, the UAC refreshes the session.

   Calling UA -> Called UA
          INVITE
          Supported: timer
          Session-Expires: 120 3600

   Calling UA <- Called UA
          200 OK
          Require: timer
          Session-Expires: 120;refresher=uac 3600;refresher=uac   Called UA starts timer on send
                                                Calling UA starts timer on receipt
   Calling UA -> Called UA
          ACK

   60 seconds later:

   Calling UA -> Called UA
          INVITE
          Supported: timer
          Session-Expires: 120;refresher=uac 3600;refresher=uac
   Calling UA <- Called UA
          200 OK
          Require: timer
          Session-Expires: 120;refresher=uac 3600;refresher=uac   Called UA starts timer on send
                                                Calling UA starts timer on receipt
   Calling UA -> Called UA
          ACK

   110

   3550 seconds later the called UA did not receive a re-INVITE. It
   therefore considers the call terminated and sends a BYE:

   Calling UA <- Called UA
          BYE

   Calling UA -> Called UA
          200 OK

10.2

12.2 Basic negotiation of Session Time

   In this configuration, two UAs talk through a single proxy server.
   Both the proxy and the UAS reduce the session timer.

   Calling UA -> proxy
           INVITE
           Supported: timer
           Session-Expires: 240 3600

   proxy -> Called UA
           INVITE                proxy wants a shorter timer
           Supported: timer
           Session-Expires: 180

   proxy <- Called UA
           200 OK                              Called UA wants a shorter timer
           Session-Expires: 120;refresher=uac  Called UA starts timer
           Require: timer

   Calling UA <- proxy
           200 OK
           Session-Expires: 120;refresher=uac  Proxy starts timer on send
           Require: timer                      Calling UA starts timer on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

   For whatever reason, the calling UA decides not to refresh. So, after
   110 seconds, it sends a BYE.

   Calling UA -> proxy
           BYE

   proxy -> Called UA
          BYE

   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK

10.3

12.3 No Session-Expires Header in INVITE

   In this scenario, the UA sends an INVITE without a Session-Expires
   header and with a Supported header containing the option tag "timer".
   Since the proxy wants session timer for the call, it adds the
   Session-Expires header.

   Calling UA -> proxy
          INVITE                 No Session-Expires
          Supported: timer

   proxy -> Called UA
          INVITE
          Supported: timer
          Session-Expires: 120 3600   Proxy added Session-Expires

   proxy <- Called UA
          200 OK
          Session-Expires: 120;refresher=uac 3600;refresher=uac   Called UA starts timer on send
          Require: timer

   Calling UA <- proxy
          200 OK
          Session-Expires: 120;refresher=uac 3600;refresher=uac   Proxy starts timer on send
          Require: timer                        Calling UA starts timer on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

10.4

12.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 wants session timer for the call it adds
   Session-Expires header before proxying the INVITE to the called UA.

   Calling UA -> proxy
           INVITE

   proxy -> Called UA
           INVITE                Proxy adds session expires
           Session-Expires: 180 3600

   proxy <- Called UA
           200 OK                              Called UA wants a shorter timer
           Session-Expires: 120;refresher=uas  Called UA starts timer on send

   Calling UA <- proxy
           200 OK
           Session-Expires: 120;refresher=uas  Proxy starts timer on send
                                               Called UA starts timer on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

   Sixty seconds later, the called UA sends a re-INVITE. Note that the
   called UA does support session timer, so it includes a
   header{Supported} header in the request. The proxy adds the
   Session-Expires and Require headers into the response from the calling
   UA.

   proxy <- Called UA
          INVITE
          Supported: timer
          Session-Expires: 120;refresher=uac

   Calling UA <- proxy
          INVITE
          Supported: timer
          Session-Expires:120;refresher=uac

   Calling UA -> proxy
          200 OK

   proxy -> Called UA
          200 OK
          Session-Expires: 120;refresher=uac  Proxy updates timer on send
          Require: timer                      Called UA updates timer on receipt

   proxy <- Called UA
          ACK

   Calling UA <- proxy
          ACK

   The Calling UA terminates the session for non timer
   related reasons:

   Calling UA -> proxy
          BYE

   proxy -> Called UA
          BYE

   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK

10.5

12.5 Session Timer without Called UA Support

   In this scenario, the calling UA indicates that it supports the
   session timer, but does not add the Session-Expires header into the
   INVITE. The proxy adds it, but session timer is not supported by the
   UAS. The call is still set up with a session timer, as all that is
   required is for one of the user agents involved in the call leg to
   understand the "timer" feature.

   Calling UA -> proxy
          INVITE
          k: timer

   proxy -> Called UA
          INVITE                    proxy adds S-E header
          k: timer
          Session-Expires: 180 3600

   proxy <- Called UA
          200 OK                 Called UA doesn't understand session timer

   Calling UA <- proxy
          200 OK
          Session-Expires: 180;refresher=uac 3600;refresher=uac  Proxy adds S-E and Require
          Require: timer                       Proxy starts timer on send
                                               Calling UA starts timer on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

   The UAC then re-invites, which is responded to with a 400 because the
   new media streams were rejected. Since this is a re-INVITE, the
   session is still active.

   Calling UA -> proxy
          INVITE
          k: timer
          Session-Expires: 180;refresher=uac   UA asks for timer this time
                                               This is not mandatory

   proxy -> Called UA
          INVITE                    proxy does not reduce Session-Expires header
          k: timer
          Session-Expires: 180;refresher=uac

   proxy <- Called UA
          400 Rejected Media        Called UA doesn't understand session timer

   Calling UA <- proxy
          400 Rejected Media

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

10.6 Proxy insists on session timer

   In this scenario, the calling UA does not support the session timer,
   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
   rejects the request with a 420 as per standard RFC2543 extension
   handling. This response is forwarded upstream towards the UAC. The
   UAC treats it as a normal 400 class response, and then ACKs it. In
   this case, the call cannot be established.

        It is slightly odd that a UAC will send a request without a
        Require header, and yet get a 420 response back with an
        Unsupported header. Normal UAs that don't support session
        timer should handle this case correctly, treating it just
        as Since this is a normal 400 class response.

   Note that proxy insertion of Require re-INVITE, the
   session is NOT RECOMMENDED. still active.

   Calling UA -> proxy
          INVITE
          k: timer
          Session-Expires: 3600;refresher=uac   UA asks for timer this time
                                                This is not mandatory

   proxy -> Called UA
          INVITE                    proxy adds session expires
           Require: does not reduce Session-Expires header
          k: timer        proxy adds Require
          Session-Expires: 180 3600;refresher=uac
   proxy <- Called UA
           420 Bad Extension
           Unsupported:
          400 Rejected Media        Called UA doesn't understand session timer

   Calling UA <- proxy
           420 Bad Extension
           Unsupported: timer
          400 Rejected Media

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

10.7

12.6 Neither UA Supports Session Timer

   In this case, neither UA supports the session timer. However, one of
   the proxies on the call setup path requests (but does not require)
   it. The call completes without session timers.

   Calling UA -> proxy
          INVITE

   proxy -> Called UA
          INVITE                    proxy adds S-E header compact form
          x: 180 3600

   proxy <- Called UA
          200 OK                 Called UA doesn't understand session timer

   Calling UA <- proxy         proxy doesn't add S-E since it knows Calling UA
          200 OK               doesn't support it

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

10.8

12.7 Both UAs Support, Change in Roles

   In this case, both user agents support session timer. The initial
   INVITE from caller to callee results in refreshes being generated by
   the caller. A re-INVITE sent from the callee changes that role so
   that the callee refreshes.

   Calling UA -> proxy
           INVITE
           Supported: timer
           Session-Expires: 240 3600

   proxy -> Called UA
           INVITE                Proxy wants timer, no change in value
           Supported: timer
           Session-Expires: 240 3600

   proxy <- Called UA
           200 OK                               Called UA supports timer
           Session-Expires: 240;refresher=uac 3600;refresher=uac  Inserts Require, Session-Expires
           Require: timer                       Called UA starts timer on send

   Calling UA <- proxy                          Calling UA sees refresher=uac
           200 OK                               It is refreshing
           Session-Expires: 240;refresher=uac 3600;refresher=uac  Proxy starts timer on send
           Require: timer                       Calling UA starts timer on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

   The called UA (which is a UAC for this transaction) now sends a re-
   INVITE. For whatever reason, it decides to switch roles by explicitly
   designating the itself as the refresher.

   proxy <- Called UA
           INVITE
           Supported: timer
           Session-Expires: 240;refresher=uac 3600;refresher=uac

   Calling UA <- proxy
           INVITE                proxy wants timer, no change in value
           Supported: timer
           Session-Expires: 240;refresher=uac 3600;refresher=uac
   Calling UA -> proxy
           200 OK                               Calling UA supports timer
           Session-Expires: 240;refresher=uac 3600;refresher=uac  Inserts Session-Expires
           Require: timer                       Calling UA updates timer on send

   proxy -> Called UA                           Called UA sees 200 w/refresher=uac
           200 OK                               It is refreshing
           Session-Expires: 240;refresher=uac 3600;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

12.8 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
         Session-Expires: 250;refresher=uac 200;refresher=uac   UAS lowers to 200

   Calling UA <- Proxy
         200
         Require: timer
         Session-Expires: 250;refresher=uac

   Calling UA -> Proxy
         ACK

   Proxy -> Called UA
         ACK

11 Acknowledgements

   The authors wish
         Session-Expires: 200;refresher=uac

   Calling UA -> Proxy
         ACK

   Proxy -> Called UA
         ACK

13 Acknowledgements

   The authors wish to thank Brett Tate for his contributions to this
   work.

14 Changes since -05

        o Added a section explicitly defining the 422 response code.

        o Clarified UAC behavior for 422, distinguishing between calls
          and call legs.

        o Merged normative text in Section 2 with the rest of the
          document. Section 2 is now purely tutorial, at a higher level.

        o Clarified that the recommended minimum value for Session-
          Expires is 30 minutes. The previous text just talked about the
          "interval", without a formal definition of what interval might
          mean.

        o Min-SE now used in 422 response, instead of Session-Expires,
          based on agreement at IETF 51.

        o Clarified that Require in a request does not mean that the UAS
          is being required to perform refreshes, just that its required
          to support the extension.

        o Updated row three of Table 3 to indicate a value of "uas"
          since this case is actually possible. Updated the related text
          in the section on proxy behavior to describe the scenario.

        o Based on IETF 51 discussions, removed absolute time. Everyting
          is now in delta-seconds.

        o Removed example flow that uses Require header. No reason to
          list flows that are not recommended.

        o Updated examples to use recommended values for parameters.

        o Added terminology section, reworked text to use consistent
          terms based on that section.

        o Modeled the behavior of a UAS as the concatenation of a proxy
          and virtual UAS, so that a UAS could perform the same session
          timer manipulations as a proxy without respecification of the
          rules for such processing.

        o Generalization of the request processing behaviors to thank Brett Tate work for his contributions
          both INVITE and re-INVITE, which allowed for the removal of
          the secion on performing refreshes.

        o Allow proxies to this
   work.

12 insert or increase Min-SE (and possibly
          increase Session-Timer as a result) in order to handle the
          case when the UAC doesn't support session timer, and a proxy
          receives a request with a value that is too small.

        o Min-SE header in initial INVITE is the maximum of the values
          returned in 422, AND also received in any INVITE. Previously,
          it was just 422. This change is needed because of the previous
          item.

        o Improvied Security Considerations section to explicitly
          consider several DoS cases.

15 Changes since -04

        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 Removed text about inserting Session-Expires:0 when you want
          to indicate that the call is down. Rather, send a 481.

        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

16 Author's Addresses

   Steven R. Donovan
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: sdonovan@dynamicsoft.com

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

14

17 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
   transport protocol for real-time applications," Request for Comments
   1889, Internet Engineering Task Force, Jan. 1996.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [4] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
   Internet Draft, Internet Engineering Task Force, Feb. 2001.  Work in
   progress.

   [4] M. Handley and V. Jacobson, "SDP: session description protocol,"
   Request for Comments 2327, Internet Engineering Task Force, Apr.
   1998.

                           Table of Contents

   1          Introduction ........................................    1
   2          Terminology .........................................    2
   3          Protocol Overview ...................................    2    3
   4          Session-Expires Header Field Definition .............    4
   4    5
   5          Min-SE Header Field Definition ......................    6
   5
   6          422 Response Code Definition ........................    7
   7          UAC Behavior ........................................    7
   6
   7.1        Generating an INVITE Request ........................    7
   7.1.1      Example .............................................    9
   7.2        Processing a 2xx Response ...........................   10
   7.3        Processing a 422 Response ...........................   11
   8          Proxy Behavior ......................................    9
   6.1   11
   8.1        Processing of requests ..............................    9
   6.2   11
   8.2        Processing of Responses .............................   10
   7   13
   8.3        Session Expiration ..................................   14
   9          UAS Behavior ........................................   11
   8   14
   10         Performing Refreshes ................................   13
   9   15
   11         Security Considerations .............................   15
   10   16
   12         Examples ............................................   16
   10.1   17
   12.1       Basic session timer .................................   16
   10.2   17
   12.2       Basic negotiation of Session Time ...................   17
   10.3   18
   12.3       No Session-Expires Header in INVITE .................   18
   10.4   19
   12.4       Session timer without Calling UA Support ............   18
   10.5   20
   12.5       Session Timer without Called UA Support .............   20
   10.6       Proxy insists on session timer ......................   22
   10.7   21
   12.6       Neither UA Supports Session Timer ...................   22
   10.8   23
   12.7       Both UAs Support, Change in Roles ...................   23
   10.9
   12.8       Proxy Rejects Timer .................................   25
   11
   13         Acknowledgements ....................................   26
   12
   14         Changes since -04 -05 ...................................   26
   13
   15         Changes since -04 ...................................   27
   16         Author's Addresses ..................................   27
   14   28
   17         Bibliography ........................................   27   29