Internet Engineering Task Force                           Steve Donovan                                   SIP WG
Internet Draft                                     S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-01.txt             MCI Worldcom
October, 1999                                       Expires April, Worldcom,dynamicsoft
March 9, 2000
Expires: September, 2000
                                    draft-ietf-sip-session-timer-00.txt

                         The SIP Session Timer

Status of this Memo

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.

   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 mate-
   rial
   material or to cite them other than as "work work in progress." progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt.
   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 SIP specification [1]. Session Initiation
   Protocol (SIP). This extension adds a new message header, Session-Expires, which is
   used to specify the duration of a requested session.

   A session timer can be used to control the duration of a session if, allows for instance, one of the participants in the session wants to limit
   the cost of the session. Call Stateful SIP Proxy Servers can also use a session timer to track the status periodic refresh of SIP
   sessions for which session
   state exists on the servers. Currently through a re-INVITE. The refresh allows both user agents and
   call stateful SIP Proxy
   Server that is not handling the media stream(s) for the session has
   no mechanism proxies to definitively determine the state of all sessions for
   which it has state.  While in the SIP Specification does provide the BYE
   method for terminating the session, there session is no mechanism for still
   active. The extension defines a SIP
   Proxy Server to detect new general header, Session-Expires,
   which conveys the end lifetime of a session when the BYE message is
   not sent or is lost due to network problems.

1.0 session.

1 Introduction

   The need for the addition of Session Initiation Protocol (SIP) [1], does not currently define
   a session timer was initially motivated
   by the realization keepalive mechanism. The result is that call stateful proxy servers currently have no
   method of determining the end of proxies will
   not always be able to determine whether a session in certain anomalous situ-
   ations. call is still active or
   not. For instance, when a user agent fails to send a BYE message at
   the end of a session session, or the BYE message gets lost due to network
   problems.
   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 session call and has no deterministic method of determining when the
   call state information no longer applies.

   With

   To resolve this problem, this extension defines a keepalive mechanism
   for SIP sessions. UAs send periodic re-INVITEs to keep the addition of 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 timer is considered terminated.
   Both UAs are supposed to send a BYE, and call stateful proxies can
   remove any state for the SIP protocol, call.

   This refresh mechanism has additional applications. For the same
   reasons a call stateful proxy server will have the option of tearing down the ses-
   sion upon the expiration of would like to determine whether
   the session timer.

   A session timer can also be used for other purposes.  For instance,
   it could be used in the implementation of is still active, a prepaid service.  In this
   case all session related signaling user agent would like to make this
   determination. This determination can be routed through made at a SIP Pre-
   paid Server that would control user agent without
   the session time based on a sub-
   scriber's prepaid account. The SIP Prepaid Server could use the ses-
   sion timer of SIP level mechanisms; for audio sessions, periodic RTCP
   packets serve as an indication of liveness [2]. However, it is
   desirable to force separate SIP call liveness from the tear down details of the
   particular session.

   Another important application of the session within a specific
   time.  The session timer could also be used by the is in NAT and
   firewall control. In order for SIP Prepaid Server
   as a trigger to indicate flow through a NAT or firewall,
   holes and/or address bindings must be dynamically created to allow
   the subscriber that media for the prepaid account
   requires more funds session to extend flow. These holes and/or address
   bindings represent state which must be eventually removed. Relying on
   a BYE to trigger the call. removal of state, besides being unreliable,
   introduces a potential denial of service attack.

   This document proposes the addition of the Session-Expires header an extension to
   various SIP messages.  In addition, that defines a new Request Failure message is
   proposed.  This message would be session
   expiration mechanism. Periodic refreshes, through re-INVITEs, are
   used to indicate keep the session timer prob-
   lems, including active. A new general header, the need for 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 session-expires
   Supported header in an INVITE
   message and all requests, excepting ACK, containing the need for
   option tag "timer" [3]. When a smaller session-expires time.

2.0 Session-Expires Header Field Definition

   User agents or proxy servers needing to indicate the maximum duration
   of UAC makes a call, it MAY include a session shall use the
   Session-Expires header. header in the INVITE request. The format presence of the
   Session-Expires header shall be equivalent indicates that the UAC wishes to use the
   session timer for this call. Its value indicates the
   format desired
   expiration time of the Expires header (see section 6.20 in [1]).  As such, session.

   Proxies on the
   end signaling path may have their own requirements for the
   refresh interval of the session can be specified as either an absolute or delta
   time.

   The Session-Expires session. If the Supported header shall be valid in INVITE and ACK requests.
   In addition it shall the
   request lists the option tag "timer", a proxy can be valid in certain response messages.  This
   includes the 200 OK response and the new Request Failure responses
   defined in this document.

   The called UA or any SPS in the path of UAC
   understands the session signaling shall
   have the option of rejecting an INVITE that does not contain the Ses-
   sion-Expires header timer. In this case, if no Session-Expires
   was present, the service context in which proxy can insert one if it so desires. If one was
   present, the session
   request is made requires proxy can lower, but not increase, the use expiration time
   of the session timer.

   The called UA has the option of adding session. If, however, the Session-Expires Supported header to was absent, or was
   present but didn't include the 200 OK response in tag "timer", the case where there was not proxy MAY reject the
   request with a Session-Expires
   header 421, and indicate in the INVITE message.

   An SPS shall also have the option of adding the Session-Expires Require header to an INVITE message.

   In addition, that the called UA and SPS shall have
   feature "timer" is needed. As an alternative, the option of modifying proxy MAY forward
   the value in request, but MUST NOT add the Session-Expires header. This modification shall
   only be will
   allow the call to decrease proceed without a timer.

   Eventually, the requested duration of initial INVITE reaches the session.

   The start time of UAS. Like proxies, the UAS
   MAY add a session shall be based on timer, reduce the sending of session timer, or reject the
   ACK by
   request if the calling UA and receipt of session timer is needed but not supported. If the ACK message by UAS
   accepts the SPS and
   called UA.

   If call, it places the called UA or final value of the SPS requires a session timer for a requested
   session and the calling UA does not include in
   the Session-Expires in the 200 OK response, and includes a Require
   header in the INVITE message, then response indicating that the called UA or feature "timer" was
   applied to the SPS may
   reject response.

   As the request with a 487 request failure message.

   If 200 OK traverses the use of a session timer is desirable but optional for path back towards the ses-
   sion and UAC, proxies make
   note of the calling UA does not include expiration time in the Session-Expires header in the INVITE then the called UA or SPS may add a Session-Expires
   header to the next session setup message. In
   response. The proxy is safe in destroying call state if a refresh is
   not received by this case the SPS shall
   add the Session-Expires header to the INVITE message and the called
   UA shall add expiration time. The UAC then ACKs the INVITE.
   The Session-Expires header to need not be included in the 200 OK response mes-
   sage.

   The calling UA shall have ACK.

   If the ability to request an extension UAC wishes to the
   duration of keep the session by sending alive, it MUST send a re-INVITE message for
   before the ses-
   sion with expiration time. This re-INVITE MAY contain a new Session-Expires Session-
   Expires header.  See section 1.4.6, Changing
   an Existing Session, in [1]. The called UA or any SPS in the path processing of the session signaling shall
   have the ability this re-INVITE by proxies and UAS
   is identical to reject the change in the session duration.

   Upon expiration that of the session timer, the calling UA and called UA
   shall have the option of terminating initial INVITE.

   If the session using UAS does not receive a re-INVITE refreshing the normal session, it
   SHOULD send a BYE
   method.

3.0 Behavior of SIP User Agents

3.1 Behavior of User Agent Clients

   A User Agent Client (UAC) shall have the ability to include the Ses-
   sion-Expires header in an INVITE message.

   The UAC shall have terminate the ability to request an extension of call. If the session
   timer by sending an INVITE message for an existing session with UAC does not receive
   a
   Session-Expires header.  This should be done enough in advance of the
   session timeout response to prevent the called UA or the SPS from timing out re-INVITE used to refresh the session prior session, it SHOULD
   send a BYE to receipt of terminate the new INVITE.

   When requesting an extension 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 UAC shall use a
   value in
   call. Unlike the UA, it MUST NOT send a BYE.

3 Session-Expires header that is less-than or equal to the
   value of the Header Field Definition

   The Session-Expires header received in the 200 OK from the
   original setup of conveys the session.

   The UAC shall have the ability to receive expiration time for a Session-Expires header SIP
   session. It is placed in only in INVITE requests, and is allowed in a
   200 OK message.  This is independent of whether response to an INVITE. Like the SIP Expires header, it can
   contain either an absolute time or not a Session-
   Expires was included in delta-time. If it contains an
   absolute time, this time indicates the original INVITE message.

   The UAC shall have time at which a proxy or UA
   may safely destroy any state associated with the ability to accept call. If it contains
   a delta time, the expiration time of the session is defined as that
   delta plus the time indicated
   in at which the header is observed in a response.

   For example, if a UAS generates a 200 OK response to a re-INVITE that
   contained a Session-Expires header by including unchanged Session-
   Expires header in the ACK generated as with a result value of 3600, the 200 OK.

   The UAC shall have UAS
   computes the ability to reject expiration time of the session as one hour after the
   time indicated
   in when the 200 OK message by not including a Session-Expires header in was sent. For each proxy, the ACK generated as a result of expiration time is
   one hour after the time when the 200 OK message.

   In general, if was received or sent
   (assuming these two are sufficiently close together). For the UAC is able to support session timers then it
   should accept UAC,
   the session expiration time included in the 200 OK, even if it
   changed between is one hour after the INVITE and receipt of the 200 OK.

3.2 Behavior

   The syntax of User Agent Servers

   The User Agent Server shall have the ability to reject an INVITE mes-
   sage that does not contain a Session-Expires header if the INVITE 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
   received an extension of tables 4 and 5 in a service context that requires a session timer.  The UAS
   shall reject the INVITE using [1] for the following response:

        487 Session-
   Expires header:

                     where  enc.  e-e  ACK  BYE  CAN  INV  OPT  REG
    Session-Expires Header Problem
        Session-Expires:    R     n

   The UAS shall have     h    -    -    -    o    -    -
    Session-Expires   200    n     h    -    -    -    o    -    -

4 UAC Behavior

   A UAC which supports the ability to provisionally reject an INVITE session timer extension defined here MUST
   include a Supported header in each request based on (excepting ACK), listing
   the contents of 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 header received in the INVITE message.  For instance, the UAS may choose request used to reject initiate the INVITE if
   call. The value of this header indicates the requested session time when the UAC will
   consider the call expired if no refresh is longer than sent. If the UAS
   desires to participate in request is
   being authenticated, the session.  The UAS shall use Session-Expires header MUST appear before
   the follow-
   ing message Authorization or Proxy-Authorization headers.

   When the response to reject the request:

        487 initial INVITE request arrives, it may or
   may not contain a Session-Expires Header Problem
        Session-Expires: n

   In both cases, the UAS shall include header. UACs MUST be prepared to
   receive a Session-Expires header in a 200 OK response even if none
   were present in the 487 request. The presence of this header in response
   to an accept-
   able delta initial INVITE is only relevant in a 200 OK response. Assuming
   this is the case, the UAC computes the expiration time for of the
   session. If the Session-Expires header contains an absolute time, that is
   the time of expiration. If it contains a delta delta-time, the expiration
   time then is the UAS
   shall calculate time of reception of the end 200 OK plus that delta time. Let
   the difference in time between the reception of the 200 OK and the
   session based on receipt of expiration time be called the ACK
   message refresh interval. Note that completes
   this expiration applies to the call leg created as a successful session initiation:

      End result of that
   200 OK. It is explicitly allowed for there to be differing session time = Receipt of ACK time + Session-Expires time
   The UAS shall have
   timers (or none at all) on differing call legs.

   If the ability 200 OK response to reject the initial INVITE contained a request Session-
   Expires, and the UAC wishes to extend continue with the
   length of the session.  The UAS shall do so by sending session beyond the following
   response:

        487 Session Time Request Problem
        Session-Expires: n

   A value of zero (0) in
   expiration, it MUST generate a refresh before the Session-Expires header shall indicate expiration time. It
   is RECOMMENDED that this be refresh be sent once half the extension request refresh
   interval has elapsed. This refresh is rejected.  Any other value should be less
   than that received 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 re-INVITE message and should indicate an
   acceptable extension to new desired expiration time
   of the session timer. session. If the UAC does not place a Session-Expires header in
   the re-INVITE contains a delta time
   then the UAS shall calculate the new end of request, this means the session from UAC wishes for the pre-
   vious end of session time:

    New end of session time = Previous end of session time + delta time

   If a request to extend the session time is rejected by the UAS then
   the end of session have no
   expiration time that existed prior to the extension request
   shall be remain in effect. going forward. The UAS shall have the ability to add a Session-Expires header to a 200 OK response for an INVITE request that did not contain a session-
   Expires header.

   If the UAS adds a Session-Expires header to the re-INVITE
   contains the actual expiration time. If the 200 OK response and to the resulting ACK
   re-INVITE does not contain a Session-Expires header then header, the
   UAS session no
   longer has an expiration. If the following options:

   - The UAS can choose response to participate in the session without a session
   timer.

   - The UAS can choose to re-INVITE was not participate in the session.  In this
   case, the UAS shall send a BYE message to tear down the session.

   The UAS shall have
   200 OK, the ability to decrease call is still active (as per RFC 2543), but the requested session
   expiration time
   in remains unchanged. As with the INVITE Session-Expires header.

   If original INVITE, the UAS is sending a 200 OK
   UAC MUST be prepared to an INVITE that contained receive a Session-
   Expires Session-Expires header then the UAS shall include in a Session-Expires header 200 OK
   response even if it did not place one in the 200 OK.  The content request.

   It is important to note that the processing rules for re-INVITEs
   parallels that of the Session-Expires header shall be
   either initial INVITE. This helps maintain the content
   idempotency of INVITE.

   A UAC MAY use the Session-Expires header contained in refreshing re-INVITE as a normal SIP re-INVITE;
   that is, this re-INVITE MAY contain an updated session description.
   In the
   INVITE request, if case where the UAS accepts re-INVITE contains an updated session
   description, the requested duration, or a
   decreased 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 timer desired by session, the UAS.

4.0 Behavior 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 Proxy Servers

   A SIP Proxy Server has traffic to pass after the option expiration time of tracking the duration of ses-
   sions for which it
        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.

   If proxy may have guidelines about the SPS receives desired
   maximum lifetime for a call initiated through it. When an initial
   INVITE without is received to establish a call, a proxy MAY insert a
   Session-Expires header, it
   has header in the option of sending request before forwarding it, if (1)
   none was present in the request, and (2) if the following request failure response
   indicating that contained a
   Supported header with the option tag "timer". This Session-Expires
   header is required:

        487 Session-Expires Header Problem
        Session-Expires: n

   A SPS has may contain any desired expiration time the option of rejecting an proxy would like.

   If the initial INVITE with had both a Session-Expires header based on the time specified in and a
   Supported header containing the header.  For instance, if option tag "timer", the time specified is too long. The proxy server shall do so by send-
   ing MAY
   reduce the value in the following request failure response:

        487 Session-Expires Header Problem
        Session-Expires: n

   In both cases, header before forwarding the SPS shall include in
   request, but MUST NOT increase it.

   If the 487 response an accept-
   able delta time for initial INVITE did not contain a Supported header with the session.

   If
   option tag "timer", the proxy MUST NOT insert the Session-Expires
   header contains a delta time then the SPS
   shall use into the method of calculating forwarded request. It MAY, however, follow the session time specified
   procedures defined in
   section 3.2.

   A SPS has [3] and reject the option of rejecting a request with a 421.

   When a 200 OK response arrives for an extension of the
   session timer call, the actual expiration
   time for an existing session by sending the following
   request failure response:

        487 Session-Expires Header Problem
        Session-Expires: n

   A value of zero (0) call leg is contained in the Session-Expires header shall indicate that header. The
   proxy MUST NOT modify the extension request is rejected. Any other value should be less
   than that received in the re-INVITE message and should indicate an
   acceptable extension to the session timer.

   If the SPS accepts the request to extend the session timer then it
   shall use the method of calculating the new end of session time spec-
   ified in section 3.2.

   The SPS shall have the ability to add a Session-Expires header to an
   INVITE request that does not contain a Session-Expires header. when
   forwarding the response upstream. The SPS shall have expiration of the ability to decrease call will
   occur at the requested session time indicated in the INVITE Session-Expires header.

   The content of If the
   Session-Expires header included in the INVITE sent
   by contains a delta-time, the SPS shall be either expiration time is
   the content time of receipt of the Session-Expires header
   contained in 200 OK response, plus that delta time.

   Re-INVITE requests may arrive from the INVITE request, if UAC, refreshing the UAS accepts session
   and extending the requested
   duration, or a decreased value expiration time. Processing of the session timer desired these re-INVITEs by
   a proxy is identical to the
   SPS. procedure for processing the initial
   INVITE.

   If the SPS adds session expires without having seen a Session-Expires header to the 200 OK response and
   the resulting ACK does not contain to a Session-Expires header then the
   SPS has
   re-INVITE, the following options:

   - The SPS can choose to allow proxy MAY consider the session without a session timer.

   - The SPS can choose to not allow the session.

5.0 Header Field Definitions

   The following is call leg terminated. This means
   it MAY flush any state associated with that call leg.

6 UAS Behavior

   When a UAS receives an extension of tables 4 and 5 in [1] INVITE for the Ses-
   sion-Expires header:

                     where  enc.  e-e  ACK  BYE  CAN  INV  OPT  REG
    Session-Expires    R           e    o    -    -    o    -    -
    Session-Expires   200          e    -    -    -    o    -    -
    Session-Expires   487          e    -    -    -    o    -    -

6.0 Request Failure Messages

6.1 487 Session-Expires Header Problem

   The server received an a new call, and that INVITE request with one of the following prob-
   lems:

   - The server requires
   contains a Session-Expires header.  In this case header, the
   response should contain UAS MUST place a Session-Expires Session-
   Expires header with an acceptable
   session time.

   - The server received an INVITE with in a Session-Expires header with an 200 OK response (assuming the UAS accepts the
   call). The UAS MAY reduce the expiration time longer than the server is willing to accept.  In when it places this
   case
   header into the response should response, but it MUST NOT increase it.  If the inital
   INVITE did not contain a Session-Expires header with an
   acceptable session time.

   - The server received an INVITE with header, but it did contain a Session-Expires
   Supported header for an
   existing session and the server does not wish to extend containing the session.
   In this case option tag "timer", the response should contain UAS MAY
   insert a Session-Expires header
   with a value of zero (0).

   - The server received an INVITE with a Session-Expires into the response. This header for an
   existing session with an MAY
   have any desired expiration time longer than the server is
   willing to accept. In this case time.

   If the response should initial INVITE did not contain a Ses-
   sion-Expires Supported header with an acceptable session time.

7.0 Security Considerations

   There are no new security considerations introduced by the Session-
   Expires header.

8.0 Examples

   The following examples are meant to illustrate
   option tag "timer", the functionality
   associated with UAS MUST NOT insert the Session-Expires header.  In
   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.

8 Examples

   The following examples are meant to illustrate the functionality
   associated with the session timer. In the interest of brevity, other all
   headers excepting Supported, Session-Expires and Require are
   intentionally left out of the SIP mes-
   sages. 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

     Calling UA ->    Called UA
            ACK starts session timer on send
                                  Calling UA starts session timer
            Session-Expires: 120

     Called on receipt
   Calling UA Receipt of ACK -> Called UA starts session timer

     Calling UA determines need to extend session time
          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

     Calling UA ->    Called UA
            ACK starts session timer on send
                                  Calling UA resets starts session end time
            Session-Expires: 120

     Called timer on receipt
   Calling UA Receipt of ACK -> Called UA resets session timer

     Session timeout detected by Called
          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

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

     Calling UA -> SPS
            ACK  Proxy starts timer on send
           Require: timer        Calling UA starts session timer
            Session-Expires: 120 on receipt

   Calling UA -> SPS Receipt of
          ACK

   SPS starts session timer

     SPS -> Called UA
          ACK                        Called

   For whatever reason, the calling UA starts session timer
            Session-Expires: 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

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
            4xx Session-Expires Header
          421 Extension Required
            Session-Expires: 120       Suggested session time
          Require: timer

   Calling UA -> SPS
            INVITE
            Session-Expires: 120

     Session setup continues
          ACK

8.4 Invalid Addition of Session-Expires Header Rejection by Called UA

     Calling UA -> Called UA
            INVITE                     No Session-Expires header
            Session-Expires: 1000

     Calling UA <- Called UAS

   In this scenario, the calling UA
            4xx Session Time Request Rejected
            Session-Expires: 120       Suggested indicates that it supports the
   session time timer, but does not add the Session-Expires into the INVITE.
   The UAS, however, adds the header.

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

     Session setup continues

8.5 Session-Expires Header Added by SPS, Rejected by UAC
          Supported: timer

   Calling UA -> SPS
            INVITE

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

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

   Calling UA -> SPS Called UA
          ACK                    Calling

8.5 Addition of Session-Expires by Proxy

   In this scenario, the calling UA indicates that it supports the
   session timer, but does not include S-E 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
          done to unify the choice processing of allowing 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 not allowing 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 as a
   result of if the Calling calling UA not supporting supported
          the Session-Expires function.

9.0 Changes in this version

   The changes in this version of session timer, but the document were primarily editorial
   in nature.

   10.0 References

[1] M. Handley, H. Schulzrinne, E. Schooler, 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 J. Rosenberg, "SIP:
   Session Initiation Protocol", RFC 2543, March 1999.

11.0 we should not worry about it)

11 Author's Address Addresses

   Steven R. Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081
   Email:
   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
   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