summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4028.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4028.txt')
-rw-r--r--doc/rfc/rfc4028.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc4028.txt b/doc/rfc/rfc4028.txt
new file mode 100644
index 0000000..ecec689
--- /dev/null
+++ b/doc/rfc/rfc4028.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group S. Donovan
+Request for Comments: 4028 J. Rosenberg
+Category: Standards Track Cisco Systems
+ April 2005
+
+
+ Session Timers in the Session Initiation Protocol (SIP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+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 whether the SIP session is still
+ active. The extension defines two new header fields:
+ Session-Expires, which conveys the lifetime of the session, and
+ Min-SE, which conveys the minimum allowed value for the session
+ timer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 1]
+
+RFC 4028 Session Timer April 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
+ 4. Session-Expires Header Field Definition . . . . . . . . . . 6
+ 5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
+ 6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
+ 7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7.1. Generating an Initial Session Refresh Request . . . . 9
+ 7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
+ 7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
+ 7.4. Generating Subsequent Session Refresh Requests . . . . 11
+ 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
+ 8.2. Processing of Responses . . . . . . . . . . . . . . . 14
+ 8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
+ 9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . 18
+ 11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
+ 11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
+ 12.1. IANA Registration of Min-SE and Session-Expires
+ Header Fields . . . . . . . . . . . . . . . . . . . . 19
+ 12.2. IANA Registration of the 422 (Session Interval Too
+ Small) Response Code . . . . . . . . . . . . . . . . . 20
+ 12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
+ 13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
+ 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
+ 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 15.1. Normative References . . . . . . . . . . . . . . . . . 25
+ 15.2. Informative References . . . . . . . . . . . . . . . . 26
+ Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
+ Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
+
+1. Introduction
+
+ The Session Initiation Protocol (SIP) [2] does not define a keepalive
+ mechanism for the sessions it establishes. Although the user agents
+ may be able to determine whether the session has timed out by 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. For instance, when a
+ user agent fails to send a BYE message at the end of a session, or
+ when 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
+
+
+
+Donovan & Rosenberg Standards Track [Page 2]
+
+RFC 4028 Session Timer April 2005
+
+
+ has no method to determine when the call state information no longer
+ applies.
+
+ To resolve this problem, this extension defines a keepalive mechanism
+ for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] 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. 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 [5]. 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)
+ [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 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.
+
+2. Terminology
+
+ 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 RFC 2119 [1] and
+ indicate requirement levels for compliant SIP implementations.
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 3]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 Section 6 of [2], 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.
+
+3. Overview of Operation
+
+ 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
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 4]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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.
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 5]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 [3] 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.
+
+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, 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.
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 6]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 Section 25 of RFC 3261 [2].
+
+ Table 1 is an extension of Tables 2 and 3 in [2] for the
+ Session-Expires and Min-SE header fields. The column 'PRA' is for
+ the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is
+ for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 7]
+
+RFC 4028 Session Timer April 2005
+
+
+ +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
+ | 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
+
+5. Min-SE Header Field Definition
+
+ 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)
+
+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 below the
+ minimum timer for the server. The 422 response MUST contain a Min-SE
+ header field with the minimum timer for that server.
+
+
+
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 8]
+
+RFC 4028 Session Timer April 2005
+
+
+7. UAC Behavior
+
+7.1. Generating an Initial Session Refresh Request
+
+ 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' [2]. 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.
+
+7.2. Processing a 2xx Response
+
+ 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.
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 9]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 10]
+
+RFC 4028 Session Timer April 2005
+
+
+ RECOMMENDED that this refresh be sent once half the session interval
+ has elapsed. Additional procedures for this refresh are described in
+ Section 10.
+
+ 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.
+
+7.3. Processing a 422 Response
+
+ 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 Section 7.4.
+ 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.
+
+7.4. Generating Subsequent Session Refresh Requests
+
+ 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.
+
+
+
+Donovan & Rosenberg Standards Track [Page 11]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 Section 11. 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 [4], 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.
+
+8. Proxy Behavior
+
+ 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.
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 12]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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
+ 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
+
+
+
+Donovan & Rosenberg Standards Track [Page 13]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 Section 11.
+
+ 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.
+
+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 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'
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 14]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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.
+
+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. 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 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.
+
+
+
+Donovan & Rosenberg Standards Track [Page 15]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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
+ 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
+ is disallowed by the protocol.
+
+ 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 where 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, the UAS cannot override 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', the UAS MUST place a Require
+ header field into the response with the value 'timer'. This is
+
+
+
+Donovan & Rosenberg Standards Track [Page 16]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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' and the Supported header field
+ in the request contained the value 'timer', the UAS SHOULD place a
+ Require header field into the response with the value '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 sending a BYE, insertion of the Require is a
+ SHOULD here, and not a MUST.
+
+ Just like the UAC, the UAS 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 dialog,
+ 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 have 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 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 have to send 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 the session refresh request transaction times out or generates a
+ 408 or 481 response, then the UAC sends a BYE request as per Section
+ 12.2.1.2 of RFC 3261 [2]. If the session refresh request does not
+ generate a 2xx response (and, as a result, the session is not
+ refreshed), and a response other than 408 or 481 is received, the UAC
+
+
+
+Donovan & Rosenberg Standards Track [Page 17]
+
+RFC 4028 Session Timer April 2005
+
+
+ SHOULD follow the rules specific to that response code and retry if
+ possible. For example, if the response is a 401, the UAC would retry
+ the request with new credentials. However, the UAC SHOULD NOT
+ continuously retry the request if the server indicates the same error
+ response.
+
+ Similarly, if the side not performing refreshes does not receive a
+ session refresh request before the session expiration, it SHOULD send
+ a BYE to terminate the session, slightly before the session
+ expiration. The minimum of 32 seconds and one third of 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. This is
+ why the BYE should be sent before the expiration.
+
+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' (elements that attempt to modify
+ messages in transit) or by 'insiders' (elements that are legitimately
+ in the request path but are intent on doing harm). Fortunately, both
+ cases are adequately handled by this specification.
+
+11.1. 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.
+
+ 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 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. The UAS or any proxy that objects to
+ this low timer will reject the request with a 422, thereby 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 allowed by 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,
+
+
+
+Donovan & Rosenberg Standards Track [Page 18]
+
+RFC 4028 Session Timer April 2005
+
+
+ which returns a 2xx with a very small session interval. The UAC uses
+ this timer and quickly sends a refresh. Section 7.4 requires that
+ the UAC 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, which the UAC will then use. Note,
+ that if the proxies did not reject 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 this, requests
+ and responses have to be protected by message integrity. Since the
+ session timer header fields are not end-to-end and are manipulated by
+ proxies, the SIP S/MIME capabilities are not suitable for this task.
+ Rather, integrity has to be protected by using hop-by-hop mechanisms.
+ As a result, it is RECOMMENDED that an element send a request with a
+ Session-Expires header field or a Supported header field with the
+ value 'timer' by using TLS. As adequate protection is obtained only
+ if security is applied on each hop, it is RECOMMENDED that the SIPS
+ URI scheme be used in conjunction with this extension. This means
+ that proxies that record-route and request session timer SHOULD
+ record-route with a SIPS URI. A UA that inserts a Session-Expires
+ header into a request or response SHOULD include a Contact URI that
+ is a SIPS URI.
+
+12. IANA Considerations
+
+ This extension defines two new header fields, a new response code,
+ and a new option tag. SIP [2] 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 4028
+ Header Name: Min-SE
+ Compact Form: none
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 19]
+
+RFC 4028 Session Timer April 2005
+
+
+ The following is the registration for the Session-Expires header
+ field:
+
+ RFC Number: RFC 4028
+ Header Name: Session-Expires
+ Compact Form: x
+
+12.2. IANA Registration of the 422 (Session Interval Too Small)
+ Response 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 4028
+
+12.3. IANA Registration of the 'timer' Option Tag
+
+ The following is the registration for the '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 can perform 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 that the UAC must look for the Session-Expires
+ header field in the response and process it accordingly.
+
+13. Example Call Flow
+
+ Example Session Timer Flow
+
+ Alice Proxy P1 Proxy P2 Bob
+ |(1) INVITE | | |
+ |SE: 50 | | |
+ |----------->| | |
+ |(2) 422 | | |
+ |MSE: 3600 | | |
+ |<-----------| | |
+ |(3) ACK | | |
+ |----------->| | |
+ |(4) INVITE | | |
+ |SE:3600 | | |
+ |MSE:3600 | | |
+ |----------->| | |
+
+
+
+Donovan & Rosenberg Standards Track [Page 20]
+
+RFC 4028 Session Timer April 2005
+
+
+ | |(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 | |
+ | |<------------------------|
+
+
+
+Donovan & Rosenberg Standards Track [Page 21]
+
+RFC 4028 Session Timer April 2005
+
+
+ |(21) 200 OK | | |
+ |SE:4000 | | |
+ |<-----------| | |
+ | |(22) BYE | |
+ | |<------------------------|
+ |(23) BYE | | |
+ |<-----------| | |
+ | |(24) 408 | |
+ | |------------------------>|
+
+ Figure 1: Example Session Timer 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 this:
+
+ INVITE sips:bob@biloxi.example.com SIP/2.0
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
+ Supported: timer
+ Session-Expires: 50
+ Max-Forwards: 70
+ To: Bob <sips:bob@biloxi.example.com>
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+ Contact: <sips:alice@pc33.atlanta.example.com>
+ Content-Type: application/sdp
+ Content-Length: 142
+
+ (Alice's SDP not shown)
+
+ This request indicates that Alice supports the session timer, and is
+ requesting 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/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+ Min-SE: 3600
+ To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 22]
+
+RFC 4028 Session Timer April 2005
+
+
+ This response contains a Min-SE header field with the value 3600.
+ Alice then retries the request. This time, the request contains a
+ Min-SE header, as Alice has received a 422 for other INVITE requests
+ with the same Call-ID. The new request (message 4) might look like
+ this:
+
+ INVITE sips:bob@biloxi.example.com SIP/2.0
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
+ Supported: timer
+ Session-Expires: 3600
+ Min-SE: 3600
+ Max-Forwards: 70
+ To: Bob <sips:bob@biloxi.example.com>
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314160 INVITE
+ Contact: <sips:alice@pc33.atlanta.example.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 this:
+
+ INVITE sips:bob@biloxi.example.com SIP/2.0
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
+ Supported: timer
+ Session-Expires: 4000
+ Min-SE: 4000
+ Max-Forwards: 70
+ To: Bob <sips:bob@biloxi.example.com>
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314161 INVITE
+ Contact: <sips:alice@pc33.atlanta.example.com>
+ Content-Type: application/sdp
+ Content-Length: 142
+
+ (Alice's SDP not shown)
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 23]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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'. This 200 OK is
+ forwarded back to Alice. The response she receives (message 15)
+ might look like this:
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
+ ;received=192.0.2.1
+ Require: timer
+ Supported: timer
+ Record-Route: sips:p1.atlanta.example.com;lr
+ Session-Expires: 4000;refresher=uac
+ To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314161 INVITE
+ Contact: <sips: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 2000 seconds later
+ Alice sends an UPDATE request to refresh the session. Because 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 sips:bob@192.0.2.4 SIP/2.0
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
+ Route: sips:p1.atlanta.example.com;lr
+ Supported: timer
+ Session-Expires: 4000;refresher=uac
+ Max-Forwards: 70
+ To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314162 UPDATE
+ Contact: <sips:alice@pc33.atlanta.example.com>
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 24]
+
+RFC 4028 Session Timer April 2005
+
+
+ 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 this:
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
+ ;received=192.0.2.1
+ Require: timer
+ Session-Expires: 4000;refresher=uac
+ To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
+ From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314162 UPDATE
+ Contact: <sips:bob@192.0.2.4>
+
+ Shortly afterward, Alice's UA crashes. As a result, she never sends
+ a session refresh request. 3968 seconds later, Bob times out and
+ sends a BYE request (message 22). This is sent to P1. P1 attempts
+ to deliver it but fails (because Alice's UA has crashed). P1 then
+ returns a 408 (Request Timeout) to Bob.
+
+14. Acknowledgements
+
+ The authors wish to thank Brett Tate for his contributions to this
+ work. Brian Rosen completed the editing of the document.
+
+15. References
+
+15.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+ Method", RFC 3311, October 2002.
+
+ [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 25]
+
+RFC 4028 Session Timer April 2005
+
+
+15.2. Informative References
+
+ [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+ [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
+ (NAT) Terminology and Considerations", RFC 2663, August 1999.
+
+ [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+ Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+ 2002.
+
+ [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
+ Notification", RFC 3265, June 2002.
+
+Authors' Addresses
+
+ Steve Donovan
+ Cisco Systems, Inc.
+ 2200 E. President George Bush Turnpike
+ Richardson, Texas 75082
+ US
+
+ EMail: srd@cisco.com
+
+
+ Jonathan Rosenberg
+ Cisco Systems, Inc.
+ 600 Lanidex Plaza
+ Parsippany, NJ 07054
+ US
+
+ EMail: jdrosen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 26]
+
+RFC 4028 Session Timer April 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Donovan & Rosenberg Standards Track [Page 27]
+