Internet Engineering Task Force
SIP WG Working Group                                             S.Donovan
Internet Draft                                                 S.Donovan                                              dynamicsoft
                                                             J.Rosenberg
                                                             dynamicsoft
draft-ietf-sip-session-timer-10.txt
November 4, 2002
Document: draft-ietf-sip-session-timer-11.txt              J. Rosenberg
Category: Informational                                     Dynamicsoft
Expires: May January, 2004                                     July 1, 2003

        Session Timers in the Session Initiation Protocol (SIP)

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. RFC2026 [1].

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

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

   To view the
   The list of Internet-Draft Shadow Directories, see Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

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

Table of Contents

   1          Introduction ........................................    3
   2          Terminology .........................................    4
   3          Overview of Operation ...............................    4
   4          Session-Expires Header Field Definition .............    6
   5          Min-SE Header Field Definition ......................    7
   6          422 Response Code Definition ........................    8
   7          UAC Behavior ........................................    8
   7.1        Generating a Session Refresh Request ................    8
   7.2        Processing a 2xx Response ...........................   10
   7.3        Processing a 422 Response ...........................   11
   8          Proxy Behavior ......................................   11
   8.1        Processing of Requests ..............................   11
   8.2        Processing of Responses .............................   13
   8.3        Session Expiration ..................................   13
   9          UAS Behavior ........................................   14
   10         Performing Refreshes ................................   16
   11         Security Considerations .............................   16
   11.1       Inside Attacks ......................................   17
   11.2       Outside Attacks .....................................   17
   12         IANA Considerations .................................   18
   12.1       IANA Registration of Min-SE and Session-Expires
   Header Fields ..................................................   18
   12.2       IANA Registration of the 422 (Session Interval Too
   Small) Response Code ...........................................   18
   12.3       IANA Registration of the "timer" Option Tag .........   18
   13         Example Call Flow ...................................   19
   14         Acknowledgements ....................................   24
   15         Author's Addresses ..................................   24
   16         Normative References ................................   24
   17         Informative References ..............................   24

1

1. Introduction
   The Session Initiation Protocol (SIP) [1], does not define a
   keepalive mechanism for the sessions it establishes. Although the
   user agents may be able to determine if the session has timed out
   using session specific mechanisms, proxies will not be able to do
   so. The result is that call stateful proxies will not always be able
   to determine whether a session is still active or not. For instance,
   when a user agent fails to send a BYE message at the end of a
   session, or the BYE message gets lost due to network problems, a
   call stateful proxy will not know when the session has ended.  In
   this situation, the call stateful proxy will retain state for the
   call and has no deterministic method of determining when the call
   state information no longer applies.

<Lastname>              Category - Expiration                       1 
   To resolve this problem, this extension defines a keepalive
   mechanism for SIP sessions. UAs send periodic re-INVITE or UPDATE
   [2] requests (referred to as session refresh requests) to keep the
   session alive. The interval for the session refresh requests is
   determined through a negotiation mechanism defined here. If a
   session refresh request is not received before the interval passes,
   the session is considered terminated. Both UAs are supposed to send
   a BYE, and call stateful proxies can remove any state for the call.

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

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

   This document proposes provides an extension to SIP that defines a session
   expiration mechanism. Periodic refreshes, through re-INVITEs or
   UPDATEs, are used to keep the session active. The extension is
   sufficiently backwards compatible with SIP that it works so long as
   either one of the two participants in a dialog understand the
   extension. Two new header fields, Session-Expires and Min-SE, and a
   new response code, 422, are defined. Session-Expires conveys the
   duration of the session, and Min-SE conveys the minimum allowed
   value for the session expiration. The 422 response code indicates
   that the session timer duration was too small.

2

2. Terminology

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

   Additionally, we define the following terms:

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

S. Donovan et. Al.          Informational                           2 
        header field in a 2xx response to a session refresh request
        that they receive.

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

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

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

        Refresh: Same as a session refresh request.

3

3. Overview of Operation

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

   This extension has the property that it works even when only one UA
   in a dialog supports it. The processing steps differ for handling
   each of the four cases (UAC supports it, or doesn't, and UAS
   supports it, or doesn't). For simplicity's sake, this section will
   describe basic operation in the case where both sides support the
   extension.

   A UAC starts by sending an INVITE. It includes a Supported header
   with the option tag "timer", ætimerÆ, indicating support for this extension.
   This request passes through proxies and B2BUAs, any one of which may
   have an interest in establishing a session timer. Each of them can
   insert a Session-Expires header field into the request if none is
   already there, containing the desired interval. If one is already
   there, a proxy or B2BUA can reduce the interval, but not to a value
   lower than the Min-SE header field. The Min-SE header field contains
   the minimum allowed value of the session interval. Its purpose,
   explained below, is to ensure that the session interval is not lower
   than any proxies proxy's configured minimum.

   If the Session-Expires interval is too low for a proxy, it can
   reject the request with a 422 response. That response contains the
   Min-SE header field, identifying the minimum session interval it is
   willing to support. The UAC will try again, this time including the
   Min-SE header in the request. The header field contains the largest

S. Donovan et. Al.          Informational                           3 
   Min-SE header field it observed in all 422 responses received
   previously. This way, the minimum timer meets the constraints of all
   proxies along the path.

   After several INVITE/422 iterations, the request eventually arrives
   at the UAS. The UAS can adjust the value of the session interval as
   if it was a proxy, and when done, it places the final session
   interval into the Session-Expires header field in a 2xx response.
   The Session-Expires header field also contains a "refresher" ærefresherÆ
   parameter, which indicates who is doing the refreshing - the UA that
   is currently the UAC, or the UA that is currently the UAS. As the
   2xx response travels back through the proxy chain, each proxy or
   B2BUA can observe the final session interval (they interval, but they can't change it).
   it.

   From the Session-Expires header field in the response, both UAs know
   that a session timer is active, they know when it will expire, and
   they know who is refreshing. At some point before the expiration,
   the currently active refresher generates a session refresh request,
   which is a re-INVITE or UPDATE [2] request.  If the refresher never
   gets a response to that session refresh request, it sends a BYE to
   terminate the session. Similarly, if the other side never gets the
   session refresh request before the session expires, it sends a BYE.

   The refresh requests sent once the session is established are
   processed identically to the initial requests, as described above.
   This means that a successful session refresh request will extend the
   session, as desired.

   The extension introduces additional complications beyond this basic
   flow to support cases where only one of the UA support UAs supports it.  One
   such complication is that a proxy may need to insert the Session-Expires Session-
   Expires header into the response, in the event that the UAS doesn't
   support the extension. The negotiation of the role of refresher is
   also affected by this capability; it takes into consideration which
   participants support the extension.

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

4

4. Session-Expires Header Field Definition

   The Session-Expires header field conveys the session interval for a
   SIP session. It is placed only in INVITE or UPDATE requests, and is
   allowed as well
   as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires
   header field, it contains a delta-time.

   There is no absolute minimum value for the Session-Expires header
   field. However, 1800 seconds (30 minutes) is RECOMMENDED. In other
   words, SIP entites entities MUST be prepared to handle Session-Expires

S. Donovan et. Al.          Informational                           4 
   header field values of any duration, but entities that insert the Session-
   Expires
   Session-Expires header field SHOULD NOT choose values less than 30
   minutes.

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

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

   The syntax of the Session-Expires header field is:

   Session-Expires  =  ("Session-Expires" ('Session-Expires' / "x") 'x') HCOLON delta-seconds
                      *(SEMI se-params)
   se-params        = refresher-param / generic-param
   refresher-param  =  "refresher" 'refresher' EQUAL ("uas"  ('uas' / "uac") 'uac')

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

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

   Header field    where proxy ACK BYE CAN INV OPT REG PRA UPD SUB NOT
   _____________________________________________________________________

   Session-Expires   R    amr   -   -   -   o   -   -   -   o   -   -
   Session-Expires  2xx   ar    -   -   -   o   -   -   -   o   -   -
   Min-SE            R    amr   -   -   -   o   -   -   -   o   -   -
   Min-SE           422         -   -   -   m   -   -   -   m   -   -

   Table 1: 1 Session-Expires and Min-SE Header Fields

5 Fields}

5. Min-SE Header Field Definition

S. Donovan et. Al.          Informational                           5 
   The Min-SE header field indicates the minimum value for the session
   interval, in units of delta-seconds. When used in an INVITE or
   UPDATE request, it indicates the smallest value of the session
   interval
   which that can be used for that session.

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

   The Min-SE header field MUSTNOT {MUSTNOT} be used in responses except those
   with a 422 response code. It indicates the minimum value of the
   session interval that the server is willing to accept.

   The syntax of the Min-SE header field is:

   Min-SE   =  "Min-SE"   'Min-SE' HCOLON delta-seconds *(SEMI generic-param)

6

6. 422 Response Code Definition

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

7

7. UAC Behavior
7.1 Generating a an Initial Session Refresh Request
   A UAC which that supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" 'timer' [1]. It MUST do so even if the UAC is
   not requesting usage of the session timer for this session.

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

   The 'timer'.

   A UAC MUST insert MAY include the Min-SE header field into in the initial INVITE
   request.

   A UAC MAY include a Session-Expires in an initial session refresh
   request for a particular dialog if it has ever received a 422
   response to wishes for a previous session refresh request on the same dialog, or
   if it has received a session refresh request on that dialog which
   contained a Min-SE header field. Similarly, if no dialog has been
   established yet, a UAC MUST insert the Min-SE header field into an
   INVITE request if it has ever received a 422 response timer to be applied to a previous
   INVITE request with the same Call-ID.
   session. The value of the Min-SE this header field present in a indicates the session refresh
   request MUST be
   interval desired by the largest value amongst all UAC.  If a Min-SE header field
   values returned in all 422 responses, or received is included in the

S. Donovan et. Al.          Informational                           6 
   initial session refresh
   requests, on the same dialog, if a dialog has been established. If no
   dialog has been established, request, the Min-SE header field value is set of the Session-Expires
   MUST be equal to the largest value amongst all Min-SE header field values returned in
   all 422 responses for an INVITE request with the same Call-ID. A
   result of this rule is that Min-SE.

   The UAC MAY include the maximum refresher parameter with value of 'uac' if it
   wishes to perform the Min-SE refreshes. However, it is
   effectively "cleared" once RECOMMENDED that the dialog is established, and from
   parameter be omitted, so that
   point on, only it can be selected by the values from proxies known negotiation
   mechanisms described below.

7.2 Processing a 2xx Response

   Session timer requires a UA to be on create and maintain state. This state
   includes the proxy path
   will end up being used.

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

   A UAC MAY include refresher. This state is associated with the Min-SE header field in an INVITE request
   outside of a dialog, even if it never received dialog
   on which the session has been negotiated.

   When a 422 previously.

   A UAC MAY include 2xx response to a Session-Expires in an initial session refresh request request if arrives, it wishes for may or
   may not contain a session timer to be applied to Require header field with the
   session. The value of this ætimerÆ. If it
   does, the UAC MUST look for the Session-Expires header field indicates the session
   interval desired by to
   process the UAC. In a session refresh request sent within response.

   If there was a dialog Require header field in the response with an active session timer, the value
   ætimerÆ, the Session-Expires header field SHOULD will always be present. When present, it
   UACs MUST be equal prepared to the maximum of the Min-SE receive a Session-Expires header field (recall that its default value when not in a
   response even if none were present is zero)
   and in the current session interval.

   In an initial session refresh request, request.  The ærefresherÆ
   parameter will be present in the Session-Expires header field,
   indicating who will be performing the refreshes. The UAC MAY include MUST set
   the identity of the refresher parameter with value "uac" if it wishes to perform the
   refreshes. However, it is RECOMMENDED that value of this parameter. If the
   parameter be omitted,
   so that it can be selected by the negotiation mechanisms described
   below. If contains the session refresh request is not value æuacÆ, the initial one, it UAC will perform them. It is
   RECOMMENDED
   possible that the refresher parameter be set to "uac" if UAC requested session timer (and thus included a
   Session-Expires header field in the
   element sending the request is currently performing refreshes, else
   "uas" if its peer is performing request), but there was no
   Require or Session-Expires header field in the refreshes. 2xx response. This way,
   will happen when the role of
   refresher does not change on each refresh. However, if it wishes to
   explicitly change UAS doesn't support the roles, it MAY use a value of "uas" if it knows
   that session timer
   extension, and only the other side supports UAC has asked for a session timer. It could know timer (no
   proxies have requested it). In this by
   having received a request from its peer with a Supported header field
   containing case, if the value "timer". If it UAC still wishes to reselect
   use the roles, session timer (they are purely for its benefit alone), it
   MAY omit the parameter.

   A re-INVITE generated
   has to refresh perform them. To do this, the session is a normal re-INVITE,
   and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports follows the UPDATE method, it is RECOMMENDED
   that UPDATE be used instead of a re-INVITE. A UA can make procedures
   defined in this
   determination specification as if it has seen an Allow the Session-Expires header field from its peer with
   were in the 2xx response, and its value "UPDATE", or through a mid-dialog OPTIONS request. It is
   RECOMMENDED that was the UPDATE request not contain an offer [4], same as the one in
   the request, but with a
   re-INVITE SHOULD contain one, even if the details refresher parameter of æuacÆ.

   If the session have 2xx response did not changed. contain a Session-Expires header field,
   there is no session expiration. In that this case, no refreshes need to
   be sent. A 2xx without a Session-Expires can come for both initial
   and mid-dialog session refresh requests. This means that the offer MUST indicate that it has not
   changed. In the case of SDP, this is accomplished session
   timer can be æturned-offÆ mid dialog by including receiving a response without
   a Session-Expires header.

   The UAC remembers the
   same value session interval for a session as the origin value of
   the delta-time from the Session-Expires header field as previous SDP messages in the most
   recent 2xx response to its peer.
   The same a session refresh request on a dialog. It is true
   explicitly allowed for an answer exchanged there to be differing session intervals (or
   none at all) on differing dialogs established as a result of a session
   refresh request; if

S. Donovan et. Al.          Informational                           7 
   single INVITE. It also remembers whether it, or its peer, is the
   refresher on for the session.

   If the UAC must perform the refreshes, it has not changed, computes the session
   expiration for that MUST be indicated.

7.2 Processing a session. The session expiration is the time of
   reception of the last 2xx Response

   Session timer requires response to a session refresh request on
   that dialog plus the session interval for that session. If UA wishes
   to create and maintain state. This state
   includes continue with the session interval, beyond the session expiration, and the
   identity of it MUST
   generate a refresh before the refresher. This state session expiration. It is associated with the dialog
   on which RECOMMENDED
   that this refresh be sent once half the session interval has been negotiated.

   When lapsed.
   Additional procedures for this refresh are described in Section
   Section 10.

7.3 Processing a 2xx 422 Response

   If the response to a session refresh request arrives, it may or
   may not contain is a Require header field with the value "timer". If it
   does, 422 (Session
   Interval Too Small) response message, then the UAC MUST look for the Session-Expires header field to
   process MAY retry the response.

   If there was a Require header field
   request. The procedures for retrying are described in Section
   Section 7.1.  This new request constitutes a new transaction and
   SHOULD have the response with the same value
   "timer", of the Session-Expires header field will always be present.
   UACs MUST be prepared to receive a Session-Expires header field in Call-ID, To, and From of the
   previous request, but the CSeq should contain a
   response even if none were present in new sequence number
   that is one higher than the request. previous.

7.4 Generating Subsequent Session Refresh Requests

   The "refresher"
   parameter will be present values of Supported, Require and Proxy-Require used in the Session-Expires header field,
   indicating who will
   initial Session refresh request MUST be performing the refreshes. used.

   The UAC MUST set the
   identity of the refresher to the value of this parameter. 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 header field in insert the request), but there was no
   Require or Session-Expires Min-SE header field in the 2xx response. This
   will happen when the UAS doesn't support the into a session timer extension,
   and only refresh
   request for a particular dialog if it has ever received a 422
   response to a previous session refresh request on the UAC same dialog,
   or if it has asked for received a session timer (no proxies have
   requested it). In this case, refresh request on that dialog which
   contained a Min-SE header field. Similarly, if the no dialog has been
   established yet, a UAC still wishes to use MUST insert the
   session timer (they are purely for its benefit alone), Min-SE header field into an
   INVITE request if it has ever received a 422 response to
   perform them. To do this, the UAC follows a previous
   INVITE request with the procedures defined in
   this specification as if same Call-ID.

   The value of the Session-Expires Min-SE header field were present in a session refresh
   request MUST be the
   2xx response, and its largest value was the same as the one amongst all Min-SE header field
   values returned in all 422 responses, or received in session refresh
   requests, on the request,
   but with same dialog, if a refresher parameter of "uac". dialog has been established. If
   no dialog has been established, the 2xx response did not contain a Session-Expires Min-SE header field,
   there field value is no session expiration. In this case, no refreshes need set
   to be
   sent. A 2xx without a Session-Expires can come the largest value amongst all Min-SE header field values returned
   in all 422 responses for both initial an INVITE request with the same Call-ID. A
   result of this rule is that the maximum value of the Min-SE is
   effectively æclearedÆ once the dialog is established, and
   mid-dialog session refresh requests. This means from that
   point on, only the session
   timer can values from proxies known to be "turned-off" mid dialog by receiving a response without
   a Session-Expires header. on the proxy path
   will end up being used.

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

S. Donovan et. Al.          Informational                           8 
   In a session as refresh request sent within a dialog with an active
   session timer, the value of Sesssion-Expires header field SHOULD be present.
   When present, it MUST be equal to the delta-time from maximum of the Session-Expires Min-SE header
   field in (recall that its default value when not present is zero) and
   the current session interval.

   If the most
   recent 2xx response to a session refresh request on a dialog. It is
   explicitly allowed for there to be differing session intervals (or
   none at all) on differing dialogs established as a result of a single
   INVITE. It also remembers whether it, or its peer, not the initial one, it is
   RECOMMENDED that the refresher
   on for the session.

   If parameter be set to æuacÆ if the UAC must perform
   element sending the request is currently performing refreshes, it computes the session
   expiration for that session. The session expiration else
   æuasÆ if its peer is performing the time of
   reception of refreshes. This way, the last 2xx response role of
   refresher does not change on each refresh. However, if it wishes to
   explicitly change the roles, it MAY use a session refresh request on value of æuasÆ if it knows
   that dialog plus the other side supports session interval for that session. timer. It could know this by
   having received a request from its peer with a Supported header
   field containing the value ætimerÆ. If UA it wishes to continue with reselect the session beyond
   roles, it MAY omit the parameter.

   A re-INVITE generated to refresh the session expiration, it MUST
   generate is a normal re-INVITE,
   and an UPDATE generated to refresh before the a session expiration. It is a normal UPDATE. If
   a UAC knows that its peer supports the UPDATE method, it is
   RECOMMENDED that this refresh UPDATE be sent once half the session interval has elapsed.
   Additional procedures for this refresh are described in Section 10.

7.3 Processing used instead of a 422 Response

   If re-INVITE. A UA can
   make this determination if it has seen an Allow header field from
   its peer with the response to value æUPDATEÆ, or through a session refresh request mid-dialog OPTIONS
   request. It is a 422 (Session
   Interval Too Small) response message, then the UAC MAY retry RECOMMENDED that the
   request. The procedures for retrying are described in Section 7.1.
   This new UPDATE request constitutes not contain an
   offer [4], but a new transaction and re-INVITE SHOULD have contain one, even if the
   same value details
   of the Call-ID, To, and From session have not changed. In that case, the offer MUST
   indicate that it has not changed. In the case of SDP, this is
   accomplished by including the previous request, but same value for the CSeq should contain origin field as
   previous SDP messages to its peer.  The same is true for an answer
   exchanged as a new sequence number result of a session refresh request; if it has not
   changed, that is one higher than
   the previous.

8 MUST be indicated.

8. Proxy Behavior

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

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

8.1 Processing of Requests

   Processing of requests is identical for all session refresh
   requests.

   To request a session timer for a session, a proxy makes sure that a
   Session-Expires header field is present in a session refresh request
   for that session. A proxy MAY insert a Session-Expires header field

S. Donovan et. Al.          Informational                           9 
   in the request before forwarding it, if none was present in the
   request. This Session-Expires header field may contain any desired
   expiration time the proxy would like, but not with a duration lower
   than the value in the Min-SE header field in the request, if
   present. The proxy MUST NOT include a refresher parameter in the
   header field value.

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

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

   If the request doesn't indicate support for session timer, but the
   request contains a session interval that is too small, the proxy
   cannot usefully reject the request, as this would result in a call
   failure. Rather, the proxy SHOULD insert a Min-SE header field
   containing its minimum interval. If a Min-SE header field is already
   present, the proxy SHOULD increase (but MUST NOT decrease) the value
   to equal its minimum interval. The proxy MUST then increase the
   Session-Expires
   session-Expires header field value to be equal to the value in the
   Min-SE header field, as described above. A proxy MUST NOT insert a
   Min-SE header field, or modify the value of an existing header
   field, in a proxied request if that request contains a Supported
   header field with the value "timer". ætimerÆ. This is needed to protect
   against certain denial of service attacks, described in Section
   Section 11.

   Assuming the proxy has requested a session timer (and thus has
   possibly inserted the Session-Expires header field or reduced it),
   the proxy MUST remember that it is using a session timer, and also
   remember the value of the Session-Expires header field from the
   proxied request. This MUST be remembered for the duration of the
   transaction. The proxy MUST remember, for the duration of the
   transaction, whether the request contained the Supported header
   field with the value "timer". ætimerÆ.

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

8.2 Processing of Responses

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

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

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

   If the received response contains a Session-Expires header field, no
   modification of the response is needed.

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

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

S. Donovan et. Al.          Informational                          11 

8.3 Session Expiration

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

9

9. Proxy UAS Behavior
   The UAS must respond to a request for a session timer by the UAC or
   a proxy in the path of the request, or it may request that a session
   Timer be used itself.

   If an incoming request contains a Supported header field with a
   value ætimerÆ and a Session Expires header, the UAS MAY reject the
   INVITE request with a 422 (Session Interval Too Small) response if
   the session interval in the Session-Expires header field is smaller
   than the minimum interval defined by the UAS' local policy. When
   sending the 422 responses, the UAS MUST include a Min-SE header
   field with the value of its minimum interval.

   If the UAS receives a session refresh wishes to accept the request, it copies the processing value of that the
   Session-Expires header field from the request can logically be broken into two steps. In the first step, the 2xx response.
   The UAS acts as a "virtual proxy", and follows the rules specified in
   Section 8.1 as if response MAY reduce its value, but MUST NOT set it were to a proxy. This means that
   duration lower than the same session
   timer manipulations that a proxy can do, can also be done by a UAS.
   Specifically, this means that it can insert or reduce value in the session
   interval (but not below Min-SE header field value, in the
   request, if present),
   reject present. If the request with a 422, and insert/increase value of the Min-SE Session-Expires header
   field value, just as a proxy can. Of course, rather is greater than proxying or equal to the
   request, value in the "modified" request is passed into Min-SE header
   field (recall that the second step of
   processing, which we call default is zero when the "virtual UAS" processing. Viewing Min-SE header field
   is not present), the UAS as MUST NOT increase the concatenation value of a proxy and a UAS-specific processing
   component simplifies the specification Session-
   Expires header field. If the value of behavior and guarantees
   consistency. This separation the Session-Expires header
   field is for lower than the purposes value of defining
   behavior. It does not mandate that the implementation work this way.

   Once Min-SE header field (possibly
   because a proxy increased the request is received by value of the virtual UAS (assuming it is
   received; it may have been rejected with a 422 based on Min-SE header field),
   the rules in
   Section 8.1), virtual UAS processing begins. From this point forward, MUST increase the term "UAS" refers to value of the "virtual UAS". Session-Expires header field
   to make it equal to Min-SE header field value.

   If the incoming request contains a Supported header field with a
   value ætimerÆ but does not contain a Session-Expires header, the UAC
   indicated support for timers, but did not request one.  The UAS wishes to
   accept request, may
   request a session timer in the 2XX response by including a Session-
   Expires header.  The value MUST NOT be set it copies to a duration lower
   than the value of in the Session-Expires Min-SE header field from the request into the 2xx response. Of course, this request
   refers to the one received from in the "virtual proxy". request, if
   present.

   The UAS MUST set the value of the refresher parameter in the
   Session-Expires header field in the 2xx response. This value
   specifies who will perform refreshes for the dialog. The value is
   based on the value of this parameter in the request, and on whether
   the UAC supports the session timer extension. The UAC supports the
   extension if the "timer" ætimerÆ option tag was present in a Supported
   header field in the request. Table 2 1 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 it's disallowed by the protocol.

S. Donovan et. Al.          Informational                          12 
   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 2: UAS Behavior

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

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

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

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

S. Donovan et. Al.          Informational                          13 

10.

10 Performing Refreshes

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

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

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

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

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

11

11. Security Considerations

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

11.1

11.2 Inside Attacks

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

S. Donovan et. Al.          Informational                          14 
   First, consider the case of a rogue UAC that wishes to force a UAS
   to generate refreshes at a rapid rate. To do so, it inserts a Session-
   Expires
   Session-Expires header field into an INVITE with a low duration and
   a refresher parameter equal to uas. Assume it places a Supported
   header field into the request. Any proxy, or the UAS, which objects
   to this low timer will reject the request with a 422, therefore
   preventing the attack. If no Supported header field was present, the
   proxies will insert a Min-SE header field into the request before
   forwarding it. As a result, the UAS will not choose a session timer
   lower than the minimum acceptable one to all elements on the path.
   This too prevents the attack.

   Next, consider the case of a rogue UAS that wishes to force a UAC to
   generate refreshes at a rapid rate. In that case, the UAC has to
   support session timer. The initial INVITE arrives at the rogue UAS,
   which returns a 2xx with a very small session interval. The UAC uses
   this timer, and quickly sends a refresh. Section 7.1 requires the
   UAC to copy the current session interval into the Session-Expires
   header field in the request. This enables the proxies to see the
   current value. The proxies will reject this request, and provide a
   Min-SE with a higher minimum. The UAC will then use this higher
   minimum. Note, that if the proxies did not reject eject the request, but
   rather proxied the request with a Min-SE header field, an attack
   would still be possible. The UAS could discard this header field in
   a 2xx response, and force the UAC to continue to generate rapid
   requests.

   In a similar fashion, a rogue proxy cannot force either the UAC or
   UAS to generate refreshes unless the proxy remains on the signaling
   path, and sees every request and response.

11.2 Outside Attacks

   An element that can observe and modify a request or response in
   transit can force rapid session refreshes. To prevent that, requests
   and responses need to be protected by message integrity. Since the
   session timer headers are not end-to-end, and are manipulated by
   proxies, the SIP S/MIME capabilities are not suitable for this task.
   Rather, integrity needs to be protected using hop-by-hop mechanisms.
   As a result, it is RECOMMENDED that an element which that sends a request
   with a Session-Expires header field, or a Supported header field
   with the value "timer", ætimerÆ, do so using IPSec or TLS. Since adequate
   protection is obtained only if TLS or IPSec is applied on each hop,
   it is RECOMMENDED that the SIPS URI scheme be used in conjunction
   with this extension. This means that proxies which that record-route and
   request session timer, SHOULD record-route with a SIPS URI. A UA
   which
   that inserts a Session-Expires header into a request or response
   SHOULD include a Contact URI thats that is a SIPS URI.

12

12. IANA Considerations

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

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

   The following is the registration for the Min-SE header field:

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

        Header Name: Min-SE

        Compact Form: none

   The following is the registration for the Session-Expires header
   field:

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

        Header Name: Session-Expires

        Compact Form: x

12.2 IANA Registration of the 422 (Session Interval Too Small) Response
   Code
Code}

   The following is the registration for the 422 (Session Interval Too
   Small) response code:

        Response Code: 422

        Default Reason Phrase: Session Interval Too Small

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

12.3 IANA Registration of the "timer" ætimerÆ Option Tag Tag}

   The following is the registration for the "timer" ætimerÆ option tag:

        Name: timer

        Description: This option tag is for support of the session
        timer extension. Inclusion in a Supported header field in a
        request or response indicates that the UA is capable of
        performing refreshes according to that specification. Inclusion
        in a Require header in a request means that the UAS must
        understand the session timer extension to process the request.
        Inclusion in a Require header field in a response indicates

S. Donovan et. Al.          Informational                          16 
        that the UAC must look for the Session-
             Expires Session-Expires header field in
        the response, and process accordingly.

13

13. Example Call Flow

   Figure 1 gives an example of a call flow that makes use of the
   session timer. In this example, both the UAC and UAS support the
   session timer extension. The initial INVITE request generated by the
   UAC, Alice (message 1), might look like:

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

   (Alice's SDP not shown)

   This request indicates that Alice supports the session timer, and is
   request session refreshes every 50 seconds. This arrives at the
   first proxy, P1. This session interval is below the minimum allowed
   value of 3600. So, P1 rejects the request with a 422 (message 2):

   SIP/2.0 422 Session Interval Too Small
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
     ;received=192.0.2.1
   Min-SE: 3600
   To: Bob <sip:bob@biloxi.com>;tag=9a8kz
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE

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

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
   Supported: timer
   Session-Expires: 3600
   Min-SE: 3600
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.com>

S. Donovan et. Al.          Informational                          17 
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)

   Proxy P1 record-routes. Since the session interval is now acceptable
   to it, it forwards the request to P2 (message 5). However, the
   session interval is below its minimum configured amount of 4000. So,
   it rejects the request with a 422 response code (message 6), and
   includes a Min-SE header field with the value of 4000. Once more,
   Alice retries the INVITE. This time, the Min-SE header field in her
   INVITE is the maximum of all Min-SE she has received (3600 and
   4000). Message 10 might look like:

        Alice      Proxy P1     Proxy P2        Bob
          |(1) INVITE  |            |            |
          |SE: 50      |            |            |
          |----------->|            |            |
          |(2) 422     |            |            |
          |MSE: 3600   |            |            |
          |<-----------|            |            |
          |(3) ACK     |            |            |
          |----------->|            |            |
          |(4) INVITE  |            |            |
          |SE:3600     |            |            |
          |MSE:3600    |            |            |
          |----------->|            |            |
          |            |(5) INVITE  |            |
          |            |SE:3600     |            |
          |            |MSE:3600    |            |
          |            |----------->|            |
          |            |(6) 422     |            |
          |            |MSE:4000    |            |
          |            |<-----------|            |
          |            |(7) ACK     |            |
          |            |----------->|            |
          |(8) 422     |            |            |
          |MSE:4000    |            |            |
          |<-----------|            |            |
          |(9) ACK     |            |            |
          |----------->|            |            |
          |(10) INVITE |            |            |
          |SE:4000     |            |            |
          |MSE:4000    |            |            |
          |----------->|            |            |
          |            |(11) INVITE |            |
          |            |SE:4000     |            |
          |            |MSE:4000    |            |
          |            |----------->|            |
          |            |            |(12) INVITE |
          |            |            |SE:4000     |
          |            |            |MSE:4000    |
          |            |            |----------->|
          |            |            |(13) 200 OK |
          |            |            |SE:4000     |
          |            |            |<-----------|
          |            |(14) 200 OK |            |
          |            |SE:4000     |            |
          |            |<-----------|            |
          |(15) 200 OK |            |            |
          |SE:4000     |            |            |
          |<-----------|            |            |
          |(16) ACK    |            |            |
          |----------->|            |            |
          |            |(17) ACK    |            |
          |            |------------------------>|
          |(18) UPDATE |            |            |
          |SE:4000     |            |            |
          |----------->|            |            |
          |            |(19) UPDATE |            |
          |            |SE:4000     |            |
          |            |------------------------>|
          |            |(20) 200 OK |            |
          |            |SE:4000     |            |
          |            |<------------------------|
          |(21) 200 OK |            |            |
          |SE:4000     |            |            |
          |<-----------|            |            |
          |            |(22) BYE    |            |
          |            |<------------------------|
          |(23) BYE    |            |            |
          |<-----------|            |            |
          |            |(24) 408    |            |
          |            |------------------------>|

   Figure 1: Example Session Timer Flow

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

   (Alice's SDP not shown)

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

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
    ;received=192.0.2.1
   Require: timer
   Supported: timer
   Record-Route: sip:p1.atlanta.com;lr
   Session-Expires: 4000;refresher=uac
   To: Bob <sip:bob@biloxi.com>;tag=9as888nd
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE

S. Donovan et. Al.          Informational                          18 
   Contact: <sip:bob@192.0.2.4>
   Content-Type: application/sdp
   Content-Length: 142

   (Bob's SDP not shown)

   Alice generates an ACK (message 16), which is routed through P1 and
   then to Bob. Since Alice is the refresher, around 3000 seconds
   later, Alice sends an UPDATE request to refresh the session. Since
   this request is part of an established dialog, and Alice has not
   received any 422 responses or requests on that dialog, there is no
   Min-SE header field in her request (message 18):

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

   This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
   the Session-Expires header field into the response. This is
   forwarded through P1, and arrives at Alice. The response she
   receives (message 21) might look like:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds12
     ;received=192.0.2.1
   Require: timer
   Session-Expires: 4000;refresher=uac
   To: Bob <sip:bob@biloxi.com>;tag=9as888nd
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314162 UPDATE
   Contact: <sip:bob@192.0.2.4>

   Shortly afterwards, Alice's UA crashes. As a result, she never sends
   an session refresh request. 3990 seconds later, Bob gives up, and
   sends a BYE request (message 22). This is sent to P1. P1 attempts to
   deliver it, but fails (since Alice's UA has crashed). P1 then
   returns a 408 (Request Timeout) to Bob.

14

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

15  Brian Rosen completed the editing of this latest draft.

15. Author's Addresses

S. Donovan et. Al.          Informational                          19 
   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

16

16. Normative References

   [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
   Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force,
   June 2002.

   [2] J. Rosenberg, "The session initiation protocol (SIP) UPDATE
   method," RFC 3311, Internet Engineering Task Force, Oct. 2002.

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

   [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
   session description protocol (SDP)," RFC 3264, Internet Engineering
   Task Force, June 2002.

17

17. Informative References

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

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

   [7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
   responses in session initiation protocol (SIP)," RFC 3262, Internet
   Engineering Task Force, June 2002.

   [8] A. B. Roach, "Session initiation protocol (sip)-specific event
   notification," RFC 3265, Internet Engineering Task Force, June 2002.

S. Donovan et. Al.          Informational                          20 

Full Copyright Statement

   Copyright (c)

   "Copyright (C) The Internet Society (2002). (date). 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.

S. Donovan et. Al.          Informational                          21