[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-01.txt             MCI Worldcom,dynamicsoft
March 9, 2000
Expires: September, 2000


                         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

   The list of Internet-Draft Shadow Directories can be accessed at
   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
   call stateful proxies to determine in the SIP session is still
   active. The extension defines a new general header, Session-Expires,
   which conveys the lifetime of the session.


1 Introduction

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



S.Donovan,J.Rosenberg                                         [Page 1]


Internet Draft               Session Timer                 March 9, 2000


   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.

   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 important application of the session timer is in NAT and
   firewall control. In order for SIP to flow through a NAT or firewall,
   holes and/or address bindings must be dynamically created to allow
   the media for the session to flow. These holes and/or address
   bindings represent state which must be eventually 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. A new general header, the Session-
   Expires header, is defined. It conveys the expiration time of the
   session.

2 Protocol Overview

   UACs which support the session timer extension defined here 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
   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.

   Proxies on the signaling path may have their own requirements for the
   refresh interval of the session. If the Supported header in the



S.Donovan,J.Rosenberg                                         [Page 2]


Internet Draft               Session Timer                 March 9, 2000


   request lists the option tag "timer", a proxy can be certain the UAC
   understands the session timer. In this case, if no Session-Expires
   was present, the proxy can insert one if it so desires. If one was
   present, the proxy can lower, but not increase, the expiration time
   of the session. If, however, the Supported header was absent, or was
   present but didn't include the tag "timer", the proxy MAY reject the
   request with a 421, and indicate in the Require header that the
   feature "timer" is needed. As an alternative, the proxy MAY forward
   the request, but MUST NOT add the Session-Expires header. This will
   allow the call to proceed without a timer.

   Eventually, the initial INVITE reaches the UAS. Like proxies, the UAS
   MAY add a session timer, reduce the session timer, or reject the
   request if the session timer is needed but not supported. If the UAS
   accepts the call, it places the final value of the session timer in
   the Session-Expires in the 200 OK response, and includes a Require
   header in the response indicating that the feature "timer" was
   applied to the response.

   As the 200 OK traverses the path back towards the UAC, proxies make
   note of the expiration time in the Session-Expires header in the
   response. The proxy is safe in destroying call state if a refresh is
   not received by this expiration time. The UAC then ACKs the INVITE.
   The Session-Expires need not be included in the ACK.

   If the UAC wishes to keep the session alive, it MUST send a re-INVITE
   before the expiration time. This re-INVITE MAY contain a Session-
   Expires header. The processing of this re-INVITE by proxies and UAS
   is identical to that of the initial INVITE.

   If the UAS does not receive a re-INVITE refreshing the session, it
   SHOULD send a BYE to terminate the call. If the UAC 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. It is placed in only in INVITE requests, and is allowed in a
   200 OK 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 response.



S.Donovan,J.Rosenberg                                         [Page 3]


Internet Draft               Session Timer                 March 9, 2000


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

   The syntax of the Session-Expires header is:



        Session-Expires  =  "Session-Expires" ":" ( SIP-date |
                            delta-seconds )


   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   200    n     h    -    -    -    o    -    -



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

   When the response to the initial INVITE request arrives, it may or
   may not contain a Session-Expires header. UACs MUST be prepared to
   receive a Session-Expires header in a 200 OK response even if none
   were present in the request. The presence of this header in response



S.Donovan,J.Rosenberg                                         [Page 4]


Internet Draft               Session Timer                 March 9, 2000


   to an initial INVITE is only relevant in a 200 OK response. Assuming
   this is the case, the UAC computes the expiration time of the
   session. If the Session-Expires contains an absolute time, that is
   the time of expiration. If it contains a delta-time, the expiration
   time is the time of reception of the 200 OK plus that delta time. Let
   the difference in time between the reception of the 200 OK and the
   session expiration time be called the refresh interval. Note that
   this expiration applies to the call leg created as a result of that
   200 OK. It is explicitly allowed for there to be differing session
   timers (or none at all) on differing call legs.

   If the 200 OK response to the initial INVITE contained a Session-
   Expires, and the UAC wishes to continue with the session beyond the
   expiration, it MUST generate a refresh before the expiration time. It
   is RECOMMENDED that this be refresh be sent once half the refresh
   interval has elapsed. This refresh is accomplished by sending a re-
   INVITE request on the given call leg. The UAC MAY include a Session-
   Expires in this re-INVITE, indicating the new desired expiration time
   of the session. If the UAC does not place a Session-Expires header in
   the request, this means the UAC wishes for the session to have no
   expiration time going forward. The 200 OK response to the re-INVITE
   contains the actual expiration time. If the 200 OK response to the
   re-INVITE does not contain a Session-Expires header, the session no
   longer has an expiration. If the response to the re-INVITE was not a
   200 OK, the call is still active (as per RFC 2543), but the
   expiration time remains unchanged. As with the original INVITE, the
   UAC MUST be prepared to receive a Session-Expires header in a 200 OK
   response even if it did not place one in the request.

   It is important to note that the processing rules for re-INVITEs
   parallels that of the initial INVITE. This helps maintain the
   idempotency of INVITE.

   A UAC MAY use the refreshing re-INVITE as a normal SIP re-INVITE;
   that is, this re-INVITE MAY contain an updated session description.
   In the case where the re-INVITE contains an updated session
   description, the session description MUST somehow indicate that it is
   unchanged. In the case of SDP [4], this is accomplished by using the
   same value for the origin field.

   If no 200 OK response to a refreshing re-INVITE is received before
   the expiration of the session, the UAC SHOULD send a BYE request to
   terminate the call. It SHOULD send this BYE slightly before
   expiration of the session. Ten seconds is RECOMMENDED.


        Firewalls and NATs may be very unforgiving about allowing
        SIP traffic to pass after the expiration time of the



S.Donovan,J.Rosenberg                                         [Page 5]


Internet Draft               Session Timer                 March 9, 2000


        session. It is for this reason that the BYE should be sent
        before the expiration.

5 Proxy Behavior

   Session expirations are mostly of interest to call stateful proxy
   servers. However, any proxy server may follow the rules described
   here.

   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 (1)
   none was present in the request, and (2) if the request contained a
   Supported header with the option tag "timer". This Session-Expires
   header may contain any desired expiration time the proxy would like.

   If the initial INVITE had both a Session-Expires header and a
   Supported header containing the option tag "timer", the proxy MAY
   reduce the value in the Session-Expires header before forwarding the
   request, but MUST NOT increase it.

   If the initial INVITE did not contain a Supported header with the
   option tag "timer", the proxy MUST NOT insert the Session-Expires
   header into the forwarded request. It MAY, however, follow the
   procedures defined in [3] and reject the request with a 421.

   When a 200 OK response arrives for the call, the actual expiration
   time for the call leg is contained in the Session-Expires header. The
   proxy MUST NOT modify the value of the Session-Expires header when
   forwarding the response upstream. The expiration of the call will
   occur at the time indicated in the Session-Expires header. If the
   Session-Expires header contains a delta-time, the expiration time is
   the time of receipt of the 200 OK response, plus that delta time.

   Re-INVITE requests may arrive from the UAC, 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 200 OK 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.

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



S.Donovan,J.Rosenberg                                         [Page 6]


Internet Draft               Session Timer                 March 9, 2000


   Expires header in a 200 OK response (assuming the UAS accepts the
   call). The UAS MAY reduce the expiration time when it places this
   header into the response, but it MUST NOT increase it.  If the inital
   INVITE did not contain a Session-Expires header, but it did contain a
   Supported header containing the option tag "timer", the UAS MAY
   insert a Session-Expires header into the response. This header MAY
   have any desired expiration time.

   If the initial INVITE did not contain a Supported header with the
   option tag "timer", the UAS MUST NOT insert the Session-Expires
   header into the 200 OK response. It MAY, however, follow the
   procedures defined in [3] and reject the request with a 421.

   If the UAS sends a 200 OK to the initial INVITE, and that 200 OK had
   a Sesion-Expires header, the UAS computes the expiration time of the
   session. If the Session-Expires contains an absolute time, that is
   the time of expiration. If it contains a delta-time, the expiration
   time is the time of transmission of the 200 OK plus that delta time.

   As described in Section 4, the UAC will send periodic re-INVITEs to
   refresh the session. The UAS MUST be prepared to receive and process
   these re-INVITEs. Processing of the re-INVITE, as far as the session
   timer is concerned, is identical to the rules for the initial INVITE,
   described above. Note that if the 200 OK to the re-INVITE has no
   Session-Expires, no expiration time exists for the session.

   Since the re-INVITE is a standard re-INVITE, it is possible, for
   whatever reason, that the UAS might reject the request. The
   processing rules for session timer only apply to INVITEs with a 200
   OK response.

   If no re-INVITE is received before expiration of the timer, the UAS
   SHOULD send a BYE for the call leg.

7 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 introducing denial-of-service attacks. Use of short refresh
   intervals allows the proxies to create network load. The session
   timer mechanism allows the proxy to be able to terminate established
   calls - a capability a normal proxy doesn't have in [1].

   As a result of these potential attacks, it is RECOMMENDED that IP or
   transport level security is used when communicating between proxies.




S.Donovan,J.Rosenberg                                         [Page 7]


Internet Draft               Session Timer                 March 9, 2000


8 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 and Require are
   intentionally left out of the SIP messages.

8.1 Basic session-timer setup with UAS detected timeout



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

   Calling UA <- Called UA
          200 OK
          Require: timer
          Session-Expires: 120    Called UA starts session timer on send
                                  Calling UA starts session timer on receipt
   Calling UA -> Called UA
          ACK

   60 seconds later:

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

   Calling UA <- Called UA
          200 OK
          Require: timer
          Session-Expires: 120    Called UA starts session timer on send
                                  Calling UA starts session timer on receipt
   Calling UA -> Called UA
          ACK

   120 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




S.Donovan,J.Rosenberg                                         [Page 8]


Internet Draft               Session Timer                 March 9, 2000


8.2 Basic negotiation of Session Time

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



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

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

   SPS <- Called UA
           200 OK                Called UA wants a shorter timer
           Session-Expires: 120  Called UA starts timer
           Require: timer

   Calling UA <- SPS
           200 OK
           Session-Expires: 120  Proxy starts timer on send
           Require: timer        Calling UA starts timer on receipt

   Calling UA -> SPS
          ACK

   SPS -> Called UA
          ACK

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

   Calling UA -> SPS
           BYE

   SPS -> Called UA
          BYE

   SPS <- Called UA
          200 OK

   Calling UA <- SPS
          200 OK




S.Donovan,J.Rosenberg                                         [Page 9]


Internet Draft               Session Timer                 March 9, 2000


8.3 No Session-Expires Header Rejection by SPS

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



   Calling UA -> SPS
          INVITE                 No Session-Expires or Supported header

   Calling UA <- SPS
          421 Extension Required
          Require: timer

   Calling UA -> SPS
          ACK



8.4 Addition of Session-Expires by UAS

   In this scenario, the calling UA indicates that it supports the
   session timer, but does not add the Session-Expires into the INVITE.
   The UAS, however, adds the header.



   Calling UA -> Called UA
          INVITE
          Supported: timer

   Calling UA <- Called UA
          200 OK
          Require: timer
          Session-Expires: 120   Called UA starts timer on send
                                 Calling UA starts timer on receipt

   Calling UA -> Called UA
          ACK




8.5 Addition of Session-Expires by Proxy

   In this scenario, the calling UA indicates that it supports the



S.Donovan,J.Rosenberg                                        [Page 10]


Internet Draft               Session Timer                 March 9, 2000


   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 result is that the call is set up without a session timer.



   Calling UA -> SPS
          INVITE
          k: timer

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

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

   Calling UA <- SPS
          200 OK

   Calling UA -> SPS
          ACK

   SPS -> Called UA
          ACK




9 Changes since -00

        o Changed to make use of the Supported header.

        o Conveyance of Session Expires in ACK is no longer needed
          (because of usage of the Supported header), and has been
          removed.

        o Session Expires only allowed in INVITE, not in BYE as
          previously specified. Usage in BYE doesn't accomplish
          anything, as the call is terminated.

        o Specified that only UAC sends re-INVITEs for keepalives.

        o Session Expires only present in 200 OK responses. Doesn't
          appear to be needed in any other.

        o Session-Expires no longer mandatory in re-INVITEs. This is



S.Donovan,J.Rosenberg                                        [Page 11]


Internet Draft               Session Timer                 March 9, 2000


          done to unify the processing of INVITE and re-INVITE for
          session timer. Also means that a previously timed session can
          become untimed.

        o Changed semantics of delta-time to be relative to the time of
          message arrival, rather than the time of previous expiration.
          This is in line with normal Expires processing.

        o The original mechanism allowed a proxy to reject the request
          if the timer was too long, or to reduce the timer. There seems
          to be no clear reason to have both. Rejecting will just cause
          the client to resubmit with the shorter expiration, resulting
          in the same net effect with additional complexity. Thus, the
          notion of rejecting session timers is removed, and with it,
          the 488 response code, which is then uneccesary. This seems to
          simplify the protocol.

        o A mechanism had existed to reject a session timer with a
          Session-Expires of 0, meaning the expiration remains
          unchanged. With the new definition of the relative offset for
          Expires, this no longer requires special treatment. A proxy or
          UAS can set the session timer with an absolute time equal to
          the current expiration.

10 Open Issues

        o Should we allow Session-Expires in non-INVITE requests,
          perhaps INFO (I think no)

        o Should we allow the UAC to insert a Require header in the
          request, indicating that the UAS must support the session
          timer?  (I think no)

        o With this draft (and the previous versions), there was no way
          for the proxy to reject the call if the calling UA supported
          the session timer, but the called UA didn't. Is this a
          problem? If so, what can be done about it? (I think there is
          nothing we can do, and we should not worry about it)

11 Author's Addresses



   Steven R. Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081



S.Donovan,J.Rosenberg                                        [Page 12]


Internet Draft               Session Timer                 March 9, 2000


   email: steven.r.donovan@wcom.com

   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ 07052
   email: jdrosen@dynamicsoft.com




12 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments (Proposed
   Standard) 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
   (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.

   [3] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support
   by servers," Internet Draft, Internet Engineering Task Force, Jan.
   2000.  Work in progress.

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



   Full Copyright Statement

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

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



S.Donovan,J.Rosenberg                                        [Page 13]


Internet Draft               Session Timer                 March 9, 2000


   English.

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

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




                           Table of Contents



   1          Introduction ........................................    1
   2          Protocol Overview ...................................    2
   3          Session-Expires Header Field Definition .............    3
   4          UAC Behavior ........................................    4
   5          Proxy Behavior ......................................    6
   6          UAS Behavior ........................................    6
   7          Security Considerations .............................    7
   8          Examples ............................................    8
   8.1        Basic session-timer setup with UAS detected
   timeout ........................................................    8
   8.2        Basic negotiation of Session Time ...................    9
   8.3        No Session-Expires Header Rejection by SPS ..........   10
   8.4        Addition of Session-Expires by UAS ..................   10
   8.5        Addition of Session-Expires by Proxy ................   10
   9          Changes since -00 ...................................   11
   10         Open Issues .........................................   12
   11         Author's Addresses ..................................   12
   12         Bibliography ........................................   13














S.Donovan,J.Rosenberg                                        [Page 14]


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