rfc4028.htm

RFC4028,session timer的标准文档

   In a session refresh request sent within a dialog with an active
   session timer, the Session-Expires header field SHOULD be present.
   When present, it SHOULD be equal to the maximum of the Min-SE header
   field (recall that its default value when not present is 90 seconds)
   and the current session interval.  Inclusion of the Session-Expires
   header field with this value avoids certain denial-of-service
   attacks, as documented in <A href="#section-11">Section 11</A>.  As such, a UA should only
   ignore the SHOULD in unusual and singular cases where it is desirable
   to change the session interval mid-dialog.

   If the session refresh request is not the initial one, it is
   RECOMMENDED that the refresher parameter be set to 'uac' if the
   element sending the request is currently performing refreshes, and to
   'uas' if its peer is performing the refreshes.  This way, the role of
   refresher does not change on each refresh.  However, if it wishes to
   explicitly change the roles, it MAY use a value of 'uas' if it knows
   that the other side supports the session timer.  It could know this
   by having received a request from its peer with a Supported header
   field containing the value 'timer'.  If it seeks to reselect the
   roles, it MAY omit the parameter.

   A re-INVITE generated to refresh 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 the UPDATE method, it is
   RECOMMENDED that UPDATE be used instead of a re-INVITE.  A UA can
   make this determination if it has seen an Allow header field from its
   peer with the value 'UPDATE', or through a mid-dialog OPTIONS
   request.  It is RECOMMENDED that the UPDATE request not contain an
   offer [<A title='"An Offer/Answer Model with Session Description Protocol (SDP)"' href="#ref-4">4</A>], but a re-INVITE SHOULD contain one, even if the details of
   the 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 same value for the origin field as did previous SDP
   messages to its peer.  The same is true for an answer exchanged as a
   result of a session refresh request; if it has not changed, that MUST
   be indicated.

<SPAN class=h2><A name=section-8>8</A>.  Proxy Behavior</SPAN>

   Session timers are mostly of interest to call stateful proxy servers
   (that is, to servers that maintain the state of calls and dialogs
   established through them).  However, a stateful proxy server (that
   is, a server which is aware of transaction state but does not retain
   call or dialog state) MAY also follow the rules described here.
   Stateless proxies MUST NOT attempt to request session timers.
   Proxies that ask for session timers SHOULD record-route, as they
   won't receive refreshes if they don't.





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


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

<SPAN class=h3><A name=section-8.1>8.1</A>.  Processing of Requests</SPAN>

   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
   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 it is
   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
   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 it is 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 90 seconds 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' parameter in the
   Session-Expires header field.

   If the request contains a Supported header field with a value
   'timer', the proxy 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 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.  That minimum MUST NOT be lower than 90 seconds.

   If the request doesn't indicate support for the session timer but
   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 its
   minimum interval.  The proxy MUST then increase the Session-Expires



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


   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'.  This is needed to protect against certain denial of
   service attacks, described in <A href="#section-11">Section 11</A>.

   Assuming that 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'.  If the request did not contain a Supported header field
   with the value 'timer', the proxy MAY insert a Require header field
   with the value 'timer' into the request.  However, this is NOT
   RECOMMENDED.  This allows the proxy to insist on a 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 would already be
   sure the session timer can be used for the session.

<SPAN class=h3><A name=section-8.2>8.2</A>.  Processing of Responses</SPAN>

   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 the 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 the session timer, additional processing is
   needed.

   Because there is no Session-Expires or Require header field in the
   response, the proxy knows that 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' parameter to 'uac'.  The proxy MUST add the 'timer'





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


   option tag to any Require header field in the response, and if none
   was present, add the Require header field with that value 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.

<SPAN class=h3><A name=section-8.3>8.3</A>.  Session Expiration</SPAN>

   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.

<SPAN class=h2><A name=section-9>9</A>.  UAS Behavior</SPAN>

   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 field, 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 response, the UAS MUST include a Min-SE header field
   with the value of its minimum interval.  This minimum interval MUST
   NOT be lower than 90 seconds.

   If the UAS wishes to accept the request, it copies the value of the
   Session-Expires header field from the request into the 2xx response.



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


   The UAS response 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 it is present; otherwise the UAS MAY reduce its value but
   MUST NOT set it to a duration lower than 90 seconds.  The UAS MUST
   NOT increase the value of the Session-Expires header field.

   If the incoming request contains a Supported header field with a
   value 'timer' but does not contain a Session-Expires header, it means
   that the UAS is indicating support for timers but is not requesting
   one.  The UAS may request a session timer in the 2XX response by
   including a Session-Expires header field.  The value MUST NOT be set
   to a duration lower than the value in the Min-SE header field in the
   request, if it is 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' option tag was present in a Supported header
   field in the request.  Table 2 defines how the value in the response