rfc4028.htm

RFC4028,session timer的标准文档

   This refresh mechanism has additional applications.  A user agent
   would like to determine whether the session is still active for the
   same reasons a call stateful proxy server would.  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 [<A title='"RTP: A Transport Protocol for Real-Time Applications"' href="#ref-5">5</A>].  However, it is desirable to separate indications of
   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)
   [<A title='"IP Network Address Translator (NAT) Terminology and Considerations"' href="#ref-6">6</A>].  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 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 backward compatible with SIP that it works as long as
   either one of the two participants in a dialog understands 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.

<SPAN class=h2><A name=section-2>2</A>.  Terminology</SPAN>

   In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
   'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
   and 'OPTIONAL' are to be interpreted as described in <A href="./rfc2119">RFC 2119</A> [<A title='"Key words for use in RFCs to Indicate Requirement Levels"' href="#ref-1">1</A>] and
   indicate requirement levels for compliant SIP implementations.







<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                     [Page 3]</SPAN>
<A class=invisible id=page-4 href="#page-4" name=page-4><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   Additionally, we define the following terms:

   Session Interval: The maximum 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, which is 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 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 processed
      according to the rules of this specification.  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 <A href="#section-6">Section 6</A> of [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>], which is a
      request that can update the remote target of a dialog.

   Initial Session Refresh Request: The first session refresh request
      sent with a particular Call-ID value.

   Subsequent Session Refresh Request: Any session refresh request sent
      with a particular Call-ID after the initial session refresh
      request.

   Refresh: Same as a session refresh request.

<SPAN class=h2><A name=section-3>3</A>.  Overview of Operation</SPAN>

   This section provides a brief overview of the operation of the
   extension.  It is tutorial in nature and should not be considered
   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 (the UAC does or doesn't support it, and the
   UAS does or doesn't support it).  For simplicity's sake, this section




<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                     [Page 4]</SPAN>
<A class=invisible id=page-5 href="#page-5" name=page-5><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   will describe basic operation in the case where both sides support
   the extension.

   A UAC starts by sending an INVITE.  This includes a Supported header
   field with the option tag 'timer', indicating support for this
   extension.

   This request passes through proxies, any one of which may have an
   interest in establishing a session timer.  Each proxy can insert a
   Session-Expires header field and a Min-SE header field into the
   request (if none is already there) or alter the value of existing
   Session-Expires and Min-SE header fields as described below.

   The Min-SE header field establishes the lower bound for the session
   refresh interval; i.e., the fastest rate any proxy servicing this
   request will be allowed to require.  The purpose of this header field
   is to prevent hostile proxies from setting arbitrarily short refresh
   intervals so that their neighbors are overloaded.  Each proxy
   processing the request can raise this lower bound (increase the
   period between refreshes) but is not allowed to lower it.

   The Session-Expires header field establishes the upper bound for the
   session refresh interval; i.e., the time period after processing a
   request for which any session-stateful proxy must retain its state
   for this session.  Any proxy servicing this request can lower this
   value, but it is not allowed to decrease it below the value specified
   in the Min-SE header field.

   If the Session-Expires interval is too low for a proxy (i.e., lower
   than the value of Min-SE that the proxy would wish to assert), the
   proxy rejects the request with a 422 response.  That response
   contains a 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 field in the request.  The header field
   contains the largest Min-SE header field it observed in all 422
   responses previously received.  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 were a proxy; 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' 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 can observe
   the final session interval but can't change it.




<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                     [Page 5]</SPAN>
<A class=invisible id=page-6 href="#page-6" name=page-6><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   From the Session-Expires header field in the response, both UAs know
   that a session timer is active, when it will expire, and 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 [<A title='"The Session Initiation Protocol (SIP) UPDATE Method"' href="#ref-3">3</A>] 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 UAs supports it.  One
   such complication is that a proxy may need to insert the
   Session-Expires header field 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.

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

<SPAN class=h2><A name=section-4>4</A>.  Session-Expires Header Field Definition</SPAN>

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

   The absolute minimum for the Session-Expires header field is 90
   seconds.  This value represents a bit more than twice the duration
   that a SIP transaction can take in the event of a timeout.  This
   allows sufficient time for a UA to attempt a refresh at the halfpoint
   of the session interval, and for that transaction to complete
   normally before the session expires.  However, 1800 seconds (30
   minutes) is RECOMMENDED as the value for the Session-Expires header
   field.  In other words, SIP entities MUST be prepared to handle
   Session-Expires header field values of any duration greater than 90
   seconds, but entities that insert the Session-Expires header field
   SHOULD NOT choose values of less than 30 minutes.






<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                     [Page 6]</SPAN>
<A class=invisible id=page-7 href="#page-7" name=page-7><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   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' that 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 because 95% of phone
   calls are shorter than this duration.  However, the 30 minute minimum
   is listed as a SHOULD, and not as 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 is undefined.
   This means that the absence of the Session-Expires header field
   implies no expiration of the session, using the mechanism defined in
   this specification.  Note that other mechanisms not defined in this
   specification, such as locally configured timers, may apply.

   The syntax of the Session-Expires header field is as follows:

   Session-Expires  = ("Session-Expires" / "x") HCOLON delta-seconds
                        *(SEMI se-params)
   se-params        = refresher-param / generic-param
   refresher-param  = "refresher" EQUAL  ("uas" / "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 <A href="./rfc3261#section-25">Section&nbsp;25 of RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>].