[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-05.txt                          dynamicsoft
July 20, 2001
Expires: February 2002


                         The SIP Session Timer

STATUS OF THIS MEMO

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

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

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

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

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


Abstract

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


1 Introduction

   The Session Initiation Protocol (SIP) [1], does not currently define
   a keepalive mechanism. The result is that call stateful proxies will
   not always be able to determine whether a call is still active or
   not. For instance, when a user agent fails to send a BYE message at



S.Donovan,J.Rosenberg                                         [Page 1]


Internet Draft               Session Timer                 July 20, 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, are defined. Session-
   Expires conveys the duration of the session, and Min-SE conveys the
   minimum allowed value for the session expiration.

2 Protocol Overview

   UACs which support the session timer extension defined here MUST
   include a Supported header in all requests, excepting ACK, containing
   the option tag "timer" [3]. When a UAC makes a call, it MAY include a



S.Donovan,J.Rosenberg                                         [Page 2]


Internet Draft               Session Timer                 July 20, 2001


   Session-Expires header in the INVITE request. The presence of the
   Session-Expires header indicates that the UAC wishes to use the
   session timer for this call. Its value indicates the desired
   expiration time of the session. The UAC MAY include the "refresher"
   parameter in the Session-Expires header with the value "uac". This
   indicates that the caller will perform refreshes for the session.

   Proxies on the signaling path may have their own requirements for the
   refresh interval of the session. If no Session-Expires was present,
   the proxy MAY insert one if it so desires. If one was present, the
   proxy can lower its value, but not to a value lower than the value in
   the Min-SE header in the request, if present. The proxy MUST NOT
   increase the value of the Session-Expires header. The proxy remembers
   the value of Session-Expires that was finally used in the request.
   The proxy also notes whether the UAC supports session timer, based on
   whether the Supported header was present with the tag "timer". In all
   cases, the proxy MUST NOT insert or modify the value of the
   "refresher" parameter in the Session-Expires header.

   If the proxy wishes to insist that the call is only established if
   the UAS supports session timer, it MAY insert a Require header into
   the request, with the value "timer", although this is NOT
   RECOMMENDED, since it eliminates the possibility of call
   establishment if the UAS does not support session timers.

   Eventually, the initial INVITE reaches the UAS. There are two cases -
   the UAS supports session timer, or it does not. If it does, and the
   response is otherwise acceptable to the UAS, the UAS MUST copy the
   Session-Expires into the 200 class response, or MAY add one into the
   response if none was present in the request. They UAS MAY reduce the
   session timer in the 200 class response, but not lower than the value
   in the Min-SE header, if present. The UAS also sets the value of the
   refresher parameter, based on rules in Section 7, which determines
   who will be generating the re-INVITEs for the refreshing. If the UAC
   is doing refreshes, the UAS additionally inserts a Require header
   into the 200 class response, with the tag "timer". This informs the
   UAC that special processing is needed for this response.

   If the UAS does not support session timer, it behaves as a normal
   UAS. Because of this, any 200 class response it generates will not
   contain the Session-Expires or Require header with the tag "timer".

   The 200 class response travels backwards through the proxies. When it
   reaches a proxy which remembers that it asked for session timer, the
   proxy examines the response. If the response did not contain a
   Session-Expires header (meaning the UAS does not support session
   timer), additional proxy processing is needed. If the proxy remembers
   that the UAC supported session timer, the proxy must return the value



S.Donovan,J.Rosenberg                                         [Page 3]


Internet Draft               Session Timer                 July 20, 2001


   of the session timer to the UAC. So, it inserts the Session-Expires
   header into the response (using the value it remembered inserting),
   sets the "refresher" parameter to "uac", and adds a Require header
   with a value of "timer". If the proxy remembers that the UAC did not
   support session timer, the proxy knows that session timer cannot be
   used, since neither UAS nor UAC support it.

   If the response received by the proxy does contain the Session-
   Expires header, the "refresher" parameter will indicate which side is
   performing refreshes.

   The response then arrives at the UAC. If it contains a Require header
   with the value "timer", the UAC knows that special processing of the
   response is needed. The response will also contain a Session-Expires
   header, and the value of that header is used as the interval for
   refreshes. The refresher parameter indicates who will be performing
   the refreshes. If it contains the value "uac", the UAC knows it is
   performing them. If it contains the value "uas", it knows that the
   UAS is performing them.

   The UAC then ACKs the INVITE. The Session-Expires MUST NOT be
   included in the ACK.

   Whichever side is supposed to perform the refreshes MUST send a re-
   INVITE before the expiration time. This re-INVITE SHOULD contain a
   Session-Expires header. The processing of this re-INVITE by proxies
   and UAS is identical to that of the initial INVITE.

   If the side not performing refreshes does not receive a re-INVITE
   refreshing the session before the session expires, they SHOULD send a
   BYE to terminate the call. If a refreshing UA does not receive a
   response to the re-INVITE used to refresh the session, it SHOULD send
   a BYE to terminate the call. Similarly, if a proxy doesn't receive a
   re-INVITE before expiration of the session, it MAY remove associated
   call state, and MAY free any resources associated with the call.
   Unlike the UA, it MUST NOT send a BYE.

3 Session-Expires Header Field Definition

   The Session-Expires header conveys the expiration time for a SIP
   session described in the body of the message. It is placed only in
   INVITE requests, and is allowed in any 200 class response to an
   INVITE. Like the SIP Expires header, it can contain either an
   absolute time or a delta-time. If it contains an absolute time, this
   time indicates the time at which a proxy or UA may safely destroy any
   state associated with the call. If it contains a delta time, the
   expiration time of the session is defined as that delta plus the time
   at which the header is observed in a final response. For example, if



S.Donovan,J.Rosenberg                                         [Page 4]


Internet Draft               Session Timer                 July 20, 2001


   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
   expiration time of the session as one hour after the time when the
   200 OK was sent. For each proxy, the expiration time is one hour
   after the time when the 2xx was received or sent (assuming these two
   are sufficiently close together). For the UAC, the expiration time is
   one hour after the receipt of the final response.

   Any entity that inserts a Session-Expires header with an absolute
   time MUST also insert a Date header into the message. This ensures
   proper operation for devices that do not have access to absolute
   time.

   There is no absolute minimum session refresh interval. However, 30
   minutes is RECOMMENDED. In other words, SIP entites MUST be prepared
   to handle session refresh intervals of any duration, but entities
   that insert the Session-Expires header SHOULD NOT choose times that
   result in intervals less than 30 minutes.

   Small session timer values can be destructive to the network. They
   cause excessive messaging traffic that affects both user agents and
   proxy servers. They increase the possibility of re-INVITE collisions
   (when both parties re-INVITE each other at the same time). Since the
   primary purpose of session timer is to provide a means to time out
   state in SIP elements, very small values won't generally be needed.
   30 minutes was chosen since 95% of phone calls are less than this
   duration. However, the 30 minute minimum is listed as a SHOULD, and
   not a MUST, since the exact value for this number is dependent on
   many network factors, including network bandwidths and latencies,
   computing power, memory availability, network topology, and of
   course, the application scenario. After all, SIP can set up any kind
   of session, nut just a phone call. At the time of publication of this
   document, 30 minutes seems appropriate. Advances in technologies may
   result in the number being excessively large five years in the
   future.

   The syntax of the Session-Expires header is:



        Session-Expires  =  ("Session-Expires" | "x") ":" ( SIP-date |
                            delta-seconds ) [refresher]
        refresher        =  ";" "refresher" "=" "uas"|"uac"



        OPEN ISSUE: Is there really any reason for absolute times?
        It just complicates things, since all operations really



S.Donovan,J.Rosenberg                                         [Page 5]


Internet Draft               Session Timer                 July 20, 2001


        need to be done using the delta-seconds. Plus, it will
        require a Date header, so that a proxy will have to
        subtract the two to arrive at a delta-time anyway.
        RECOMMENDATION: Remove absolute time.

   The optional refresher parameter indicates who will be doing the
   refreshing. It is RECOMMENDED that this parameter not be present in
   an initial INVITE, so that the negotiation mechanisms can
   successfully determine who will perform them. A response with the
   Session-Expires header MUST contain this parameter, indicating who
   will perform the refreshes. If the UAC wishes to insist on performing
   the refreshes, it MAY insert the parameter with a value of "uac" in
   the initial INVITE. It MUST NOT use a value of "uas" in the initial
   INVITE, since it doesn't know whether the UAS is capable of
   refreshes. However, in a re-INVITE, it MAY use a value of "uas" if it
   knows that the other side supports session timer.

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

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


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


   Table 1: Summary of header fields. "o": optional "-": not applicable,
   "R':  request header, "r": response header, "g": general header, "*":
   needed if message body is not empty. A numeric value  in  the  "type"
   column indicates the status code the header field is used with.


4 Min-SE Header Field Definition

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

   The syntax of the Min-SE header is:



S.Donovan,J.Rosenberg                                         [Page 6]


Internet Draft               Session Timer                 July 20, 2001


        Min-SE  =  "Min-SE" ":" delta-seconds


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

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


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


   Table 2: Summary of header fields. "o": optional "-": not applicable,
   "R':  request header, "r": response header, "g": general header, "*":
   needed if message body is not empty. A numeric value  in  the  "type"
   column indicates the status code the header field is used with.


5 UAC Behavior

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

   If the UAC wishes to request keepalives for this call, it MUST
   include a Session-Expires in the INVITE request used to initiate the
   call. The value of this header indicates the time when the UAC will
   consider the call expired if no refresh is sent. If the request is
   being authenticated, the Session-Expires header MUST appear before
   the Authorization or Proxy-Authorization headers. The UAC MAY include
   the refresher parameter with value "uac" if it wishes to perform the
   refreshes.

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



S.Donovan,J.Rosenberg                                         [Page 7]


Internet Draft               Session Timer                 July 20, 2001


   When a 2xx response to the initial 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 only the UAC
   supports session timer. In this case, the UAC needs to perform
   keepalives. To do this, the UAC follows the procedures defined in
   this specification as if the Session-Expires header were in the 200
   class response, and its value was the same as the one in the request
   (but with a refresher parameter of "uac").

   If the UAC must refresh, it computes the expiration time of the
   session. This is based on the value of the Session-Expires in the
   response. If the Session-Expires contains an absolute time, that is
   the time of expiration. If it contains a delta-time, the expiration
   time is the time of reception of the response plus that delta time.
   Let the difference in time between the reception of the response and
   the session expiration time be called the refresh interval. Note that
   this expiration applies only to the call leg associated with the
   response. It is explicitly allowed for there to be differing session
   timers (or none at all) on differing call legs, in the case where
   there are multiple 2xx OK responses to an initial INVITE with
   different tags in the To field.

   If UA wishes to continue with the session beyond the expiration, it
   MUST generate a refresh before the expiration time. It is RECOMMENDED
   that this refresh be sent once half the refresh interval has elapsed.
   The procedures for performing this refresh are described in Section
   8.

   If the response to the initial INVITE request is a 422 Session Timer
   Too Small response message then the UAC MAY retry the INVITE with a
   longer session timer value in the Session-Expires header.  The UAC
   MUST use a value that is bigger than any value returned in a
   Session-Expires header in any 422 response within the call leg. This
   requires the UA to store the largest session timer duration returned
   in any 422 for the duration of the call leg. This behavior is needed
   to prevent certain denial of service attacks, described in Section 9.




S.Donovan,J.Rosenberg                                         [Page 8]


Internet Draft               Session Timer                 July 20, 2001


6 Proxy Behavior

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


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

6.1 Processing of requests

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

   If the request already had a Session-Expires header, the proxy MAY
   reduce the value in the Session-Expires header, but MUST NOT set it
   to a duration lower than the value in the Min-SE header in the
   request, if present. The proxy MUST NOT increase the value of the
   duration.

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

   Assuming the proxy wishes to use session timer (and thus has possibly
   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 it placed in 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 9]


Internet Draft               Session Timer                 July 20, 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.

6.2 Processing of Responses

   When the final response to the request arrives, it is examined by the
   proxy. There are four cases.

        CASE I: UAC supports, UAS doesn't. In this case, the request
             forwarded by the proxy contained a Session-Expires header
             (possibly inserted by the proxy). Recall that all proxies
             interested in session timer MUST remember the value of the
             timer in the forwarded request, in addition to whether the
             UAC supports it. Handling of the response for this scenario
             depends on whether the session timer aware proxy is the one
             closest to the UAS, amongst all proxies which requested
             session timer.

             When the UAS sends the response, it will not contain a
             Session-Expires or Require header. This response is
             forwarded upstream, and it will eventually arrive at a
             proxy which was interested in session timers. Because there
             is no Session-Expires or Require in the response, the proxy
             knows it is the first session-timer-aware proxy to receive
             the response. This proxy MUST insert a Session-Expires
             header into the response with the value it remembered from
             the forwarded request. It MUST set the value of the
             "refresher" parameter to "uac". The proxy MUST also insert
             the Require header into the response, with the value
             "timer", before forwarding it upstream. The value of the
             Session-Expires in the forwarded response represents the
             expiration time of the session. For other proxies, the
             response will already contain the Session-Expires and
             Require header, so that this case is indistinguishable from
             CASE IV.

        CASE II: UAC doesn't support, UAS doesn't support. In this case,
             the final response has no Session-Expires header, and the
             proxy remembers that the UAC did not support the session
             timer. The proxy forwards the response upstream normally.
             There are no session timers for this call leg.

        CASE III: UAS supports, UAC doesn't. In this case, the final
             response contains a Session-Expires header with the
             refresher parameter set to "uas". The proxy forwards the



S.Donovan,J.Rosenberg                                        [Page 10]


Internet Draft               Session Timer                 July 20, 2001


             response upstream.

        CASE IV: UAC supports, UAS supports. In this case, the final
             response contains a Session-Expires header. The refresher
             parameter indicates who is performing the refreshes. This
             case will also occur when the UAC supports session timer,
             and the UAS doesn't, but a downstream proxy had recognized
             this as CASE I and inserted the Session-Expires and Require
             headers into the response. The proxy forwards the response
             upstream.

   In all cases, if the final response forwarded upstream by the proxy
   contains a Session-Expires header, its value represents the
   expiration time of the session for the call leg associated with that
   response. There can be multiple 200 class responses to a single
   INVITE, each representing a different call leg, resulting in multiple
   session timers, 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.

   The expiration of the call leg will occur at the time indicated in
   the Session-Expires header. If the Session-Expires header contains a
   delta-time, the expiration time is the time of receipt of the final
   response, plus that delta time.

   Re-INVITE requests may arrive from either UA, refreshing the session
   and extending the expiration time. Processing of these re-INVITEs by
   a proxy is identical to the procedure for processing the initial
   INVITE.

   If the session expires without having seen a response to a re-INVITE,
   the proxy MAY consider the call leg terminated. This means it MAY
   flush any state associated with that call leg.

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

7 UAS Behavior

   When a UAS receives an INVITE for a new call, and that INVITE
   contains a Session-Expires header, the UAS MUST place a Session-
   Expires header in a 200 class response (assuming the UAS accepts the
   call). The UAS MAY reduce the expiration time when it places this
   header into the response, but MUST NOT set it to a duration lower
   than the value in the Min-SE header in the request, if present. The
   UAS MUST NOT increase the value of the duration.



S.Donovan,J.Rosenberg                                        [Page 11]


Internet Draft               Session Timer                 July 20, 2001


   The UAS MAY reject the INVITE request if the requested session timer
   value in the Session-Expires header is smaller than the minimum value
   defined in UAS local policy. The UAS does so by sending a 422 Session
   Timer Too Small response message. When sending the 422 response
   message, the UAS MUST include a Session-Expires header with a value
   that is acceptable to it.

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

   The UAS MUST set 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 is set. A value of 'none' in the 2nd column means
   that there was no refresher parameter in the request. A value of 'NA'
   in the third column means that this particular combination shouldn't
   happen, as its disallowed by the protocol.


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


   Table 3: UAS Behavior


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

   If the refresher parameter in the Session-Expires header in the 200
   class response has a value of "uac", the UAS MUST place a Require
   header into the response with the value "timer".

   If the UAS is generating refreshes, it computes the expiration time
   of the session based on the value of the Session-Expires header in
   the response it sent. If the Session-Expires contains an absolute



S.Donovan,J.Rosenberg                                        [Page 12]


Internet Draft               Session Timer                 July 20, 2001


   time, that is the time of expiration. If it contains a delta-time,
   the expiration time is the time of transmission of the response plus
   that delta time. Let the difference in time between the transmission
   of the response and the session expiration time be called the refresh
   interval. Note that this expiration applies only to the call leg
   associated with the response.

   If the UA wishes to continue with the session beyond the expiration,
   it MUST generate a refresh before the expiration time. It is
   RECOMMENDED that this refresh be sent once half the refresh interval
   has elapsed. The procedures for performing this refresh are described
   in Section 8.

8 Performing Refreshes

   The refresh is accomplished by sending a re-INVITE request on the
   given call leg. Sending of the refresh (in terms of this extension),
   and processing the response are exactly identical to the rules in
   Sections 5 and 7. However, as discussed in Section 4, if the UAC
   received any 422 responses for this call leg, the re-INVITE MUST
   contain a Min-SE header with the largest of all durations returned in
   all 422 responses on that call leg. The re-INVITE SHOULD contain a
   Session-Expires header, with an duration equal to the last duration.
   For example, if the initial INVITE sequence results in a session
   timer of 200 seconds, the re-INVITE SHOULD contain a session timer
   with a value of 200 seconds. The re-INVITE MAY contain a different
   expiration, but this should only be done if the UA wishes to change
   the session expiration.

   If the Session-Timer is placed in the re-INVITE, the refresher
   parameter SHOULD be present, and SHOULD identify the element
   currently responsible for refreshes. This means that a re-INVITE may
   have a refresher parameter with value "uas", if the element not
   performing refreshes sends a re-INVITE for some other, non-session-
   timer reason. The refresher parameter MAY be set to identify the
   element not performing refreshes at this time. This will result in a
   change of roles.

   If the 200 OK to the re-INVITE has no Session-Expires, no expiration
   time exists for the session. This can happen if the proxies and/or
   UAS change their mind about session timers, and decide they no longer
   wish to use them. Since each INVITE is treated independently, the
   proxies or UAS do not need to continue requesting session timer even
   though they did so the first time.

   A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that
   is, this re-INVITE MAY contain an updated session description. In the
   case where the re-INVITE contains an updated session description, the



S.Donovan,J.Rosenberg                                        [Page 13]


Internet Draft               Session Timer                 July 20, 2001


   session description MUST somehow indicate that it has changed. In the
   case of SDP [4], this is accomplished by using a different value for
   the origin field.

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

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


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


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

   It is possible that the calling UA is generating refreshes, and then
   it receives a re-INVITE. After following the rules for UAS described
   above, the calling UA now determines it is not supposed to generate
   refreshes. The UA SHOULD cease generating refreshes in this case, and
   let the other UA perform them. This also implies that the
   responsibility for generating refreshes may change during a call.
   This happens commonly in one specific case - both caller and callee
   support session timer. The caller will be doing re-INVITEs initially.
   If the callee re-INVITEs, it becomes the UAC for this transaction,
   and the rules defined in this specification may result in a change in
   refresh responsibility to the called party. In general, when both
   parties support session timer, refreshes become the responsibility of
   the party which performed the last INVITE transaction.

   It is possible for a UAS to believe that an INVITE is an initial
   INVITE, and for the UAC to believe it is a re-INVITE. This happens



S.Donovan,J.Rosenberg                                        [Page 14]


Internet Draft               Session Timer                 July 20, 2001


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


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


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

9 Security Considerations

   The session timer introduces the capability of a proxy to effectively
   force clients to send refreshes at a rate of the proxies choosing. It
   can also force the clients to send a BYE by setting the expirations
   to times that are too short. This introduces the possibility of rogue
   proxies or UASes introducing denial-of-service attacks. Use of short
   refresh intervals allows the proxies or UAS to create network load.
   This is preventable using the 422 response and Min-SE header
   mechanism. Any proxy or the UAS can reject an INVITE with a low
   session timer, and the UAC will then include this minimum in the
   Min-SE header in subsequent requests. No compliant proxy will then
   use a session timer with a lower value. Rogue proxies could strip the
   Min-SE, but in this case, UA configuration should ideall prevent the
   attacks by refusing to use a session timer lower than a specific
   value (30 minutes is recommended here).

   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.




S.Donovan,J.Rosenberg                                        [Page 15]


Internet Draft               Session Timer                 July 20, 2001


10 Examples

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

10.1 Basic session timer

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



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

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

   60 seconds later:

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

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

   110 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



S.Donovan,J.Rosenberg                                        [Page 16]


Internet Draft               Session Timer                 July 20, 2001


   Calling UA -> Called UA
          200 OK




10.2 Basic negotiation of Session Time

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



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

   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




S.Donovan,J.Rosenberg                                        [Page 17]


Internet Draft               Session Timer                 July 20, 2001


   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK



10.3 No Session-Expires Header in INVITE

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



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

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

   proxy <- Called UA
          200 OK
          Session-Expires: 120;refresher=uac   Called UA starts timer on send
          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



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



S.Donovan,J.Rosenberg                                        [Page 18]


Internet Draft               Session Timer                 July 20, 2001


   tag "timer". Since the proxy wants session timer for the call it adds
   Session-Expires header before proxying the INVITE to the called UA.



   Calling UA -> proxy
           INVITE

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK

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

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

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

   Calling UA -> proxy
          200 OK

   proxy -> Called UA
          200 OK



S.Donovan,J.Rosenberg                                        [Page 19]


Internet Draft               Session Timer                 July 20, 2001


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


   proxy <- Called UA
          ACK

   Calling UA <- proxy
          ACK

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

   Calling UA -> proxy
          BYE

   proxy -> Called UA
          BYE

   proxy <- Called UA
          200 OK

   Calling UA <- proxy
          200 OK




10.5 Session Timer without Called UA Support

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



   Calling UA -> proxy
          INVITE
          k: timer

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




S.Donovan,J.Rosenberg                                        [Page 20]


Internet Draft               Session Timer                 July 20, 2001


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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK




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



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

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

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

   Calling UA <- proxy
          400 Rejected Media

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK





S.Donovan,J.Rosenberg                                        [Page 21]


Internet Draft               Session Timer                 July 20, 2001


10.6 Proxy insists on session timer

   In this scenario, the calling UA does not support the session timer,
   but the proxy on the setup path insists on it by inserting a Require
   header. The UAS does not support the session timer either, so it
   rejects the request with a 420 as per standard RFC2543 extension
   handling. This response is forwarded upstream towards the UAC. The
   UAC treats it as a normal 400 class response, and then ACKs it. In
   this case, the call cannot be established.


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

   Note that proxy insertion of Require is NOT RECOMMENDED.




   Calling UA -> proxy
           INVITE

   proxy -> Called UA
           INVITE                proxy adds session expires
           Require: timer        proxy adds Require
           Session-Expires: 180

   proxy <- Called UA
           420 Bad Extension
           Unsupported: timer

   Calling UA <- proxy
           420 Bad Extension
           Unsupported: timer

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK




10.7 Neither UA Supports Session Timer



S.Donovan,J.Rosenberg                                        [Page 22]


Internet Draft               Session Timer                 July 20, 2001


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



   Calling UA -> proxy
          INVITE

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

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

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK



10.8 Both UAs Support, Change in Roles

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



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

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

   proxy <- Called UA
           200 OK                              Called UA supports timer



S.Donovan,J.Rosenberg                                        [Page 23]


Internet Draft               Session Timer                 July 20, 2001


           Session-Expires: 240;refresher=uac  Inserts Require, Session-Expires
           Require: timer                      Called UA starts timer on send

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

   Calling UA -> proxy
          ACK

   proxy -> Called UA
          ACK



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



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

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

   Calling UA -> proxy
           200 OK                              Calling UA supports timer
           Session-Expires: 240;refresher=uac  Inserts Session-Expires
           Require: timer                      Calling UA updates timer on send

   proxy -> Called UA                          Called UA sees 200 w/refresher=uac
           200 OK                              It is refreshing
           Session-Expires: 240;refresher=uac  Proxy updates timer on send
           Require: timer                      Called UA updates timer on receipt

   proxy <- Called UA
          ACK

   Calling UA <- proxy
          ACK




S.Donovan,J.Rosenberg                                        [Page 24]


Internet Draft               Session Timer                 July 20, 2001


10.9 Proxy Rejects Timer

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



   Calling UA -> Proxy
         INVITE
         Supported: timer
         Session-Expires: 10              UAC uses low timer

   Calling UA <- Proxy
         422 Timer Too Low
         Session-Expires: 200             Proxy says minimum is 200s

   Calling UA -> Proxy
         ACK

   Calling UA -> Proxy
         INVITE
         Supported: timer
         Session-Expires: 300             UAC chooses larger SE
         Min-SE: 200                      Minimum is 200

   Proxy -> Called UA
         INVITE
         Supported: timer
         Session-Expires: 250             Proxy lowers to 250
         Min-SE: 200

   Proxy <- Called UA
         200
         Require: timer
         Session-Expires: 250;refresher=uac   UAS lowers to 200

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

   Calling UA -> Proxy
         ACK

   Proxy -> Called UA



S.Donovan,J.Rosenberg                                        [Page 25]


Internet Draft               Session Timer                 July 20, 2001


         ACK




11 Acknowledgements

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

12 Changes since -04

        o Added requirement for From tags with session timer, to handle
          this crash and reboot case. Discussed when a UA would want to
          recover calls this way.

        o Removed text about inserting Session-Expires:0 when you want
          to indicate that the call is down. Rather, send a 481.

        o Made handling of a 481 a MUST for UAC.

        o Added clarification to call flows on when timer is started and
          updated.

        o Added wording indicating that it is bad to do usage billing
          using SIP.

        o Added wording indicating that the UAS should not change the
          SDP for a re-INVITE that is used solely for refreshing the
          session timer.

        o Added text about using 422 Session Timer Too Small message to
          reject an INVITE with a session expiration value that is
          smaller that policy at a proxy or UAC.

        o Changed SPS to proxy in call flows

        o Mentioned that low session timer values can lead to re-INVITE
          glare.

        o Added discussion of why minimum of 30 minutes is a SHOULD and
          not a MUST.

        o Added Min-SE header and related processing.

        o Added refresher parameter to Session-Expires, which has
          simplified processing.




S.Donovan,J.Rosenberg                                        [Page 26]


Internet Draft               Session Timer                 July 20, 2001


13 Author's Addresses



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

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




14 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] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
   Internet Draft, Internet Engineering Task Force, Feb. 2001.  Work in
   progress.

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





                           Table of Contents



   1          Introduction ........................................    1



S.Donovan,J.Rosenberg                                        [Page 27]


Internet Draft               Session Timer                 July 20, 2001


   2          Protocol Overview ...................................    2
   3          Session-Expires Header Field Definition .............    4
   4          Min-SE Header Field Definition ......................    6
   5          UAC Behavior ........................................    7
   6          Proxy Behavior ......................................    9
   6.1        Processing of requests ..............................    9
   6.2        Processing of Responses .............................   10
   7          UAS Behavior ........................................   11
   8          Performing Refreshes ................................   13
   9          Security Considerations .............................   15
   10         Examples ............................................   16
   10.1       Basic session timer .................................   16
   10.2       Basic negotiation of Session Time ...................   17
   10.3       No Session-Expires Header in INVITE .................   18
   10.4       Session timer without Calling UA Support ............   18
   10.5       Session Timer without Called UA Support .............   20
   10.6       Proxy insists on session timer ......................   22
   10.7       Neither UA Supports Session Timer ...................   22
   10.8       Both UAs Support, Change in Roles ...................   23
   10.9       Proxy Rejects Timer .................................   25
   11         Acknowledgements ....................................   26
   12         Changes since -04 ...................................   26
   13         Author's Addresses ..................................   27
   14         Bibliography ........................................   27



























S.Donovan,J.Rosenberg                                        [Page 28]


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