Internet Engineering Task Force                                   SIP WG
Internet Draft                                     S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-08.txt                                                 S.Donovan
                                                             dynamicsoft
October 6, 2001
Expires: April
                                                             J.Rosenberg
                                                             dynamicsoft
draft-ietf-sip-session-timer-09.txt
July 1, 2002

                         The SIP
Expires: January 2003

        Session Initiation Protocol Extension for 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 defines an extension to the Session Initiation Protocol
   (SIP). This extension allows for a periodic refresh of SIP sessions
   through a re-INVITE. re-INVITE or UPDATE request. The refresh allows both user
   agents and proxies to determine if the SIP session is still active.
   The extension defines two new general headers, header fields, 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 define a
   keepalive mechanism. mechanism for the sessions it establishes. Although the
   user agents may be able to determine if the session has timed out
   using session specific mechanisms, proxies will not be able to do so.
   The result is that call stateful proxies will not always be able to
   determine whether a call session 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 re-INVITE or UPDATE [2] requests
   (referred to as session refresh requests) to keep the session alive.
   The interval for the re-INVITEs session refresh requests is determined through a
   negotiation mechanism defined here. If a re-INVITE session refresh request is
   not received before the interval passes, the session is considered
   terminated. Both UAs are supposed to send a BYE, and call stateful
   proxies can remove any state for the call.

        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]. [5]. However, it is
   desirable to separate SIP call session liveness from the details of the
   particular session.

   Another application of the session timer is in the construction of a
   SIP NAT ALG. Network Address Translator (NAT) Application Level Gateway (ALG)
   [6]. The ALG embedded in a NAT will need to maintain state for the
   duration of a call. This state must eventually be removed. Relying on
   a BYE to trigger the removal of state, besides being unreliable,
   introduces a potential denial of service attack.

   This document proposes an extension to SIP that defines a session
   expiration mechanism. Periodic refreshes, through re-INVITEs, re-INVITEs or
   UPDATEs, 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 dialog understand the
   extension. Two new
   general headers, header fields, Session-Expires and Min-SE, and a
   new response code, 422, are defined. Session-Expires conveys the
   duration of the session, and Min-SE conveys the minimum allowed value
   for the session expiration. The 422 response code indicates that the
   session timer duration was too small.

2 Terminology

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

   Additionally, we define the following terms:

        Session Interval: The largest amount of time that can occur
             between INVITE session refresh requests in a call dialog before it the
             session will be considered timed out. The session interval
             is conveyed in the Session-Expires header field defined
             here. The UAS obtains this value from the Session-Expires
             header of field in a 2xx INVITE response to a session refresh request
             that it sends. Proxies and UACs determine this value from
             the Session-Expires header field in a 2xx INVITE response to a
             session refresh request that they receive.

        Minimum Timer: Because of the processing load of INVITE mid-dialog
             requests, all elements (proxy, UAC, UAS) can have a
             configured minimum value for the session interval that they
             are willing to accept. This value is called the minimum
             timer.

        Session Expiration: The time at which an element will consider
             the call session timed out, if no successful INVITE session refresh
             transaction occurs beforehand.

        Refresh:

        Session Refresh Request: An INVITE or UPDATE request sent during an active call leg. within a
             dialog. If the request generates a 2xx response, the
             session expiration is increased to the current time plus
             the session interval obtained from the response. A session
             refresh request is not to be confused with a target refresh
             request, defined in Section 6 of [1], which is a request
             that can update the remote target of a dialog.

        Refresh: Same as a session refresh request.

3 Protocol Overview of Operation

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

   Session refreshes are accomplished using SIP INVITEs. INVITE or UPDATE [2]
   requests. The initial
   INVITE session refresh request establishes the
   duration of the session, which is carried in the Session-Expires
   header field in the 2xx response to the INVITE. session refresh request. The
   Session-Expires header field in the 2xx response also indicates which
   side will be responsible for generating these refreshes - the uac UAC or uas.
   the UAS. The responsible side then generates a refresh (using a re-INVITE) re-INVITE
   or UPDATE) before the session expires. If the refreshes refresher never gets a
   response to that re-INVITE, session refresh request, it sends a BYE to terminate
   the call. session. Similarly, if the other side never gets the re-INVITE session
   refresh request before the session expires, it sends a BYE. The refreshes themselves All
   session refresh requests are processed identically to
   a regular INVITE, the initial
   session refresh request, so that the 2xx response to a re-INVITE session
   refresh request carries the new time at which the session will
   expire.

   It is an explicit goal of the protocol this extension to operate so long as one of
   the two UAs in a call leg dialog support the extension. That side, of course,
   ends up performing the refreshes. The other side will merely see them
   as repetitive re-INVITEs. re-INVITE or UPDATE requests. This facilitates
   interoperability.

   The details of the protocol relate to extension supports negotiation of a reasonable value for the
   session interval, and negotiation of which side of the
   call leg dialog is
   performing the refreshes. Negotiation of the session interval is
   critical. The value must be small enough to provide a useful
   expiration, but not so small to overload the proxies with re-
   INVITEs. messages.
   The goal of the protocol negotiation algorithm is to choose a session interval
   that is the smallest of all the values requested by all elements, elements on
   the dialog path, but only if that value is larger than the largest
   minimum timer requested by all elements. Negotiation of the refresher
   role is simpler. If only one side supports the extension, that side
   acts as refresher. Otherwise, one side chooses who will refresh. This
   negotiation takes place as part of INVITE session refresh request
   processing, and due to the idempotency of
   INVITE requests, that processing, is effectively redone
   each time the session is
   refreshed with another re-INVITE. refreshed.

   To negotiate the value of the refresh interval, the Min-SE and
   Session-Expires headers header fields are used. The UAC generates an INVITE, a session
   refresh request, and includes a Session-Expires header field if it
   wishes to use the session timer. The Session-Expires header field
   value contains the session interval. As the INVITE session refresh request
   traverses proxies, the proxies (and the UAS) can reduce the value of
   the session timer, interval, but not lower than the value of the Min-SE header.
   header field. If a proxy or UAS receives a request with a Session-
   Expires header field value lower than a configured minimum, it can
   reject the request with a 422 response. This response contains a
   Min-SE header field with the minimum allowed value. The client
   retries the request, inserting a Min-SE header field containing the
   maximum value of the Min-SE headers header fields returned in previous 422
   responses for the call. In the case where the client UAC isn't aware of the
   session timer extension, a proxy that receives a session refresh
   request with a Session-Expires lower than the configured minimum
   places the Min-SE header field in the proxied request, and increases
   the Session-Expires header field value to that minimum. When the
   request eventually reaches the UAS (potentially after a few retries
   resulting from a 422), it will do so containing contain a Session-Expires header that field
   whose value meets the design criteria described above. The UAS
   returns a 200 OK with a Session-Expires header field containing the final duration of the
   session. that
   value. The header field also contains a parameter, called refresher,
   that indicates which side is performing the refreshes.

   This basic behavior is built upon to handle the case where only one
   side supports the extension.

   When only the UAC supports it, the session timer extension, one of the
   proxies "fills the shoes" of the UAS. Specifically, when the UAS does
   support session timer, it places the value of the session timer interval
   into the Session-Expires header field in the 2xx response. When the
   UAS doesn't support it, the proxy closest to the UAS that asked for a
   session expiration performs that job, and inserts the value of the timer
   session interval into the 2xx response as it passes by.

   It is worth noting that the session timer refreshes the session, not
   the dialog used to establish the session. Of course, the two are
   related. If the session expires, a BYE is sent, which terminates the
   session and generally, the dialog.

4 Session-Expires Header Field Definition

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

   There is no absolute minimum value for the Session-Expires header. header
   field. However, 1800 seconds (30 minutes) is RECOMMENDED. In other
   words, SIP entites MUST be prepared to handle Session-Expires header
   field values of any duration, but entities that insert the Session-Expires Session-
   Expires header field SHOULD NOT choose values less than 30 minutes.

   Small session intervals can be destructive to the network. They cause
   excessive messaging traffic that affects both user agents and proxy
   servers. They increase the possibility of re-INVITE collisions (when "glare" which can occur
   when both parties re-INVITE each other user agents send a re-INVITE or UPDATE at the same time). time.
   Since the primary purpose of the session timer is to provide a means
   to time out state in SIP elements, very small values won't generally
   be needed. 30 minutes was chosen 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, not just a phone call. At the time of
   publication of this document, 30 minutes seems appropriate. Advances
   in technologies may result in the number being excessively large five
   years in the future.

   The default value of the Session-Expires header field, when not
   present, is infinity. This means that absence of the Session-Expires
   header field implies no expiration.

   The syntax of the Session-Expires header field is:

        Session-Expires  =  ("Session-Expires" | / "x") ":" HCOLON delta-seconds
                            [refresher]
        refresher
                            *(SEMI se-params)
        se-params        =  refresher-param / generic-param
        refresher-param  =  ";"  "refresher" "=" "uas"|"uac"
   The optional refresher parameter indicates who will be doing the
   refreshing. It is RECOMMENDED that this parameter not be present in
   an initial INVITE, so that the negotiation mechanisms can
   successfully determine who will perform them. A 2xx response with the
   Session-Expires header MUST contain this parameter, indicating who
   will perform the refreshes. If the UAC wishes to insist on performing
   the refreshes, it MAY insert the parameter with a value of "uac" in
   the INVITE. It MAY use a value of "uas" if it knows that the other
   side supports session timer. It could know this by having received a
   request with a Supported header containing the value "timer" from its
   peer, or because a 2xx response received from the peer had a
   refresher parameter with the value "uas". EQUAL ("uas" / "uac")

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

   Table 1 is an extension of tables 4 Tables 2 and 5 3 in [1] for the Session-
   Expires header: and Min-SE header fields. The column "PRA" is for the PRACK
   method [7], "UPD" is for the UPDATE method [2], "SUB" is for the
   SUBSCRIBE method [8], and "NOT" is for the NOTIFY method [8].

   Header field     where enc e-e  proxy ACK BYE CAN INV OPT REG
           _____________________________________________________ PRA UPD SUB NOT
   _____________________________________________________________________
   Session-Expires    R    n   h     amr   -   -   -   o   -   -   -   o   -  -
   Session-Expires   2xx   n   h    ar    -   -   -   o   -   -   -   o   -   -
   Min-SE             R     amr   -   -   -   o   -   -   -   o   -   -
   Min-SE            422          -   -   -   m   -   -   -   m   -   -

   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.

5 Min-SE Header Field Definition

   The Min-SE general Session-Expires and Min-SE Header Fields

5 Min-SE Header Field Definition

   The Min-SE header field indicates the minimum value for the session
   interval, in units of delta-seconds. When used in an INVITE or UPDATE
   request, it indicates the smallest value of the session interval
   which can be used for that session. A proxy or UAS MUST NOT reduce the value of
   the session interval below the value in this header, when present in
   an INVITE request.

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

   The Min-SE header MUST NOT field MUSTNOT 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 field is:

        Min-SE  =  "Min-SE" ":" HCOLON 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 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, "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. *(SEMI generic-param)

6 422 Response Code Definition

   This extension introduces the 422 (Session Interval Too Small)
   response code. The default reason
   phrase for this code is "Session Timer Too Small". It is generated by a UAS or proxy when a request
   contains a Session-Expires header field with a duration that is below
   the minimum timer for the server. The 422 response MUST contain a
   Min-SE header field with the minimum timer for that server.

7 UAC Behavior

7.1 Generating an INVITE a Session Refresh Request

   A UAC which supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" [4]. [1]. It MUST do so even if the UAC is
   not requesting keepalives for usage of the call. session timer for this session.

   The UAC MAY include a Require header field in the request with the
   value "timer" to indicate that the UAS must support the session timer
   to participate in the session. This does not mean that the UAC is
   requiring the UAS to perform the refreshes, just that it is requiring
   the UAS to support the extension. In addition, the UAC MAY include a
   Proxy-Require header field in the request with the value "timer" to
   indicate that proxies must support session timer in order to
   correctly process the request. However, usage of either Require or
   Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
   since the extension works even when only the UAC supports the
   extension. The Supported header field containing "timer" MUST still
   be included even if the Require or Proxy-Require headers header fields are
   present containing "timer".

   The UAC MUST insert the Min-SE header field into a re-INVITE session refresh
   request for a particular call leg dialog if it has ever received a 422
   response to a previous INVITE session refresh request on the same leg, dialog, or
   if it has received an INVITE a session refresh request on that call leg dialog which
   contained a Min-SE header. header field. Similarly, if no call
   leg dialog has been
   established yet, a UAC MUST insert the Min-SE header field into an
   INVITE request for a particular call if it has ever received a 422 response to a previous
   INVITE request with the same Call-ID.

   The value of the Min-SE header field present in the INVITE a session refresh
   request MUST be the largest value amongst all Min-SE header field
   values returned in all 422 responses, or received in INVITE session refresh
   requests, on the same call leg, dialog, if a
   call leg dialog has been established. If no leg is
   dialog has been established, the Min-SE header field value is set to
   the largest value amongst all Min-SE header field values returned in
   all 422 responses for an INVITE request with the same call. Call-ID. A
   result of this rule is that the maximum value of the Min-SE is
   effectively "cleared" once the
   call leg dialog is established, and from that
   point on, only the values from proxies known to be on the proxy path
   will end up being used.

   The UAC may have its own opinions about the minimum session interval.
   In that case, if the value above is too small, the UAC MAY increase
   it.

   A UAC MAY include the Min-SE header field in an INVITE request
   outside of a dialog, even if it never received a 422 previously.

   A UAC MAY include a Session-Expires in an initial INVITE session refresh
   request request if it wishes for a session timer to be applied. applied to the
   session. The value of this header field indicates the session
   interval desired by the UAC. In an INVITE that is
   within a call leg session refresh request sent within
   a dialog with an active session timer, the header field SHOULD be
   present. When present, and SHOULD contain the it MUST be equal to the larger maximum of the current Min-SE
   header field (recall that its default value of when not present is zero)
   and the current session interval and interval.

   In an initial session refresh request, the value of UAC MAY include the Min-SE,
   refresher parameter with value "uac" if present. it wishes to perform the
   refreshes. However, it is RECOMMENDED that the parameter be omitted,
   so that it can be selected by the negotiation mechanisms described
   below. If the INVITE session refresh request is a re-INVITE not the initial one, it is
   RECOMMENDED that the refresher parameter be set to "uac" if the
   element sending the INVITE request is currently performing refreshes, else
   "uas" if its peer is performing the refreshes. In an initial INVITE, the UAC MAY include This way, the role of
   refresher
   parameter with value "uac" does not change on each refresh. However, if it wishes to perform
   explicitly change the refreshes. If roles, it MAY use a value of "uas" if it knows
   that the UAC wishes to leave other side supports session timer. It could know this decision by
   having received a request from its peer with a Supported header field
   containing the value "timer". If it wishes to reselect the negotiation mechanisms
   described below, roles, it
   MAY omit the refresher parameter is omitted. parameter.

   A re-INVITE generated to refresh the session is a normal re-INVITE,
   and an UPDATE generated to refresh a session is a normal UPDATE. If a
   UAC knows that its peer supports the UPDATE method, it is RECOMMENDED
   that UPDATE be used instead of a re-INVITE. A UA can make this
   determination if it has seen an Allow header field from its peer with
   the value "UPDATE", or through a mid-dialog OPTIONS request. It SHOULD contain SDP is
   RECOMMENDED that describes the session, UPDATE request not contain an offer [4], but a
   re-INVITE SHOULD contain one, even if that SDP
   has the details of the session have
   not changed. In that case, the session description offer MUST somehow indicate that it has not
   changed. In the case of SDP, this is accomplished by including the
   same value for the origin field as previous SDP messages to its peer.
   The same is true for the 200 class
   response to an answer exchanged as a re-INVITE used solely for refreshing. The response MUST
   contain result of a session description with an indication that
   refresh request; if it has not
   changed. This is accomplished in the same way as for the request.

   It is possible for a UAS to believe changed, that an INVITE is an initial
   INVITE, and for the UAC to believe it is MUST be indicated.

7.2 Processing a re-INVITE. This happens
   when 2xx Response

   Session timer requires a UA crashes to create and reboots between refreshes. When the refresh
   arrives at maintain state. This state
   includes the rebooted UA, it decides to reject session interval, the call (generally,
   it will reject session expiration, and the call unless it explicitly is capable
   identity of recovering
   lost calls). If From tags are used, the UAS can detect that the re-
   INVITE refresher. This state is for an existing call by the existence of the tag in associated with the To
   field of dialog
   on which the re-INVITE. Therefore, a UAC MUST insert a From tag in an
   initial INVITE if it supports session timer. A UAS that wishes to
   reject a re-INVITE for a call that it believes is already terminated
   SHOULD respond with a 481. A UAC receiving has been negotiated.

   When a 481 2xx response to a session timer refresh MUST generate request arrives, it may or
   may not contain a BYE Require header field with the value "timer". If it
   does, the UAC MUST look for the Session-Expires header field to terminate that call leg.
   process the response.

   If From tags were not mandatory, A could INVITE B without a
        From tag. B inserts there was a tag Require header field in the 200 OK. Now, B sends a
        re-INVITE response with the value
   "timer", the Session-Expires header field will always be present.
   UACs MUST be prepared to A. Meantime, A has crashed and rebooted. This
        re-INVITE has receive a From tag, but no To tag. It therefore
        cannot be distinguished for Session-Expires header field in a new INVITE
   response even if none were present in which the UAC
        inserts a From tag. This ambiguity is resolved by mandating
        use of From tag with session timer. request. The requirement for From tags and responding with a 481 to
        stale re-INVITEs has been added to the updated version of
        RFC2543. However, to eliminate a dependency between this
        spec and the new version of SIP, these two features are
        specified here as well.

7.1.1 Example

   As an example, a UAC sends an INVITE with Call-ID 1, and receives a
   422 with a Min-SE header of 100. There is a tag "refresher"
   parameter will be present in the To Session-Expires header field, with
   a value of 8.
   indicating who will be performing the refreshes. The UAC retries the request. It contains a Min-SE
   header. Since no call leg has been established, MUST set the Min-SE header
   contains
   identity of the largest value amongst all Min-SE values returned in 422
   responses refresher to INVITEs with the same Call-ID, in value of this case, with parameter. If the
   parameter contains the
   Call-ID of 1. There has only been one such 422, and it had a Min-SE
   header with value 100. So, "uac", the retried INVITE contains UAC will perform them. It is
   possible that the UAC requested session timer (and thus included a Min-SE
   Session-Expires header with value 100, and no tag field in the To field, as request), but there is was no
   call leg established yet.

   This INVITE generates another 422, this time with a Min-SE
   Require or Session-Expires header
   with a value of 200 and a tag field in the To field with value 9. Once
   again, 2xx response. This
   will happen when the UAC retries UAS doesn't support the request. This time, session timer extension,
   and only the INVITE UAC has asked for a Min-
   SE with value 200. The call is accepted by the UAS, resulting in a
   200 OK with a tag in the To field of 10. Later, session timer (no proxies have
   requested it). In this case, if the UAC sends a re-
   INVITE still wishes to refresh. Since a call leg is established, use the
   session timer (they are purely for its benefit alone), it looks has to see
   whether there had been any Min-SE headers returned
   perform them. To do this, the UAC follows the procedures defined in any 422
   responses on
   this specification as if the same leg (that is, with a tag of 10). Since there Session-Expires header field were none, that refresh doesn't contain a Min-SE header.

   Later on, in the UA receives a re-INVITE from
   2xx response, and its peer, containing a
   Min-SE header with the value of 100. This sets was the maximum Min-SE
   value on this leg to 100. When same as the UA refreshes, it includes a Min-SE
   header one in the request,
   but with a value refresher parameter of 100.

7.2 Processing a 2xx Response

   When a "uac".

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

   If field,
   there was is no session expiration. In this case, no refreshes need to be
   sent. A 2xx without a Require header in Session-Expires can come for both initial and
   mid-dialog session refresh requests.

   The UAC remembers the response with session interval for a session as the value "timer", of
   the delta-time from the Session-Expires header will always be present. UACs MUST be
   prepared field in the most
   recent 2xx response to receive a Session-Expires header in session refresh request on a response even if
   none were present in the request. The "refresher" parameter will be
   present, indicating who will be performing the refreshes. If the
   parameter contains the value "uac", the UAC will perform them. It is
   possible that the UAC requested session timer (and thus included a
   Session-Expires in the request), but there was no Require or
   Session-Expires in the 200 class response. This will happen when the
   UAS doesn't support session timer, and only the UAC has asked for
   session timer (no proxies have requested it). In this case, if the
   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 Session-Expires
   header were in the 200 class response, and its value was the same as
   the one in the request (but with a refresher parameter of "uac").

   If the 2xx response did not contain a Session-Expires header, there
   is no session expiration. In this case, no refreshes need to be sent.
   A 2xx without a Session-Expires can come for both initial and mid-
   call INVITE requests.

   The UAC remembers the session interval for a call leg as the value of
   the delta-time from the Session-Expires header in the most recent 2xx
   response to INVITE on that call leg. It is explicitly allowed for
   there to dialog. 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 To field. dialogs established as a result of a single
   INVITE. It also remembers whether it, or its peer, is the refresher
   on for the
   leg. session.

   If the UAC must refresh a leg, perform the refreshes, it computes the session
   expiration for that leg. session. The session expiration is the time of
   reception of the last 2xx INVITE response to a session refresh request on
   that leg dialog plus the session interval for that
   leg. session. If UA wishes
   to continue with the session beyond the session expiration, it MUST
   generate a refresh before the session expiration. It is RECOMMENDED
   that this refresh be sent once half the session interval has elapsed.
   Additional procedures for this refresh are described in Section 10.

7.3 Processing a 422 Response

   If the response to an INVITE a session refresh request is a 422 Session Timer (Session
   Interval Too Small Small) response message, then the UAC MAY retry the INVITE.
   request. 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 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.

8.1 Processing of requests Requests

   Processing of requests is identical for INVITE and re-INVITE all session refresh requests.

   To request a session timer for a call (either in progress or
   initial), session, a proxy makes sure that a
   Session-Expires header field is present in an INVITE that it proxies a session refresh request
   for that call. session. A proxy MAY insert a Session-Expires header field
   in the request before forwarding it, if none was present in the
   request. This Session-Expires header field may contain any desired
   expiration time the proxy would like, but not with a duration lower
   than the value in the Min-SE header field in the request, if present.
   The proxy MUST NOT insert include a refresher parameter with value
   uac. It MAY insert one with value "uas", but this is redundant since
   the UAS will conclude that it needs to refresh in any case. the header field
   value.

   If the request already had a Session-Expires header, header field, the proxy
   MAY reduce the value in the Session-Expires header, its value, but MUST NOT set it to a duration lower than
   the value in the Min-SE header field in the request, if present. If
   the value of the Session-Expires header field is greater than or
   equal to the value in the Min-SE header field (recall that the
   default is zero when the Min-SE header field is not present), the
   proxy MUST NOT increase the value of the Session-Expires header. header
   field. If the value of the Session-Expires header field is lower than
   the value of the Min-SE header field (possibly because the proxy
   increased the value of the Min-SE header, header field, as described below),
   the proxy MUST increase the value of the Session-Expires header field
   to make it equal to Min-SE. Min-SE header field value. The proxy MUST NOT
   insert or modify the value of the "refresher" parameter in the Session-
   Expires header if the
   Session-Expires header was present in the received request. field.

   If the request contains a Supported header field with a value
   "timer", the proxy MAY reject the INVITE request with a 422 (Session
   Interval Too Small) response if the session interval in the
   Session-Expires Session-
   Expires header field is smaller than the minimum timer interval defined in by
   the proxies proxy's local policy. The proxy does so by sending a 422 Session
   Timer Too Small response message. When sending the 422 response
   message, response, the proxy
   MUST include a Min-SE header field with the value of its minimum timer.
   interval.

   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 field
   containing its minimum timer. interval. If a Min-SE header field is already
   present, the proxy SHOULD increase (but MUST NOT decrease) the value
   to equal its minimum timer. interval. The proxy MUST then increase the
   Session-Expires header field value to be equal to the value in the
   Min-SE header, header field, as described above. A proxy MUST NOT insert a
   Min-SE header, header field, or modify the value of an existing header, header field,
   in a proxied request if that request contains a Supported header
   field with the value "timer". This is needed to protect against
   certain denial of service attacks, described in Section 11.

   Assuming the proxy has requested a session timer (and thus has
   possibly inserted the Session-Expires header field or reduced it),
   the proxy MUST remember that it is using a session timer, and also
   remember the value of the Session-Expires header field 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 Supported header field
   with the value "timer".

   If the request did not contain a Supported header field with the
   value "timer", the proxy MAY insert a Require header field into the
   request, with the value "timer". However, this is NOT RECOMMENDED.
   This allows the proxy to insist on session timer for the session.
   This header field is not needed if a Supported header field was in
   the request; in this case, the proxy can already be sure that the
   session timer can be used for the session.

8.2 Processing of Responses

   When the final response to the request arrives, it is examined by the
   proxy.

   If the response does not contain a Session-Expires header, header field, but
   the proxy remembers that it requested a session timer in the request
   (by inserting, modifying, or examining and accepting the Session-Expires Session-
   Expires header field in the proxied INVITE), request), this means that the UAS
   did not support the session timer. If the proxy remembers that the
   UAC did not support session timer either, the proxy forwards the
   response upstream normally. There is no session expiration for this call leg.
   session. If, however, the proxy remembers that the UAC did support
   session timer, additional processing is needed.

   Because there is no Session-Expires or Require header field in the
   response, the proxy knows it is the first session-timer-aware proxy
   to receive the response. This proxy MUST insert a Session-Expires
   header field into the response with the value it remembered from the
   forwarded request. It MUST set the value of the "refresher" parameter
   to "uac". The proxy MUST also insert the Require header field into the
   response, with the value "timer", before forwarding it upstream.

   If the response received response contains a Session-Expires header, header field, no
   additional
   modification of the response processing is needed. The response is processed
   normally.

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

   In all cases, the
   session associated with each dialog.

   The proxy MUST NOT modify the value of the Session-
   Expires Session-Expires header
   field received in the response (assuming one was present) before
   forwarding it upstream.

8.3 Session Expiration

   When the current time equals or passes the session expiration for a
   call leg,
   session, the proxy MAY remove associated call state, and MAY free any
   resources associated with the call. Unlike the UA, it MUST NOT send a
   BYE.

9 UAS Behavior

   When a UAS receives an INVITE, a session refresh request, the processing of that INVITE
   request can logically be broken into two steps. In the first step,
   the UAS acts as a "virtual proxy", and follows the rules specified in
   Section 8.1 as if it were a proxy. This means that the same session
   timer manipulations that a proxy can do, can also be done by a UAS.
   Specifically, this means that it can insert or reduce the session
   timer
   interval (but not below Min-SE header field value, if present),
   reject the request with a 422, and insert/increase the Min-SE, Min-SE header
   field value, just as a proxy can. Of course, rather than proxying the
   request, the "modified" request is passed into the second step of
   processing, which we call the "virtual UAS" processing. Viewing the
   UAS as the concatenation of a proxy and a UAS-specific processing
   component simplifies the specification of behavior and guarantees
   consistency. This separation is for the purposes of defining
   behavior. It does not mandate that the implementation work this way.

   Once the request is received by the virtual UAS (assuming it is
   received; it may have been rejected with a 422 based on the rules in
   Section 8.1), virtual UAS processing begins. From this point forward,
   the term "UAS" refers to the "virtual UAS". If the virtual UAS wishes to
   accept the call, request, it copies the value of the Session-Timer
   from the request received Session-Expires header
   field from the first step request into the 2xx response. Of course, this request
   refers to the one received from the "virtual proxy".

   The virtual UAS MUST then set the value of the refresher parameter in the
   Session-Expires header present field in a 200 class the 2xx response. This value
   specifies who will perform refreshes for the call leg. dialog. The value is set
   based on the value of this parameter in the request request, and on whether
   the UAC supports the session timer. timer extension. The UAC supports the
   extension if the "timer" option tag was present in a Supported header
   field in the request. Table 3 2 defines how the value in the response MUST be
   is set. A value of 'none' in the 2nd column means that there was no
   refresher parameter in the request. A value of 'NA' in the third
   column means that this particular combination shouldn't happen, as its
   it's disallowed by the protocol.

   In the fourth row of Table 3, since the UAC supports the session
   timer, and so does the UAS, the UAS can elect for itself or the UAC
   to perform the refreshes.

   Note that the results of the above table are that the UACs choice of
   refresher cannot be changed by the virtual UAS.

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

   Table 3: 2: UAS Behavior

   The fourth row of Table 2 describes a case where both the UAC and UAS
   support the session timer extension, and the UAC did not select who
   will perform refreshes. This allows the UAS to decide whether it, or
   the UAC, will perform the refreshes. However, as the table indicates,
   the UAS cannot overried the UAC's choice of refresher, if it made
   one.

   If the refresher parameter in the Session-Expires header field in the 200
   class
   2xx response has a value of "uac", the UAS MUST place a Require
   header field into the response with the value "timer". This is
   because the uac is performing refreshes and the response has to be
   processed for the UAC to know this. If the refresher parameter in the 200 class
   2xx response has a value of "uas", and the Supported header field in
   the request contained the value "timer", the UAS SHOULD place a
   Require header field into the response with the value "timer". In
   this case, the UAC is not refreshing, but it is supposed to send a
   BYE if it never receives a refresh. Since the call will still succeed
   without the UAC doing this, insertion of the Require is a SHOULD
   here, rather than a MUST.

   The UAS remembers UAS, just like the UAC, stores state for the session timer. This
   state includes the session interval, the session expiration, and the
   identity of the refresher. This state is bound to the dialog used to
   set up the session. The session interval for a call leg as is set to the value of the
   delta-time from the Session-Expires header field in the most recent
   2xx response to INVITE a session refresh request on that call leg. dialog. It also
   remembers whether it, or its peer, is the refresher on the leg.

   If the UAS must refresh a leg, it computes the session expiration for
   that leg. The session expiration is based
   on the time of transmission value of the
   last 2xx INVITE refresher parameter from the most recent 2xx
   response to a session refresh request on that leg plus dialog. If the most
   recent 2xx response had no Session-Expires header field, there is no
   session interval for expiration, and no refreshes need to be performed.

   If the UAS must refresh the session, it computes the session
   expiration. The session expiration is the time of transmission of the
   last 2xx response to a session refresh request on that leg. dialog plus
   the session interval. If UA wishes to continue with the session
   beyond the session expiration, it MUST generate a refresh before the
   session expiration. It is RECOMMENDED that this refresh be sent once
   half the session interval has elapsed. Additional procedures for this
   refresh are described in Section 10.

10 Performing Refreshes

   The side generating a refresh does so according to the UAC procedures
   defined in Section 7. Note that only a 2xx response to the INVITE a session
   refresh request extends the session expiration. This means that a UA
   could attempt a refresh, and receive a 422 response with a Min-SE
   header field that contains a value much larger than the current
   session interval. The UA will still need to send an INVITE session refresh
   request before the session expiration (which has not changed), even
   though this INVITE request will contain a value of the Session-Expires that
   is much larger than the current session interval.

   If no 2xx response to a refreshing re-INVITE session refresh request is received before
   the session expiration, the UA SHOULD send a BYE request to terminate
   the
   call. session. It SHOULD send this BYE slightly before session
   expiration. The minimum of ten seconds and one third the session
   interval is RECOMMENDED.

        For example, if the session interval is 120 seconds, one
        third of this is 40 seconds. Since the minimum of 10
        seconds and 40 seconds is 10 seconds, the BYE would be sent
        10 seconds before the session expires.

   Similarly, if the side not performing refreshes does not receive a
   re-INVITE refreshing the
   session refresh request before the session expiration, they SHOULD
   send a BYE to terminate the call, session, slightly before the session
   expiration. The minimum of ten seconds and one third the session
   interval is RECOMMENDED.

        Firewalls and NATs NAT ALGs may be very unforgiving about
        allowing SIP traffic to pass after the expiration time of
        the session. It is for this reason that the BYE should be
        sent before the expiration.

11 Security Considerations

   The session timer introduces the capability of a proxy or UA element
   to force compliant clients UAs to send refreshes at a rate of the element's
   choosing. This introduces the possibility of denial-of-service
   attacks with significant amplification properties. These attacks can
   be launched from "outsiders" - elements which attempt to modify
   messages in transit, or by "insiders" - elements which are
   legitimately in the request path, but are intent on doing harm.
   Fortunately, both cases are adequately handled by this specification.

11.1 Inside Attacks

   This introduces the possibility of rogue proxies or UASes UAs introducing
   denial-of-service attacks. However, the mechanisms in this
   specification prevent that from happening.

   First, consider the case of a rogue UAC that wishes to force a UAS to
   generate refreshes at a rapid rate. To do so, it inserts a Session-
   Expires header field into an INVITE with a low duration and a
   refresher parameter equal to uas. Assume it places a Supported header
   field into the request. Any proxy, or the UAS, which objects to this
   low timer will reject the request with a 422, therefore preventing
   the attack. If no Supported header field was present, the proxies
   will insert a Min-SE header field 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 very small session interval. The UAC uses
   this timer, and quickly sends a refresh. Section 7.1 requires the UAC
   to copy the current session interval into the Session-Expires header
   field in the request. This enables the proxies to see the current
   value. The proxies will reject this request, and provide a Min-SE
   with a 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, header field, an attack would still
   be possible. The UAS could discard this header field in a 2xx
   response, and force the UAC to continue to generate rapid requests.

   In a similar fashion, a 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

11.2 Outside Attacks

   An element that IP or transport level security is used
   when communicating between proxies, can observe and that modify a request or response in
   transit can force rapid session refreshes. To prevent that, requests with Session-
   Expires headers only be accepted over these secure transports.

12 Examples

   The following examples are meant
   and responses need to illustrate the functionality
   associated with be protected by message integrity. Since the
   session timer. In the interest of brevity, all timer headers except Supported, Session-Expires, Min-SE are not end-to-end, and Require are
   intentionally left out of manipulated by
   proxies, the SIP messages.

12.1 Basic session timer

   In S/MIME capabilities are not suitable for this case, two UAs communicate directly, with no proxies. Both
   support the session timer. The call task.
   Rather, integrity needs to be protected using hop-by-hop mechanisms.
   As a result, it is setup RECOMMENDED that an element which sends a request
   with a one hour
   expiration. Half an hour later, the UAC refreshes the session.

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

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

   Calling UA -> Called UA
          INVITE
          Supported: timer
          Session-Expires: 3600;refresher=uac

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

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

   Calling UA <- Called UA
          BYE

   Calling UA -> Called UA
          200 OK

12.2 Basic negotiation of Session Time

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

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

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

   Calling UA -> proxy
           BYE

   proxy -> Called UA
          BYE

   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK

12.3 No Session-Expires Header in INVITE

   In this scenario, the UA sends an INVITE without a Session-Expires header and with field, or a Supported header containing field with
   the option tag "timer". value "timer", do so using IPSec or TLS. 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: 3600   Proxy added Session-Expires

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

   Calling UA <- proxy
          200 OK
          Session-Expires: 3600;refresher=uac   Proxy starts timer on send
          Require: timer                        Calling UA starts timer adequate
   protection is obtained only if TLS or IPSec is applied on receipt

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

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 each hop,
   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: 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 is RECOMMENDED that the
   called UA does support SIPS URI scheme be used in conjunction
   with this extension. This means that proxies which record-route and
   request session timer, so it includes SHOULD record-route with a SIPS URI. A UA
   which inserts a
   header{Supported} header in the request. The proxy adds the Session-Expires and Require headers header into the a request or 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
   SHOULD include a Contact URI thats a SIPS URI.

12 IANA Considerations

   This extension defines two new header fields, a new response code,
   and a new option tag. SIP [1] defines IANA procedures for registering
   these.

12.1 IANA Registration of Min-SE and Session-Expires Header Fields

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

   Calling UA -> proxy
          BYE

   proxy -> Called UA
          BYE

   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK

12.5 Session Timer without Called UA Support

   In this scenario, the calling UA indicates that it supports the
   session timer, but does not add the Session-Expires Min-SE header into field:

        RFC Number: RFC XXXX [Note to IANA: Fill in with the
   INVITE. RFC number
             of this specification.]

        Header Name: Min-SE

        Compact Form: none

   The proxy adds it, but session timer following is not supported by the
   UAS. The call is still set up with a session timer, as all that is
   required is registration for one of the user agents involved Session-Expires header
   field:

        RFC Number: RFC XXXX [Note to IANA: Fill in with the call leg to
   understand RFC number
             of this specification.]

        Header Name: Session-Expires

        Compact Form: x

12.2 IANA Registration of the "timer" feature.

   Calling UA -> proxy
          INVITE
          k: timer

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK 422 (Session Interval Too Small) Response
   Code

   The UAC then re-invites, which following is responded the registration for the 422 (Session Interval Too
   Small) response code:

        Response Code: 422
        Default Reason Phrase: Session Interval Too Small

        RFC Number: RFC XXXX [Note to IANA: Fill in with a 400 because the
   new media streams were rejected. Since RFC number
             of this is a re-INVITE, specification.]

12.3 IANA Registration of the
   session "timer" Option Tag

   The following is still active.

   Calling UA -> proxy
          INVITE
          k: timer
          Session-Expires: 3600;refresher=uac   UA asks the registration for the "timer" option tag:

        Name: timer this time

        Description: This option tag is not mandatory

   proxy -> Called UA
          INVITE                    proxy does not reduce Session-Expires header
          k: for support of the session timer
          Session-Expires: 3600;refresher=uac

   proxy <- Called UA
          400 Rejected Media        Called
             extension. Inclusion in a Supported header field in a
             request or response indicates that the UA doesn't is capable of
             performing refreshes according to that specification.
             Inclusion in a Require header in a request means that the
             UAS must understand the session timer

   Calling UA <- proxy
          400 Rejected Media

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

12.6 Neither UA Supports Session Timer

   In this case, neither UA supports extension to process
             the session timer. However, one of request. Inclusion in a Require header field in a
             response indicates that the proxies on UAC must look for 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 Session-
             Expires header compact form
          x: 3600

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

12.7 Both UAs Support, Change field in Roles the response, and process
             accordingly.

13 Example Call Flow

   Figure 1 gives an example of a call flow that makes use of the
   session timer. In this case, example, both user agents the UAC and UAS support the
   session timer. timer extension. The initial INVITE from caller to callee results in refreshes being request generated by the caller. A re-INVITE sent from
   UAC, Alice (message 1), might look like:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Supported: timer
   Session-Expires: 50
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)
   This request indicates that Alice supports the session timer, and is
   request session refreshes every 50 seconds. This arrives at the first
   proxy, P1. This session interval is below the callee changes that role so
   that minimum allowed value
   of 3600. So, P1 rejects the callee refreshes.

   Calling UA -> proxy
           INVITE
           Supported: timer
           Session-Expires: request with a 422 (message 2):

   SIP/2.0 422 Session Interval Too Small
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
     ;received=192.0.2.1
   Min-SE: 3600

   proxy -> Called UA
   To: Bob <sip:bob@biloxi.com>;tag=9a8kz
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE                Proxy wants timer, no change in

   This response contains an Min-SE header field with the value of 3600.
   Alice then retries the request. This time, the request contains a
   Min-SE header, since Alice has received a 422 for other INVITE
   requests with the same Call-ID. The new request (message 4) might
   look like:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
   Supported: timer
   Session-Expires: 3600

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

   Calling UA <- proxy                          Calling UA sees refresher=uac
           200 OK                               It is refreshing
           Session-Expires: 3600;refresher=uac
   Min-SE: 3600
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)

   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 P1 record-routes. Since the session interval is a UAC for this transaction) now sends a re-
   INVITE. For whatever reason, acceptable
   to it, it decides forwards the request to switch roles by explicitly
   designating P2 (message 5). However, the itself as
   session interval is below its minimum configured amount of 4000. So,
   it rejects the refresher.

   proxy <- Called UA request with a 422 response code (message 6), and
        Alice      Proxy P1     Proxy P2        Bob
          |(1) INVITE  |            |            |
          |SE: 50      |            |            |
          |----------->|            |            |
          |(2) 422     |            |            |
          |MSE: 3600   |            |            |
          |<-----------|            |            |
          |(3) ACK     |            |            |
          |----------->|            |            |
          |(4) INVITE  |            |            |
          |SE:3600     |            |            |
          |MSE:3600    |            |            |
          |----------->|            |            |
          |            |(5) INVITE  |            |
          |            |SE:3600     |            |
          |            |MSE:3600    |            |
          |            |----------->|            |
          |            |(6) 422     |            |
          |            |MSE:4000    |            |
          |            |<-----------|            |
          |            |(7) ACK     |            |
          |            |----------->|            |
          |(8) 422     |            |            |
          |MSE:4000    |            |            |
          |<-----------|            |            |
          |(9) ACK     |            |            |
          |----------->|            |            |
          |(10) INVITE
           Supported: timer
           Session-Expires: 3600;refresher=uac
   Calling UA <- proxy |            |            |
          |SE:4000     |            |            |
          |MSE:4000    |            |            |
          |----------->|            |            |
          |            |(11) INVITE                proxy wants timer, no change in value
           Supported: timer
           Session-Expires: 3600;refresher=uac

   Calling UA -> proxy |            |
          |            |SE:4000     |            |
          |            |MSE:4000    |            |
          |            |----------->|            |
          |            |            |(12) INVITE |
          |            |            |SE:4000     |
          |            |            |MSE:4000    |
          |            |            |----------->|
          |            |            |(13) 200 OK                               Calling UA supports timer
           Session-Expires: 3600;refresher=uac  Inserts Session-Expires
           Require: timer                       Calling UA updates timer on send

   proxy -> Called UA                           Called UA sees |
          |            |            |SE:4000     |
          |            |            |<-----------|
          |            |(14) 200 w/refresher=uac OK |            |
          |            |SE:4000     |            |
          |            |<-----------|            |
          |(15) 200 OK                               It is refreshing
           Session-Expires: 3600;refresher=uac  Proxy updates timer on send
           Require: timer                       Called UA updates timer on receipt

   proxy <- Called UA |            |            |
          |SE:4000     |            |            |
          |<-----------|            |            |
          |(16) ACK

   Calling UA <- proxy    |            |            |
          |----------->|            |            |
          |            |(17) ACK

12.8 Proxy Rejects    |            |
          |            |------------------------>|
          |(18) UPDATE |            |            |
          |SE:4000     |            |            |
          |----------->|            |            |
          |            |(19) UPDATE |            |
          |            |SE:4000     |            |
          |            |------------------------>|
          |            |(20) 200 OK |            |
          |            |SE:4000     |            |
          |            |<------------------------|
          |(21) 200 OK |            |            |
          |SE:4000     |            |            |
          |<-----------|            |            |
          |            |(22) BYE    |            |
          |            |<------------------------|
          |(23) BYE    |            |            |
          |<-----------|            |            |
          |            |(24) 408    |            |
          |            |------------------------>|

   Figure 1: Example Session Timer

   In this call flow, the calling UA sends an INVITE with Flow
   includes a Session-
   Expires Min-SE header that is low. This arrives at a proxy, which rejects it field with a 422 because it is too low. The proxy offers a larger minimum
   timer. The calling UA the value of 4000. Once more,
   Alice retries with a new Session-Expires and with a the INVITE. This time, the Min-SE header.

   Calling UA -> Proxy header field in her
   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 the maximum of all Min-SE she has received (3600 and 4000).
   Message 10 might look like:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
   Supported: timer
   Session-Expires: 300             UAC chooses larger SE 4000
   Min-SE: 4000
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)

   P1 record-routes once again, but P2 does not (this wouldn't normally
   happen; presumably, if it asked for session timer, it would record-
   route the subsequent request). The UAS receives the request. It
   copies the Session-Expires header from the request to the response,
   and adds a refresher parameter with value "uac". This 200                      Minimum OK is
   forwarded back to Alice. The response she receives (message 15) might
   look like:

   SIP/2.0 200

   Proxy -> Called UA
         INVITE OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
    ;received=192.0.2.1
   Require: timer
   Supported: timer
   Record-Route: sip:p1.atlanta.com;lr
   Session-Expires: 250             Proxy lowers 4000;refresher=uac
   To: Bob <sip:bob@biloxi.com>;tag=9as888nd
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sip:bob@192.0.2.4>
   Content-Type: application/sdp
   Content-Length: 142

   (Bob's SDP not shown)

   Alice generates an ACK (message 16), which is routed through P1 and
   then to 250
         Min-SE: 200

   Proxy <- Called UA
         200
         Require: Bob. Since Alice is the refresher, around 3000 seconds later,
   Alice sends an UPDATE request to refresh the session. Since this
   request is part of an established dialog, and Alice has not received
   any 422 responses or requests on that dialog, there is no Min-SE
   header field in her request (message 18):

   UPDATE sip:bob@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
   Route: sip:p1.atlanta.com;lr
   Supported: timer
   Session-Expires: 200;refresher=uac   UAS lowers 4000;refresher=uac
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.com>;tag=9as888nd
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314162 UPDATE
   Contact: <sip:alice@pc33.atlanta.com>

   This is forwarded through P1 to Bob. Bob generates a 200

   Calling UA <- Proxy OK, copying
   the Session-Expires header field into the response. This is forwarded
   through P1, and arrives at Alice. The response she receives (message
   21) might look like:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
     ;received=192.0.2.1
   Require: timer
   Session-Expires: 200;refresher=uac

   Calling 4000;refresher=uac
   To: Bob <sip:bob@biloxi.com>;tag=9as888nd
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314162 UPDATE
   Contact: <sip:bob@192.0.2.4>
   Shortly afterwards, Alice's UA -> Proxy
         ACK

   Proxy -> Called crashes. As a result, she never sends
   an session refresh request. 3990 seconds later, Bob gives up, and
   sends a BYE request (message 22). This is sent to P1. P1 attempts to
   deliver it, but fails (since Alice's UA
         ACK

13 has crashed). P1 then returns
   a 408 (Request Timeout) to Bob.

14 Acknowledgements

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

14

15 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

15 Bibliography

16 Normative References

   [1] M. Handley, J. Rosenberg, H. Schulzrinne, E. Schooler, and et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [2] J. Rosenberg, "SIP: "The session initiation protocol," Request protocol UPDATE method,"
   Internet Draft, Internet Engineering Task Force, May 2002.  Work in
   progress.

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

   [2] 1997.

   [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
   SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
   Work in progress.

17 Informative References

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

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119,

   [6] P. Srisuresh and M. Holdrege, "IP network address translator
   (NAT) terminology and considerations," RFC 2663, Internet Engineering
   Task Force,
   Mar. 1997.

   [4] Aug. 1999.

   [7] J. Rosenberg and H. Schulzrinne, "The SIP supported header," "Reliability of provisional
   responses in SIP," Internet Draft, Internet Engineering Task Force,
   Feb. 2001. 2002.  Work in progress.

   [8] A. Roach, "SIP-specific event notification," Internet Draft,
   Internet Engineering Task Force, Mar. 2002.  Work in progress.

   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

                           Table of Contents

   1          Introduction ........................................    1    3
   2          Terminology .........................................    2    4
   3          Protocol          Overview ...................................    3 of Operation ...............................    4
   4          Session-Expires Header Field Definition .............    5    6
   5          Min-SE Header Field Definition ......................    6    7
   6          422 Response Code Definition ........................    7    8
   7          UAC Behavior ........................................    7    8
   7.1        Generating an INVITE a Session Refresh Request ........................    7
   7.1.1      Example .............................................    9 ................    8
   7.2        Processing a 2xx Response ...........................   10
   7.3        Processing a 422 Response ...........................   11
   8          Proxy Behavior ......................................   11
   8.1        Processing of requests Requests ..............................   11
   8.2        Processing of Responses .............................   13
   8.3        Session Expiration ..................................   14
   9          UAS Behavior ........................................   14
   10         Performing Refreshes ................................   15   16
   11         Security Considerations .............................   16
   12         Examples ............................................
   11.1       Inside Attacks ......................................   17
   12.1       Basic session timer .................................
   11.2       Outside Attacks .....................................   17
   12         IANA Considerations .................................   18
   12.1       IANA Registration of Min-SE and Session-Expires
   Header Fields ..................................................   18
   12.2       Basic negotiation       IANA Registration of Session Time ................... the 422 (Session Interval Too
   Small) Response Code ...........................................   18
   12.3       No Session-Expires Header in INVITE .................       IANA Registration of the "timer" Option Tag .........   19
   12.4       Session timer without Calling UA Support ............   20
   12.5       Session Timer without Called UA Support .............   22
   12.6       Neither UA Supports Session Timer ...................   23
   12.7       Both UAs Support, Change in Roles ...................   24
   12.8       Proxy Rejects Timer .................................   25
   13         Example Call Flow ...................................   19
   14         Acknowledgements ....................................   26
   14   24
   15         Author's Addresses ..................................   26
   15         Bibliography ........................................   27   24
   16         Normative References ................................   24
   17         Informative References ..............................   25