[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 4028

Internet Engineering Task Force                                   SIP WG
Internet Draft                                     S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-08.txt                          dynamicsoft
October 6, 2001
Expires: April 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 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



S.Donovan,J.Rosenberg                                         [Page 1]


Internet Draft               Session Timer               October 6, 2001


   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 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", "REQUIRED",



S.Donovan,J.Rosenberg                                         [Page 2]


Internet Draft               Session Timer               October 6, 2001


   "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "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 requests in a call before it will be
             considered timed out. The session interval is conveyed in
             the Session-Expires header defined here. The UAS obtains
             this value from the Session-Expires header of a 2xx INVITE
             response that it sends. Proxies and UACs determine this
             value from the Session-Expires header in a 2xx INVITE
             response they receive.

        Minimum Timer: Because of the processing load of INVITE
             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 timed out, if no successful INVITE transaction
             occurs beforehand.

        Refresh: An INVITE request sent during an active call leg. If
             the request generates a 2xx response, the session
             expiration is increased to the current time plus the
             session interval from the response.

3 Protocol Overview

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

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




S.Donovan,J.Rosenberg                                         [Page 3]


Internet Draft               Session Timer               October 6, 2001


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

   The details of the protocol relate to negotiation of a reasonable
   value for the session interval, and negotiation of which side of the
   call leg 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. The goal of the protocol is to choose a session interval
   that is the smallest of all the values requested by all elements, 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 processing, and due to the idempotency of
   INVITE requests, is effectively redone each time the session is
   refreshed with another re-INVITE.

   To negotiate the value of the refresh interval, the Min-SE and
   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 the session timer, but not lower than the value of the
   Min-SE header. If a proxy or UAS receives a request with a Session-
   Expires lower than a configured minimum, it can reject the request
   with a 422 response. This response contains a Min-SE header with the
   minimum allowed value. The client retries the request, inserting a
   Min-SE header containing the maximum value of the Min-SE headers
   returned in previous 422 responses for the call. In the case where
   the client isn't aware of the session timer extension, a proxy that
   receives a request with a Session-Expires lower than the configured
   minimum places the Min-SE header in the proxied request, and
   increases the 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 that
   meets the design criteria described above. The 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 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, 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
   into the Session-Expires header in the 2xx response. When the UAS
   doesn't support it, the proxy closest to the UAS performs that job,



S.Donovan,J.Rosenberg                                         [Page 4]


Internet Draft               Session Timer               October 6, 2001


   and inserts the value of the timer into the 2xx response as it passes
   by.

4 Session-Expires Header Field Definition

   The Session-Expires general header conveys the session interval for a
   SIP call. It is placed only in INVITE requests, and is allowed in any
   200 class response to an INVITE. Unlike the SIP Expires header, it
   can only contain 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.
   However, 1800 seconds (30 minutes) is RECOMMENDED. In other words,
   SIP entites MUST be prepared to handle Session-Expires values of any
   duration, but entities that insert the Session-Expires header 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
   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, 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") ":" delta-seconds
                            [refresher]
        refresher        =  ";" "refresher" "=" "uas"|"uac"



S.Donovan,J.Rosenberg                                         [Page 5]


Internet Draft               Session Timer               October 6, 2001


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

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

   Table 1 is an extension of tables 4 and 5 in [1] for the Session-
   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.


5 Min-SE Header Field Definition

   The Min-SE general header indicates the minimum value for the session
   interval, in units of delta-seconds. When used in an INVITE 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 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.




S.Donovan,J.Rosenberg                                         [Page 6]


Internet Draft               Session Timer               October 6, 2001


   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 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.


6 422 Response Code Definition

   This extension introduces the 422 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 with
   a duration that is below the minimum timer for the server. The 422
   response MUST contain a Min-SE header with the minimum timer for that
   server.

7 UAC Behavior

7.1 Generating an INVITE Request

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

   The UAC MAY include a Require in the request with the value "timer"
   to indicate that the UAS must support the session timer to
   participate in the session. This does not mean that the UAC is
   requiring the UAS to perform the refreshes, just that it is requiring


S.Donovan,J.Rosenberg                                         [Page 7]


Internet Draft               Session Timer               October 6, 2001


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

   The UAC MUST insert the Min-SE header into a re-INVITE request for a
   particular call leg if it has ever received a 422 response to a
   previous INVITE on the 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 for a particular call if it has ever received
   a 422 response to a previous INVITE with the same Call-ID.

   The value of the Min-SE header present in the INVITE MUST be the
   largest value amongst all Min-SE values returned in all 422
   responses, or received in INVITE requests, on the same call leg, if a
   call leg has been established. If no leg is established, the Min-SE
   header is set to the largest value amongst all Min-SE values returned
   in all 422 responses for the same call. A result of this rule is that
   the maximum value of the Min-SE is effectively "cleared" once the
   call leg 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 a Session-Expires in an initial INVITE request if
   it wishes for a session timer to be applied. The value of this header
   indicates session interval desired by the UAC. In an INVITE that is
   within a call leg with an active session timer, the header SHOULD be
   present, and SHOULD contain the the larger of the current value of
   the session interval and the value of the Min-SE, if present.

   If the INVITE is a re-INVITE it is RECOMMENDED that the refresher be
   set to "uac" if the element sending the INVITE is currently
   performing refreshes, else "uas" if its peer is performing the
   refreshes. In an initial INVITE, the UAC MAY include the refresher
   parameter with value "uac" if it wishes to perform the refreshes. If
   the UAC wishes to leave this decision to the negotiation mechanisms
   described below, the refresher parameter is omitted.

   A re-INVITE generated to refresh the session is a normal re-INVITE.



S.Donovan,J.Rosenberg                                         [Page 8]


Internet Draft               Session Timer               October 6, 2001


   It SHOULD contain SDP that describes the session, even if that SDP
   has not changed. In that case, the session description MUST somehow
   indicate that it has not changed. In the case of SDP, this is
   accomplished by including the same value for the origin field as
   previous messages to its peer. The same is true for the 200 class
   response to a re-INVITE used solely for refreshing. The response MUST
   contain a session description with an indication that it has not
   changed. This is accomplished in the same way as for the request.

   It is possible for a UAS to believe that an INVITE is an initial
   INVITE, and for the UAC to believe it is a re-INVITE. This happens
   when a UA crashes and reboots between refreshes. When the refresh
   arrives at the rebooted UA, it decides to reject the call (generally,
   it will reject the call unless it explicitly is capable of recovering
   lost calls). If From tags are used, the UAS can detect that the re-
   INVITE is for an existing call by the existence of the tag in the To
   field of the re-INVITE. Therefore, a UAC MUST insert a From tag in an
   initial INVITE if it supports session timer. A UAS that wishes to
   reject a re-INVITE for a call that it believes is already terminated
   SHOULD respond with a 481. A UAC receiving a 481 to a session timer
   refresh MUST generate a BYE to terminate that call leg.


        If From tags were not mandatory, A could INVITE B without a
        From tag. B inserts a tag in the 200 OK. Now, B sends a
        re-INVITE to A. Meantime, A has crashed and rebooted. This
        re-INVITE has a From tag, but no To tag. It therefore
        cannot be distinguished for a new INVITE in which the UAC
        inserts a From tag. This ambiguity is resolved by mandating
        use of From tag with session timer.


        The requirement for From tags and responding with a 481 to
        stale re-INVITEs has been added to the updated version of
        RFC2543. However, to eliminate a dependency between this
        spec and the new version of SIP, these two features are
        specified here as well.

7.1.1 Example

   As an example, a UAC sends an INVITE with Call-ID 1, and receives a
   422 with a Min-SE header of 100. There is a tag in the To field, with
   a value of 8. The UAC retries the request. It contains a Min-SE
   header. Since no call leg has been established, the Min-SE header
   contains the largest value amongst all Min-SE values returned in 422
   responses to INVITEs with the same Call-ID, in this case, with the
   Call-ID of 1. There has only been one such 422, and it had a Min-SE
   header with value 100. So, the retried INVITE contains a Min-SE



S.Donovan,J.Rosenberg                                         [Page 9]


Internet Draft               Session Timer               October 6, 2001


   header with value 100, and no tag in the To field, as there is no
   call leg established yet.

   This INVITE generates another 422, this time with a Min-SE header
   with a value of 200 and a tag in the To field with value 9. Once
   again, the UAC retries the request. This time, the INVITE has 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, the 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 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 UA receives a re-INVITE from its peer, containing a
   Min-SE header with the value 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 arrives, it may or may 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 there was a Require header in the response with the value "timer",
   the Session-Expires header will always be present. UACs MUST be
   prepared to receive a Session-Expires header in a response even if
   none were present in the request. The "refresher" parameter will be
   present, indicating who will be performing the refreshes. If the
   parameter contains the value "uac", the UAC will perform them. It is
   possible that the UAC requested session timer (and thus included a
   Session-Expires in the request), but there was no Require or
   Session-Expires in the 200 class response. This will happen when 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



S.Donovan,J.Rosenberg                                        [Page 10]


Internet Draft               Session Timer               October 6, 2001


   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 To field.
   It also remembers whether it, or its peer, is the refresher on the
   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 last
   2xx INVITE response on that leg plus the session interval for that
   leg. 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 request is a 422 Session Timer Too Small
   response message, then the UAC 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 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

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

   To request a session timer for a call (either in progress or
   initial), a proxy makes sure that a Session-Expires header is present
   in an INVITE that it proxies for that 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 the Min-SE header in the request, if
   present. The proxy MUST NOT insert a refresher parameter with value



S.Donovan,J.Rosenberg                                        [Page 11]


Internet Draft               Session Timer               October 6, 2001


   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.

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

   If the request contains a Supported header with a value "timer", the
   proxy MAY reject the INVITE request if the session interval in the
   Session-Expires header is smaller than the minimum timer defined in
   the proxies local policy. The proxy does so by sending a 422 Session
   Timer Too Small response message. When sending the 422 response
   message, the proxy MUST include a 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 proxy 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 Supported header with the value "timer".

   If the request did not contain a Supported header with the value
   "timer", the proxy MAY insert a Require header into the request, with



S.Donovan,J.Rosenberg                                        [Page 12]


Internet Draft               Session Timer               October 6, 2001


   the value "timer". However, this is NOT RECOMMENDED. This allows the
   proxy to insist on session timer for the session. This header is not
   needed if a Supported header was in the request; in this case, the
   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, but the
   proxy remembers that it requested a session timer in the request (by
   inserting, modifying, or examining and accepting the Session-Expires
   in the proxied INVITE), 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. If,
   however, the proxy remembers that the UAC did support session timer,
   additional processing is needed.

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

   If the response received contains a Session-Expires header, no
   additional response processing is 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 when the 2xx response is
   forwarded upstream, plus the session interval. This session
   expiration MUST update any existing session expiration for the call
   leg. The refresher param in the Session-Expires header in the 2xx
   response forwarded upstream will be present, and it indicates which
   UA is performing the refreshes. There can be multiple 200 class
   responses to a single INVITE, each representing a different call leg,
   resulting in multiple session expirations, one for each call leg.

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



S.Donovan,J.Rosenberg                                        [Page 13]


Internet Draft               Session Timer               October 6, 2001


8.3 Session Expiration

   When the current time equals or passes the session expiration for a
   call leg, 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, the processing of that INVITE 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 (but not below Min-SE if present), reject the request with a
   422, and insert/increase the Min-SE, 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. If the virtual UAS
   wishes to accept the call, it copies the value of the Session-Timer
   from the request received from the first step into the 2xx response.

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


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

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



S.Donovan,J.Rosenberg                                        [Page 14]


Internet Draft               Session Timer               October 6, 2001



         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 refresher parameter in the Session-Expires header in the 200
   class response has a value of "uac", the UAS MUST place a Require
   header into the response with the value "timer". 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
   response has a value of "uas", and the Supported header in the
   request contained the value "timer", the UAS SHOULD place a Require
   header into the response with the value "timer". In this case, the
   UAC is not refreshing, but it is supposed to send a BYE if it never
   receives a refresh. Since the call will still succeed without the UAC
   doing this, insertion of the Require is a SHOULD here, rather than a
   MUST.

   The UAS remembers the session interval for a call leg as the value of
   the delta-time from the Session-Expires header in the most recent 2xx
   response to INVITE on that call leg. 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 the time of transmission of the
   last 2xx INVITE response on that leg plus the session interval for
   that leg. 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
   extends the session expiration. This means that a UA could attempt a
   refresh, and receive a 422 with a Min-SE that contains a value much
   larger than the current session interval. The UA will still need to
   send an INVITE before the session expiration (which has not changed),



S.Donovan,J.Rosenberg                                        [Page 15]


Internet Draft               Session Timer               October 6, 2001


   even though this INVITE will contain a value of the Session-Expires
   that is much larger than the current session interval.

   If no response to a refreshing re-INVITE is received before the
   session expiration, the UA SHOULD send a BYE request to terminate the
   call. 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 before the session expiration, they
   SHOULD send a BYE to terminate the call, slightly before the session
   expiration. The minimum of ten seconds and one third the session
   interval is RECOMMENDED.


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

11 Security Considerations

   The session timer introduces the capability of a proxy or UA element
   to force compliant clients to send refreshes at a rate of the
   element's choosing. This introduces the possibility of rogue proxies
   or UASes 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 into an INVITE with a low duration and a refresher
   parameter equal to uas. Assume it places a Supported header 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 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



S.Donovan,J.Rosenberg                                        [Page 16]


Internet Draft               Session Timer               October 6, 2001


   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
   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, an attack would still be possible. The
   UAS could discard this header 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 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.

12 Examples

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

12.1 Basic session timer

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



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

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




S.Donovan,J.Rosenberg                                        [Page 17]


Internet Draft               Session Timer               October 6, 2001


   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



S.Donovan,J.Rosenberg                                        [Page 18]


Internet Draft               Session Timer               October 6, 2001


   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 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: 3600   Proxy added Session-Expires

   proxy <- Called UA
          200 OK



S.Donovan,J.Rosenberg                                        [Page 19]


Internet Draft               Session Timer               October 6, 2001


          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 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 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 that the



S.Donovan,J.Rosenberg                                        [Page 20]


Internet Draft               Session Timer               October 6, 2001


   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







S.Donovan,J.Rosenberg                                        [Page 21]


Internet Draft               Session Timer               October 6, 2001


12.5 Session Timer without Called UA Support

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



   Calling UA -> proxy
          INVITE
          k: timer

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK




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



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



S.Donovan,J.Rosenberg                                        [Page 22]


Internet Draft               Session Timer               October 6, 2001


                                                This is not mandatory

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

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

   Calling UA <- proxy
          400 Rejected Media

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK




12.6 Neither UA Supports Session Timer

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



   Calling UA -> proxy
          INVITE

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK



S.Donovan,J.Rosenberg                                        [Page 23]


Internet Draft               Session Timer               October 6, 2001


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: 3600

   proxy -> Called UA
           INVITE                Proxy wants timer, no change in value
           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  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: 3600;refresher=uac




S.Donovan,J.Rosenberg                                        [Page 24]


Internet Draft               Session Timer               October 6, 2001


   Calling UA <- proxy
           INVITE                proxy wants timer, no change in value
           Supported: timer
           Session-Expires: 3600;refresher=uac

   Calling UA -> proxy
           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 200 w/refresher=uac
           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
          ACK

   Calling UA <- proxy
          ACK



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



S.Donovan,J.Rosenberg                                        [Page 25]


Internet Draft               Session Timer               October 6, 2001


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

   Calling UA <- Proxy
         200
         Require: timer
         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 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



S.Donovan,J.Rosenberg                                        [Page 26]


Internet Draft               Session Timer               October 6, 2001


   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com




15 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.





                           Table of Contents



   1          Introduction ........................................    1
   2          Terminology .........................................    2
   3          Protocol Overview ...................................    3
   4          Session-Expires Header Field Definition .............    5
   5          Min-SE Header Field Definition ......................    6
   6          422 Response Code Definition ........................    7
   7          UAC Behavior ........................................    7
   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 ......................................   11
   8.1        Processing of requests ..............................   11
   8.2        Processing of Responses .............................   13
   8.3        Session Expiration ..................................   14
   9          UAS Behavior ........................................   14



S.Donovan,J.Rosenberg                                        [Page 27]


Internet Draft               Session Timer               October 6, 2001


   10         Performing Refreshes ................................   15
   11         Security Considerations .............................   16
   12         Examples ............................................   17
   12.1       Basic session timer .................................   17
   12.2       Basic negotiation of Session Time ...................   18
   12.3       No Session-Expires Header in INVITE .................   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         Acknowledgements ....................................   26
   14         Author's Addresses ..................................   26
   15         Bibliography ........................................   27





































S.Donovan,J.Rosenberg                                        [Page 28]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/