rfc4028.htm

RFC4028,session timer的标准文档

   Table 1 is an extension of Tables 2 and 3 in [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>] for the
   Session-Expires and Min-SE header fields.  The column 'PRA' is for
   the PRACK method [<A title='"Reliability of Provisional Responses in Session Initiation Protocol (SIP)"' href="#ref-7">7</A>], 'UPD' is for the UPDATE method [<A title='"The Session Initiation Protocol (SIP) UPDATE Method"' href="#ref-3">3</A>], 'SUB' is
   for the SUBSCRIBE method [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="#ref-8">8</A>], and 'NOT' is for the NOTIFY method [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="#ref-8">8</A>].













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


   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
   |     Header    |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:  Session-Expires and Min-SE Header Fields

<SPAN class=h2><A name=section-5>5</A>.  Min-SE Header Field Definition</SPAN>

   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 that can be used for that session.  When present in a
   request or response, its value MUST NOT be less than 90 seconds.

   When the header field is not present, its default value for is 90
   seconds.

   The Min-SE header field MUST NOT be used in responses except for
   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 as follows:

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

<SPAN class=h2><A name=section-6>6</A>.  422 Response Code Definition</SPAN>

   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 below the
   minimum timer for the server.  The 422 response MUST contain a Min-SE
   header field with the minimum timer for that server.











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


<SPAN class=h2><A name=section-7>7</A>.  UAC Behavior</SPAN>

<SPAN class=h3><A name=section-7.1>7.1</A>.  Generating an Initial Session Refresh Request</SPAN>

   A UAC that supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag 'timer' [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>].  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' 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, only 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' to
   indicate that proxies must support the 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' MUST still
   be included, even if the Require or Proxy-Require header fields are
   present containing 'timer'.

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

   A UAC MAY include a Session-Expires header field in an initial
   session refresh request if it wants a session timer applied to the
   session.  The value of this header field indicates the session
   interval desired by the UAC.  If a Min-SE header is included in the
   initial session refresh request, the value of the Session-Expires
   MUST be greater than or equal to the value in Min-SE.

   The UAC MAY include the refresher parameter with value 'uac' if it
   wants to perform the refreshes.  However, it is RECOMMENDED that the
   parameter be omitted so that it can be selected by the negotiation
   mechanisms described below.

<SPAN class=h3><A name=section-7.2>7.2</A>.  Processing a 2xx Response</SPAN>

   The session timer requires a UA to create and maintain state.  This
   state includes the session interval, the session expiration, and the
   identity of the refresher.  This state is associated with the dialog
   on which the session has been negotiated.







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


   When a 2xx response to a session refresh request arrives, it may or
   may not contain a Require header field with the value 'timer'.  If it
   does, the UAC MUST look for the Session-Expires header field to
   process the response.

   If there was a Require header field in the response with the value
   'timer', the Session-Expires header field will always be present.
   UACs MUST be prepared to receive a Session-Expires header field in a
   response, even if none were present in the request.  The 'refresher'
   parameter will be present in the Session-Expires header field,
   indicating who will perform the refreshes.  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 the session timer (and thus included
   a Session-Expires header field in the request) and that there was no
   Require or Session-Expires header field in the 2xx response.  This
   will happen when the UAS doesn't support the session timer extension
   and only the UAC has asked for a session timer (no proxies have
   requested it).  In this case, if the UAC still wishes to use the
   session timer (which is purely for its benefit alone), it has to
   perform them.  To do this, the UAC follows the procedures defined in
   this specification as if the Session-Expires header field were in the
   2xx response, and its value was the same as that in the request, but
   with a refresher parameter of 'uac'.

   If the 2xx response did not contain a Session-Expires header field,
   there is no session expiration.  In this case, no refreshes need to
   be sent.  A 2xx without a Session-Expires can come for both initial
   and subsequent session refresh requests.  This means that the session
   timer can be 'turned-off' in mid dialog by receiving a response
   without a Session-Expires header field.

   The UAC remembers the session interval for a session as the value of
   the delta-time from the Session-Expires header field in 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.  The UAC also remembers whether it or its peer is the
   refresher on for the session.

   If the UAC must perform the refreshes, it computes the session
   expiration for that session.  The session expiration is the time of
   reception of the last 2xx response to a session refresh request on
   that dialog plus the session interval for that session.  If the UA
   seeks to continue with the session beyond the session expiration, it
   MUST generate a refresh before the session expiration.  It is





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


   RECOMMENDED that this refresh be sent once half the session interval
   has elapsed.  Additional procedures for this refresh are described in
   <A href="#section-10">Section 10</A>.

   Similarly, a re-INVITE or UPDATE request sent within a dialog for
   purposes other than session refreshes will also have the effect of
   refreshing the session, and its processing will follow the procedures
   defined in this specification.

<SPAN class=h3><A name=section-7.3>7.3</A>.  Processing a 422 Response</SPAN>

   If the response to a session refresh request is a 422 (Session
   Interval Too Small) response message, then the UAC MAY retry the
   request.  The procedures for retrying are described in <A href="#section-7.4">Section 7.4</A>.
   This new request constitutes a new transaction and SHOULD have the
   same value as the Call-ID, To, and From of the previous request, but
   the CSeq should contain a new sequence number that is one higher than
   the previous.

<SPAN class=h3><A name=section-7.4>7.4</A>.  Generating Subsequent Session Refresh Requests</SPAN>

   The values of Supported, Require, and Proxy-Require used in the
   initial Session refresh request MUST be used.

   The UAC MUST insert the Min-SE header field into a session refresh
   request for a particular dialog if it has ever received a 422
   response to a previous session refresh request on the same dialog, or
   if it has received a session refresh request on that dialog that
   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 to a previous
   INVITE request with the same Call-ID.

   The value of the Min-SE header field present in a session refresh
   request MUST be the largest value among all Min-SE header field
   values returned in all 422 responses or received in session refresh
   requests, on the same dialog, if a dialog has been established.  If
   no dialog has been established, the Min-SE header field value is set
   to the largest value among 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 the maximum value of the Min-SE is
   effectively 'cleared' once the dialog is established, and from that
   point on, only the values from proxies known to be on the proxy path
   will end up being used.

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



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