draft-ietf-sip-session-timer-14.txt   draft-ietf-sip-session-timer-15.txt 
SIP S. Donovan SIP S. Donovan
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: August 13, 2004 dynamicsoft Expires: January 16, 2005 dynamicsoft
February 13, 2004 July 18, 2004
Session Timers in the Session Initiation Protocol (SIP) Session Timers in the Session Initiation Protocol (SIP)
draft-ietf-sip-session-timer-14 draft-ietf-sip-session-timer-15
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2004. This Internet-Draft will expire on January 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines an extension to the Session Initiation Protocol This document defines an extension to the Session Initiation Protocol
(SIP). This extension allows for a periodic refresh of SIP sessions (SIP). This extension allows for a periodic refresh of SIP sessions
through a re-INVITE or UPDATE request. The refresh allows both user through a re-INVITE or UPDATE request. The refresh allows both user
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6
4. Session-Expires Header Field Definition . . . . . . . . . . 8 4. Session-Expires Header Field Definition . . . . . . . . . . 8
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 10 5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 10
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 11 6. 422 Response Code Definition . . . . . . . . . . . . . . . . 11
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Generating an Initial Session Refresh Request . . . . . . . 12 7.1 Generating an Initial Session Refresh Request . . . . . . 12
7.2 Processing a 2xx Response . . . . . . . . . . . . . . . . . 12 7.2 Processing a 2xx Response . . . . . . . . . . . . . . . . 12
7.3 Processing a 422 Response . . . . . . . . . . . . . . . . . 14 7.3 Processing a 422 Response . . . . . . . . . . . . . . . . 14
7.4 Generating Subsequent Session Refresh Requests . . . . . . . 14 7.4 Generating Subsequent Session Refresh Requests . . . . . . 14
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 16 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Processing of Requests . . . . . . . . . . . . . . . . . . . 16 8.1 Processing of Requests . . . . . . . . . . . . . . . . . . 16
8.2 Processing of Responses . . . . . . . . . . . . . . . . . . 17 8.2 Processing of Responses . . . . . . . . . . . . . . . . . 17
8.3 Session Expiration . . . . . . . . . . . . . . . . . . . . . 18 8.3 Session Expiration . . . . . . . . . . . . . . . . . . . . 18
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19 9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 22 10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . 23
11.1 Inside Attacks . . . . . . . . . . . . . . . . . . . . . . . 23 11.1 Inside Attacks . . . . . . . . . . . . . . . . . . . . . 23
11.2 Outside Attacks . . . . . . . . . . . . . . . . . . . . . . 24 11.2 Outside Attacks . . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
12.1 IANA Registration of Min-SE and Session-Expires Header 12.1 IANA Registration of Min-SE and Session-Expires
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Header Fields . . . . . . . . . . . . . . . . . . . . . 25
12.2 IANA Registration of the 422 (Session Interval Too Small) 12.2 IANA Registration of the 422 (Session Interval Too
Response Code . . . . . . . . . . . . . . . . . . . . . . . 25 Small) Response Code . . . . . . . . . . . . . . . . . . 25
12.3 IANA Registration of the 'timer' Option Tag . . . . . . . . 25 12.3 IANA Registration of the 'timer' Option Tag . . . . . . 25
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 27 13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
Normative References . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
Informative References . . . . . . . . . . . . . . . . . . . 34 15.1 Normative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 15.2 Informative References . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 34
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [1], does not define a The Session Initiation Protocol (SIP) [2], does not define a
keepalive mechanism for the sessions it establishes. Although the keepalive mechanism for the sessions it establishes. Although the
user agents may be able to determine if the session has timed out user agents may be able to determine if the session has timed out
using session specific mechanisms, proxies will not be able to do so. 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 The result is that call stateful proxies will not always be able to
determine whether a session is still active or not. For instance, determine whether a session is still active or not. For instance,
when a user agent fails to send a BYE message at the end of a when a user agent fails to send a BYE message at the end of a
session, or the BYE message gets lost due to network problems, a call session, or the BYE message gets lost due to network problems, a call
stateful proxy will not know when the session has ended. In this stateful proxy will not know when the session has ended. In this
situation, the call stateful proxy will retain state for the call and situation, the call stateful proxy will retain state for the call and
has no deterministic method of determining when the call state has no deterministic method of determining when the call state
information no longer applies. information no longer applies.
To resolve this problem, this extension defines a keepalive mechanism To resolve this problem, this extension defines a keepalive mechanism
for SIP sessions. UAs send periodic re-INVITE or UPDATE [2] requests for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests
(referred to as session refresh requests) to keep the session alive. (referred to as session refresh requests) to keep the session alive.
The interval for the session refresh requests is determined through a The interval for the session refresh requests is determined through a
negotiation mechanism defined here. If a session refresh request is negotiation mechanism defined here. If a session refresh request is
not received before the interval passes, the session is considered not received before the interval passes, the session is considered
terminated. Both UAs are supposed to send a BYE, and call stateful terminated. Both UAs are supposed to send a BYE, and call stateful
proxies can remove any state for the call. proxies can remove any state for the call.
This refresh mechanism has additional applications. For the same This refresh mechanism has additional applications. For the same
reasons a call stateful proxy server would like to determine whether reasons a call stateful proxy server would like to determine whether
the session is still active, a user agent would like to make this the session is still active, a user agent would like to make this
determination. This determination can be made at a user agent without determination. This determination can be made at a user agent
the use of SIP level mechanisms; for audio sessions, periodic RTCP without the use of SIP level mechanisms; for audio sessions, periodic
packets serve as an indication of liveness [5]. However, it is RTCP packets serve as an indication of liveness [5]. However, it is
desirable to separate SIP session liveness from the details of the desirable to separate SIP session liveness from the details of the
particular session. particular session.
Another application of the session timer is in the construction of a Another application of the session timer is in the construction of a
SIP Network Address Translator (NAT) Application Level Gateway (ALG) SIP Network Address Translator (NAT) Application Level Gateway (ALG)
[6]. The ALG embedded in a NAT will need to maintain state for the [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 duration of a call. This state must eventually be removed. Relying
a BYE to trigger the removal of state, besides being unreliable, on a BYE to trigger the removal of state, besides being unreliable,
introduces a potential denial of service attack. introduces a potential denial of service attack.
This document provides an extension to SIP that defines a session This document provides an extension to SIP that defines a session
expiration mechanism. Periodic refreshes, through re-INVITEs or expiration mechanism. Periodic refreshes, through re-INVITEs or
UPDATEs, are used to keep the session active. The extension is UPDATEs, are used to keep the session active. The extension is
sufficiently backwards compatible with SIP that it works so long as sufficiently backwards compatible with SIP that it works so long as
either one of the two participants in a dialog understand the either one of the two participants in a dialog understand the
extension. Two new header fields, Session-Expires and Min-SE, and a extension. Two new header fields, Session-Expires and Min-SE, and a
new response code, 422, are defined. Session-Expires conveys the new response code, 422, are defined. Session-Expires conveys the
duration of the session, and Min-SE conveys the minimum allowed value duration of the session, and Min-SE conveys the minimum allowed value
for the session expiration. The 422 response code indicates that the for the session expiration. The 422 response code indicates that the
session timer duration was too small. session timer duration was too small.
2. Terminology 2. Terminology
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
'SHALL', 'SHALLNOT', 'SHOULD', 'SHOULDNOT', 'RECOMMENDED', 'MAY', and 'SHALL', 'SHALLNOT', 'SHOULD', 'SHOULDNOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' are to be interpreted as described in RFC 2119 [3] and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant SIP implementations.
Additionally, we define the following terms: Additionally, we define the following terms:
Session Interval: The largest amount of time that can occur between Session Interval: The largest amount of time that can occur between
session refresh requests in a dialog before the session will be session refresh requests in a dialog before the session will be
considered timed out. The session interval is conveyed in the considered timed out. The session interval is conveyed in the
Session-Expires header field defined here. The UAS obtains this Session-Expires header field defined here. The UAS obtains this
value from the Session-Expires header field in a 2xx response to a value from the Session-Expires header field in a 2xx response to a
session refresh request that it sends. Proxies and UACs determine session refresh request that it sends. Proxies and UACs determine
this value from the Session-Expires header field in a 2xx response this value from the Session-Expires header field in a 2xx response
to a session refresh request that they receive. to a session refresh request that they receive.
Minimum Timer: Because of the processing load of mid-dialog requests, Minimum Timer: Because of the processing load of mid-dialog requests,
all elements (proxy, UAC, UAS) can have a configured minimum value all elements (proxy, UAC, UAS) can have a configured minimum value
for the session interval that they are willing to accept. This for the session interval that they are willing to accept. This
value is called the minimum timer. value is called the minimum timer.
Session Expiration: The time at which an element will consider the Session Expiration: The time at which an element will consider the
session timed out, if no successful session refresh transaction session timed out, if no successful session refresh transaction
occurs beforehand. occurs beforehand.
Session Refresh Request: An INVITE or UPDATE request processed
Session Refresh Request: An INVITE or UPDATE request within a dialog. according to the rules of this specification. If the request
If the request generates a 2xx response, the session expiration is generates a 2xx response, the session expiration is increased to
increased to the current time plus the session interval obtained the current time plus the session interval obtained from the
from the response. A session refresh request is not to be confused response. A session refresh request is not to be confused with a
with a target refresh request, defined in Section 6 of [1], which target refresh request, defined in Section 6 of [2], which is a
is a request that can update the remote target of a dialog. 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. Refresh: Same as a session refresh request.
3. Overview of Operation 3. Overview of Operation
This section provides a brief overview of operation of the extension. This section provides a brief overview of operation of the extension.
It is tutorial in nature and should not be considered as normative. It is tutorial in nature and should not be considered as normative.
This extension has the property that it works even when only one UA This extension has the property that it works even when only one UA
in a dialog supports it. The processing steps differ for handling in a dialog supports it. The processing steps differ for handling
each of the four cases (UAC supports it, or doesn't, and UAS supports each of the four cases (UAC supports it, or doesn't, and UAS supports
it, or doesn't). For simplicity's sake, this section will describe it, or doesn't). For simplicity's sake, this section will describe
basic operation in the case where both sides support the extension. basic operation in the case where both sides support the extension.
A UAC starts by sending an INVITE. It includes a Supported header A UAC starts by sending an INVITE. It includes a Supported header
with the option tag 'timer', indicating support for this extension. field with the option tag 'timer', indicating support for this
extension.
This request passes through proxies, any one of which may have an This request passes through proxies, any one of which may have an
interest in establishing a session timer. Each proxy can insert a interest in establishing a session timer. Each proxy can insert a
Session-Expires header field and a Min-SE header field into the Session-Expires header field and a Min-SE header field into the
request if none is already there or alter the value of existing request if none is already there or alter the value of existing
Session-Expires and Min-SE header fields as described below. Session-Expires and Min-SE header fields as described below.
The Min-SE header field establishes the lower bound for the session The Min-SE header field establishes the lower bound for the session
refresh interval, i.e. the fastest rate that any proxy servicing this refresh interval, i.e. the fastest rate that any proxy servicing
request will be allowed to require. The purpose of this header field this request will be allowed to require. The purpose of this header
is to prevent hostile proxies from setting arbitrarily short refresh field is to prevent hostile proxies from setting arbitrarily short
intervals such that their neighbors are overloaded. Each proxy refresh intervals such that their neighbors are overloaded. Each
processing the request can raise this lower bound (increase the proxy processing the request can raise this lower bound (increase the
period between refreshes) but is not allowed to lower it. period between refreshes) but is not allowed to lower it.
The Session-Expires header field establishes the upper bound for the The Session-Expires header field establishes the upper bound for the
session refresh interval, i.e., the time period after processing a session refresh interval, i.e., the time period after processing a
request for which any session-stateful proxy must retain its state request for which any session-stateful proxy must retain its state
for this session. Any proxy servicing this request can lower this for this session. Any proxy servicing this request can lower this
value, but is not allowed to decrease it below the value specified in value, but is not allowed to decrease it below the value specified in
the Min-SE header field. the Min-SE header field.
If the Session-Expires interval is too low for a proxy (i.e, lower 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 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 proxy rejects the request with a 422 response. That response
a Min-SE header field, identifying the minimum session interval it is contains a Min-SE header field, identifying the minimum session
willing to support. The UAC will try again, this time including the interval it is willing to support. The UAC will try again, this time
Min-SE header in the request. The header field contains the largest including the Min-SE header in the request. The header field
Min-SE header field it observed in all 422 responses received contains the largest Min-SE header field it observed in all 422
previously. This way, the minimum timer meets the constraints of all responses received previously. This way, the minimum timer meets the
proxies along the path. constraints of all proxies along the path.
After several INVITE/422 iterations, the request eventually arrives After several INVITE/422 iterations, the request eventually arrives
at the UAS. The UAS can adjust the value of the session interval as at the UAS. The UAS can adjust the value of the session interval as
if it was a proxy, and when done, it places the final session if it was a proxy, and when done, it places the final session
interval into the Session-Expires header field in a 2xx response. The interval into the Session-Expires header field in a 2xx response.
Session-Expires header field also contains a 'refresher' parameter, The Session-Expires header field also contains a 'refresher'
which indicates who is doing the refreshing - the UA that is parameter, which indicates who is doing the refreshing - the UA that
currently the UAC, or the UA that is currently the UAS. As the 2xx is currently the UAC, or the UA that is currently the UAS. As the
response travels back through the proxy chain, each proxy can observe 2xx response travels back through the proxy chain, each proxy can
the final session interval, but they can't change it. observe the final session interval, but they can't change it.
From the Session-Expires header field in the response, both UAs know From the Session-Expires header field in the response, both UAs know
that a session timer is active, they know when it will expire, and that a session timer is active, they know when it will expire, and
they know who is refreshing. At some point before the expiration, the they know who is refreshing. At some point before the expiration,
currently active refresher generates a session refresh request, which the currently active refresher generates a session refresh request,
is a re-INVITE or UPDATE [2] request. If the refresher never gets a which is a re-INVITE or UPDATE [3] request. If the refresher never
response to that session refresh request, it sends a BYE to terminate gets a response to that session refresh request, it sends a BYE to
the session. Similarly, if the other side never gets the session terminate the session. Similarly, if the other side never gets the
refresh request before the session expires, it sends a BYE. session refresh request before the session expires, it sends a BYE.
The refresh requests sent once the session is established are The refresh requests sent once the session is established are
processed identically to the initial requests, as described above. processed identically to the initial requests, as described above.
This means that a successful session refresh request will extend the This means that a successful session refresh request will extend the
session, as desired. session, as desired.
The extension introduces additional complications beyond this basic The extension introduces additional complications beyond this basic
flow to support cases where only one of the UAs supports it. One such flow to support cases where only one of the UAs supports it. One
complication is that a proxy may need to insert the Session-Expires such complication is that a proxy may need to insert the
header into the response, in the event that the UAS doesn't support Session-Expires header into the response, in the event that the UAS
the extension. The negotiation of the role of refresher is also doesn't support the extension. The negotiation of the role of
affected by this capability; it takes into consideration which refresher is also affected by this capability; it takes into
participants support the extension. consideration which participants support the extension.
It is worth noting that the session timer refreshes the session, not It is worth noting that the session timer refreshes the session, not
the dialog used to establish the session. Of course, the two are the dialog used to establish the session. Of course, the two are
related. If the session expires, a BYE is sent, which terminates the related. If the session expires, a BYE is sent, which terminates the
session and generally, the dialog. session and generally, the dialog.
4. Session-Expires Header Field Definition 4. Session-Expires Header Field Definition
The Session-Expires header field conveys the session interval for a The Session-Expires header field conveys the session interval for a
SIP session. It is placed only in INVITE or UPDATE requests, as well SIP session. It is placed only in INVITE or UPDATE requests, as well
skipping to change at page 8, line 24 skipping to change at page 8, line 24
that a SIP transaction can take in the event of a timeout. This 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 allows sufficient time for a UA to attempt a refresh at the halfpoint
of the session interval, and for that transaction to complete of the session interval, and for that transaction to complete
normally before the session expires. However, 1800 seconds (30 normally before the session expires. However, 1800 seconds (30
minutes) is RECOMMENDED as the value for the Session-Expires header minutes) is RECOMMENDED as the value for the Session-Expires header
field. In other words, SIP entities MUST be prepared to handle field. In other words, SIP entities MUST be prepared to handle
Session-Expires header field values of any duration greater than 90 Session-Expires header field values of any duration greater than 90
seconds, but entities that insert the Session-Expires header field seconds, but entities that insert the Session-Expires header field
SHOULD NOT choose values less than 30 minutes. SHOULD NOT choose values less than 30 minutes.
Small session intervals can be destructive to the network. They cause Small session intervals can be destructive to the network. They
excessive messaging traffic that affects both user agents and proxy cause excessive messaging traffic that affects both user agents and
servers. They increase the possibility of 'glare' that can occur when proxy servers. They increase the possibility of 'glare' that can
both user agents send a re-INVITE or UPDATE at the same time. Since occur when both user agents send a re-INVITE or UPDATE at the same
the primary purpose of the session timer is to provide a means to time. Since the primary purpose of the session timer is to provide a
time out state in SIP elements, very small values won't generally be means to time out state in SIP elements, very small values won't
needed. 30-minutes was chosen since 95% of phone calls are less than generally be needed. 30-minutes was chosen since 95% of phone calls
this duration. However, the 30 minute minimum is listed as a SHOULD, are less than this duration. However, the 30 minute minimum is
and not a MUST, since the exact value for this number is dependent on listed as a SHOULD, and not a MUST, since the exact value for this
many network factors, including network bandwidths and latencies, number is dependent on many network factors, including network
computing power, memory availability, network topology, and of bandwidths and latencies, computing power, memory availability,
course, the application scenario. After all, SIP can set up any kind network topology, and of course, the application scenario. After
of session, not just a phone call. At the time of publication of this all, SIP can set up any kind of session, not just a phone call. At
document, 30 minutes seems appropriate. Advances in technologies may the time of publication of this document, 30 minutes seems
result in the number being excessively large five years in the appropriate. Advances in technologies may result in the number being
future. excessively large five years in the future.
The default value of the Session-Expires header field is undefined. The default value of the Session-Expires header field is undefined.
This means that absence of the Session-Expires header field implies This means that absence of the Session-Expires header field implies
no expiration of the session using the mechanism defined in this no expiration of the session using the mechanism defined in this
specification. Note that other mechanisms not defined in this specification. Note that other mechanisms not defined in this
specification, such as locally configured timers, may apply. specification, such as locally configured timers, may apply.
The syntax of the Session-Expires header field is: The syntax of the Session-Expires header field is:
Session-Expires = ('Session-Expires' / 'x') HCOLON delta-seconds Session-Expires = ('Session-Expires' / 'x') HCOLON delta-seconds
*(SEMI se-params) *(SEMI se-params)
se-params = refresher-param / generic-param se-params = refresher-param / generic-param
refresher-param = 'refresher' EQUAL ('uas' / 'uac') refresher-param = 'refresher' EQUAL ('uas' / 'uac')
Note that a compact form, the letter x, has been reserved for Note that a compact form, the letter x, has been reserved for
Session-Expires. The BNF for delta-seconds and generic-param is Session-Expires. The BNF for delta-seconds and generic-param is
defined in Section 25 of RFC 3261 [1]. defined in Section 25 of RFC 3261 [2].
Table 1 is an extension of Tables 2 and 3 in [1] for the 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 Session-Expires and Min-SE header fields. The column 'PRA' is for
PRACK method [7], 'UPD' is for the UPDATE method [2], 'SUB' is for the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is
the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8]. for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
|Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Table 1 Session-Expires and Min-SE Header Fields Table 1 Session-Expires and Min-SE Header Fields
5. Min-SE Header Field Definition 5. Min-SE Header Field Definition
The Min-SE header field indicates the minimum value for the session 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 interval, in units of delta-seconds. When used in an INVITE or
request, it indicates the smallest value of the session interval that UPDATE request, it indicates the smallest value of the session
can be used for that session. When present in a request or response, interval that can be used for that session. When present in a
its value MUST NOT be less than 90 seconds. request or response, its value MUST NOT be less than 90 seconds.
When not present, the default value for this header field is 90 When not present, the default value for this header field is 90
seconds. seconds.
The Min-SE header field MUST NOT be used in responses except those The Min-SE header field MUST NOT be used in responses except those
with a 422 response code. It indicates the minimum value of the with a 422 response code. It indicates the minimum value of the
session interval that the server is willing to accept. session interval that the server is willing to accept.
The syntax of the Min-SE header field is: The syntax of the Min-SE header field is:
skipping to change at page 12, line 11 skipping to change at page 12, line 11
contains a Session-Expires header field with a duration that is below contains a Session-Expires header field with a duration that is below
the minimum timer for the server. The 422 response MUST contain a the minimum timer for the server. The 422 response MUST contain a
Min-SE header field with the minimum timer for that server. Min-SE header field with the minimum timer for that server.
7. UAC Behavior 7. UAC Behavior
7.1 Generating an Initial Session Refresh Request 7.1 Generating an Initial Session Refresh Request
A UAC that supports the session timer extension defined here MUST A UAC that supports the session timer extension defined here MUST
include a Supported header field in each request (except ACK), include a Supported header field in each request (except ACK),
listing the option tag 'timer' [1]. It MUST do so even if the UAC is 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. not requesting usage of the session timer for this session.
The UAC MAY include a Require header field in the request with the 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 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 to participate in the session. This does not mean that the UAC is
requiring the UAS to perform the refreshes, just that it is requiring requiring the UAS to perform the refreshes, just that it is requiring
the UAS to support the extension. In addition, the UAC MAY include a 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 Proxy-Require header field in the request with the value 'timer' to
indicate that proxies must support session timer in order to indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or correctly process the request. However, usage of either Require or
skipping to change at page 12, line 36 skipping to change at page 12, line 36
present containing 'timer'. present containing 'timer'.
A UAC MAY include the Min-SE header field in the initial INVITE A UAC MAY include the Min-SE header field in the initial INVITE
request. request.
A UAC MAY include a Session-Expires header field in an initial A UAC MAY include a Session-Expires header field in an initial
session refresh request if it wishes for a session timer to be session refresh request if it wishes for a session timer to be
applied to the session. The value of this header field indicates the 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 session interval desired by the UAC. If a Min-SE header is included
in the initial session refresh request, the value of the in the initial session refresh request, the value of the
Session-Expires MUST be equal to the value in Min-SE. Session-Expires MUST be greater than the value in Min-SE.
The UAC MAY include the refresher parameter with value 'uac' if it The UAC MAY include the refresher parameter with value 'uac' if it
wishes to perform the refreshes. However, it is RECOMMENDED that the wishes to perform the refreshes. However, it is RECOMMENDED that the
parameter be omitted, so that it can be selected by the negotiation parameter be omitted, so that it can be selected by the negotiation
mechanisms described below. mechanisms described below.
7.2 Processing a 2xx Response 7.2 Processing a 2xx Response
Session timer requires a UA to create and maintain state. This state Session timer requires a UA to create and maintain state. This state
includes the session interval, the session expiration, and the includes the session interval, the session expiration, and the
skipping to change at page 13, line 11 skipping to change at page 13, line 11
When a 2xx response to a session refresh request arrives, it may or 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 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 does, the UAC MUST look for the Session-Expires header field to
process the response. process the response.
If there was a Require header field in the response with the value If there was a Require header field in the response with the value
'timer', the Session-Expires header field will always be present. 'timer', the Session-Expires header field will always be present.
UACs MUST be prepared to receive a Session-Expires header field in a UACs MUST be prepared to receive a Session-Expires header field in a
response even if none were present in the request. The 'refresher' response even if none were present in the request. The 'refresher'
parameter will be present in the Session-Expires header field, parameter will be present in the Session-Expires header field,
indicating who will be performing the refreshes. The UAC MUST set the indicating who will be performing the refreshes. The UAC MUST set
identity of the refresher to the value of this parameter. If the 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 parameter contains the value 'uac', the UAC will perform them. It is
possible that the UAC requested session timer (and thus included a possible that the UAC requested session timer (and thus included a
Session-Expires header field in the request), but there was no Session-Expires header field in the request), but there was no
Require or Session-Expires header field in the 2xx response. This Require or Session-Expires header field in the 2xx response. This
will happen when the UAS doesn't support the session timer extension, 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 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 requested it). In this case, if the UAC still wishes to use the
session timer (they are purely for its benefit alone), it has to session timer (they are purely for its benefit alone), it has to
perform them. To do this, the UAC follows the procedures defined in perform them. To do this, the UAC follows the procedures defined in
this specification as if the Session-Expires header field were in the this specification as if the Session-Expires header field were in the
2xx response, and its value was the same as the one in the request, 2xx response, and its value was the same as the one in the request,
but with a refresher parameter of 'uac'. but with a refresher parameter of 'uac'.
If the 2xx response did not contain a Session-Expires header field, 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 there is no session expiration. In this case, no refreshes need to
sent. A 2xx without a Session-Expires can come for both initial and be sent. A 2xx without a Session-Expires can come for both initial
mid-dialog session refresh requests. This means that the session and subsequent session refresh requests. This means that the session
timer can be 'turned-off' mid dialog by receiving a response without timer can be 'turned-off' mid dialog by receiving a response without
a Session-Expires header. a Session-Expires header.
The UAC remembers the session interval for a session as the value of 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 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 recent 2xx response to a session refresh request on a dialog. It is
explicitly allowed for there to be differing session intervals (or explicitly allowed for there to be differing session intervals (or
none at all) on differing dialogs established as a result of a single none at all) on differing dialogs established as a result of a single
INVITE. It also remembers whether it, or its peer, is the refresher INVITE. It also remembers whether it, or its peer, is the refresher
on for the session. on for the session.
skipping to change at page 14, line 32 skipping to change at page 14, line 32
response to a previous session refresh request on the same dialog, or response to a previous session refresh request on the same dialog, or
if it has received a session refresh request on that dialog which if it has received a session refresh request on that dialog which
contained a Min-SE header field. Similarly, if no dialog has been 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 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 if it has ever received a 422 response to a previous
INVITE request with the same Call-ID. INVITE request with the same Call-ID.
The value of the Min-SE header field present in a session refresh The value of the Min-SE header field present in a session refresh
request MUST be the largest value amongst all Min-SE header field request MUST be the largest value amongst all Min-SE header field
values returned in all 422 responses, or received in session refresh values returned in all 422 responses, or received in session refresh
requests, on the same dialog, if a dialog has been established. If no requests, on the same dialog, if a dialog has been established. If
dialog has been established, the Min-SE header field value is set to no dialog has been established, the Min-SE header field value is set
the largest value amongst all Min-SE header field values returned in to the largest value amongst all Min-SE header field values returned
all 422 responses for an INVITE request with the same Call-ID. A 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 result of this rule is that the maximum value of the Min-SE is
effectively 'cleared' once the dialog is established, and from that effectively 'cleared' once the dialog is established, and from that
point on, only the values from proxies known to be on the proxy path point on, only the values from proxies known to be on the proxy path
will end up being used. will end up being used.
The UAC may have its own opinions about the minimum session interval. 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 In that case, if the value above is too small, the UAC MAY increase
it. it.
In a session refresh request sent within a dialog with an active In a session refresh request sent within a dialog with an active
session timer, the Sesssion-Expires header field SHOULD be present. session timer, the Sesssion-Expires header field SHOULD be present.
When present, it MUST be equal to the maximum of the Min-SE header 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) field (recall that its default value when not present is 90 seconds)
and the current session interval. 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
desireable to change the session interval mid-dialog.
If the session refresh request is not the initial one, it is If the session refresh request is not the initial one, it is
RECOMMENDED that the refresher parameter be set to 'uac' if the RECOMMENDED that the refresher parameter be set to 'uac' if the
element sending the request is currently performing refreshes, else element sending the request is currently performing refreshes, else
'uas' if its peer is performing the refreshes. This way, the role of '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 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 explicitly change the roles, it MAY use a value of 'uas' if it knows
that the other side supports session timer. It could know this by that the other side supports session timer. It could know this by
having received a request from its peer with a Supported header field having received a request from its peer with a Supported header field
containing the value 'timer'. If it wishes to reselect the roles, it containing the value 'timer'. If it wishes to reselect the roles, it
MAY omit the parameter. MAY omit the parameter.
A re-INVITE generated to refresh the session is a normal re-INVITE, 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 and an UPDATE generated to refresh a session is a normal UPDATE. If
UAC knows that its peer supports the UPDATE method, it is RECOMMENDED a UAC knows that its peer supports the UPDATE method, it is
that UPDATE be used instead of a re-INVITE. A UA can make this RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can
determination if it has seen an Allow header field from its peer with make this determination if it has seen an Allow header field from its
the value 'UPDATE', or through a mid-dialog OPTIONS request. It is peer with the value 'UPDATE', or through a mid-dialog OPTIONS
RECOMMENDED that the UPDATE request not contain an offer [4], but a request. It is RECOMMENDED that the UPDATE request not contain an
re-INVITE SHOULD contain one, even if the details of the session have offer [4], but a re-INVITE SHOULD contain one, even if the details of
not changed. In that case, the offer MUST indicate that it has not the session have not changed. In that case, the offer MUST indicate
changed. In the case of SDP, this is accomplished by including the that it has not changed. In the case of SDP, this is accomplished by
same value for the origin field as previous SDP messages to its peer. including the same value for the origin field as previous SDP
The same is true for an answer exchanged as a result of a session messages to its peer. The same is true for an answer exchanged as a
refresh request; if it has not changed, that MUST be indicated. result of a session refresh request; if it has not changed, that MUST
be indicated.
8. Proxy Behavior 8. Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers Session timers are mostly of interest to call stateful proxy servers
(that is, servers that maintain the state of calls and dialogs (that is, servers that maintain the state of calls and dialogs
established through them). However, a stateful proxy server (that is, established through them). However, a stateful proxy server (that
a server which is aware of transaction state, but does not retain is, a server which is aware of transaction state, but does not retain
call or dialog state) MAY also follow the rules described here. call or dialog state) MAY also follow the rules described here.
Stateless proxies MUST NOT attempt to request session timers. Proxies Stateless proxies MUST NOT attempt to request session timers.
that ask for session timers SHOULD record-route, since they won't Proxies that ask for session timers SHOULD record-route, since they
receive refreshes if they don't. won't receive refreshes if they don't.
The proxy processing rules require the proxy to remember The proxy processing rules require the proxy to remember
information between the request and response, ruling out stateless information between the request and response, ruling out stateless
proxies. proxies.
8.1 Processing of Requests 8.1 Processing of Requests
Processing of requests is identical for all session refresh 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 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 Session-Expires header field is present in a session refresh request
skipping to change at page 16, line 41 skipping to change at page 16, line 40
The proxy MUST NOT include a refresher parameter in the header field The proxy MUST NOT include a refresher parameter in the header field
value. value.
If the request already had a Session-Expires header field, the proxy 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 MAY reduce its value, but MUST NOT set it to a duration lower than
the value in the Min-SE header field in the request, if present. If the value in the Min-SE header field in the request, if present. If
the value of the Session-Expires header field is greater than or 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 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), 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 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 field. If the value of the Session-Expires header field is lower
the value of the Min-SE header field (possibly because the proxy 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), increased the value of the Min-SE header field, as described below),
the proxy MUST increase the value of the Session-Expires header field 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 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 insert or modify the value of the 'refresher' parameter in the
Session-Expires header field. Session-Expires header field.
If the request contains a Supported header field with a value If the request contains a Supported header field with a value
'timer', the proxy MAY reject the INVITE request with a 422 (Session 'timer', the proxy MAY reject the INVITE request with a 422 (Session
Interval Too Small) response if the session interval in the Interval Too Small) response if the session interval in the
Session-Expires header field is smaller than the minimum interval Session-Expires header field is smaller than the minimum interval
skipping to change at page 18, line 11 skipping to change at page 18, line 9
the UAS did not support the session timer. If the proxy remembers the UAS did not support the session timer. If the proxy remembers
that the UAC did not support session timer either, the proxy forwards that the UAC did not support session timer either, the proxy forwards
the response upstream normally. There is no session expiration for the response upstream normally. There is no session expiration for
this session. If, however, the proxy remembers that the UAC did this session. If, however, the proxy remembers that the UAC did
support session timer, additional processing is needed. support session timer, additional processing is needed.
Because there is no Session-Expires or Require header field in the Because there is no Session-Expires or Require header field in the
response, the proxy knows it is the first session-timer-aware proxy response, the proxy knows it is the first session-timer-aware proxy
to receive the response. This proxy MUST insert a Session-Expires to receive the response. This proxy MUST insert a Session-Expires
header field into the response with the value it remembered from the header field into the response with the value it remembered from the
forwarded request. It MUST set the value of the 'refresher' parameter forwarded request. It MUST set the value of the 'refresher'
to 'uac'. The proxy MUST insert the Require header field into the parameter to 'uac'. The proxy MUST insert the Require header field
response, with the value 'timer', before forwarding it upstream. into the response, with the value 'timer', before forwarding it
upstream.
If the received response contains a Session-Expires header field, no If the received response contains a Session-Expires header field, no
modification of the response is needed. modification of the response is needed.
In all cases, if the 2xx response forwarded upstream by the proxy In all cases, if the 2xx response forwarded upstream by the proxy
contains a Session-Expires header field, its value represents the contains a Session-Expires header field, its value represents the
session interval for the session associated with that response. The session interval for the session associated with that response. The
proxy computes the session expiration as the time when the 2xx proxy computes the session expiration as the time when the 2xx
response is forwarded upstream, plus the session interval. This response is forwarded upstream, plus the session interval. This
session expiration MUST update any existing session expiration for session expiration MUST update any existing session expiration for
the session. The refresher parameter in the Session-Expires header the session. The refresher parameter in the Session-Expires header
field in the 2xx response forwarded upstream will be present, and it field in the 2xx response forwarded upstream will be present, and it
indicates which UA is performing the refreshes. There can be multiple indicates which UA is performing the refreshes. There can be
2xx responses to a single INVITE, each representing a different multiple 2xx responses to a single INVITE, each representing a
dialog, resulting in multiple session expirations, one for each different dialog, resulting in multiple session expirations, one for
session associated with each dialog. each session associated with each dialog.
The proxy MUST NOT modify the value of the Session-Expires header The proxy MUST NOT modify the value of the Session-Expires header
field received in the response (assuming one was present) before field received in the response (assuming one was present) before
forwarding it upstream. forwarding it upstream.
8.3 Session Expiration 8.3 Session Expiration
When the current time equals or passes the session expiration for a When the current time equals or passes the session expiration for a
session, the proxy MAY remove associated call state, and MAY free any 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 resources associated with the call. Unlike the UA, it MUST NOT send
BYE. a BYE.
9. UAS Behavior 9. UAS Behavior
The UAS must respond to a request for a session timer by the UAC or a 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 proxy in the path of the request, or it may request that a session
Timer be used itself. Timer be used itself.
If an incoming request contains a Supported header field with a value If an incoming request contains a Supported header field with a value
'timer' and a Session Expires header, the UAS MAY reject the INVITE 'timer' and a Session Expires header, the UAS MAY reject the INVITE
request with a 422 (Session Interval Too Small) response if the request with a 422 (Session Interval Too Small) response if the
skipping to change at page 19, line 31 skipping to change at page 19, line 31
Session-Expires header field from the request into the 2xx response. Session-Expires header field from the request into the 2xx response.
The UAS response MAY reduce its value, but MUST NOT set it to a 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 duration lower than the value in the Min-SE header field in the
request, if present, else 90s if not. The UAS MUST NOT increase the request, if present, else 90s if not. The UAS MUST NOT increase the
value of the Session-Expires header field. value of the Session-Expires header field.
If the incoming request contains a Supported header field with a If the incoming request contains a Supported header field with a
value 'timer' but does not contain a Session-Expires header, the UAC value 'timer' but does not contain a Session-Expires header, the UAC
indicated support for timers, but did not request one. The UAS may indicated support for timers, but did not request one. The UAS may
request a session timer in the 2XX response by including a request a session timer in the 2XX response by including a
Session-Expires header field. The value MUST NOT be set to a duration Session-Expires header field. The value MUST NOT be set to a
lower than the value in the Min-SE header field in the request, if duration lower than the value in the Min-SE header field in the
present. request, if present.
The UAS MUST set the value of the refresher parameter in the The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response. This value Session-Expires header field in the 2xx response. This value
specifies who will perform refreshes for the dialog. The value is specifies who will perform refreshes for the dialog. The value is
based on the value of this parameter in the request, and on whether based on the value of this parameter in the request, and on whether
the UAC supports the session timer extension. The UAC supports the the UAC supports the session timer extension. The UAC supports the
extension if the 'timer' option tag was present in a Supported header extension if the 'timer' option tag was present in a Supported header
field in the request. Figure 3 defines how the value in the response field in the request. Figure 3 defines how the value in the response
is set. A value of 'none' in the 2nd column means that there was no 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 refresher parameter in the request. A value of 'NA' in the third
skipping to change at page 20, line 19 skipping to change at page 20, line 19
N uac NA N uac NA
N uas NA N uas NA
Y none uas or uac Y none uas or uac
Y uac uac Y uac uac
Y uas uas Y uas uas
Figure 3: UAS Behavior Figure 3: UAS Behavior
The fourth row of Figure 3 describes a case where both the UAC and The fourth row of Figure 3 describes a case where both the UAC and
UAS support the session timer extension, and the UAC did not select UAS support the session timer extension, and the UAC did not select
who will perform refreshes. This allows the UAS to decide whether it, who will perform refreshes. This allows the UAS to decide whether
or the UAC, will perform the refreshes. However, as the table it, or the UAC, will perform the refreshes. However, as the table
indicates, the UAS cannot override the UAC's choice of refresher, if indicates, the UAS cannot override the UAC's choice of refresher, if
it made one. it made one.
If the refresher parameter in the Session-Expires header field in the 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 2xx response has a value of 'uac', the UAS MUST place a Require
header field into the response with the value 'timer'. This is header field into the response with the value 'timer'. This is
because the uac is performing refreshes and the response has to be 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 processed for the UAC to know this. If the refresher parameter in
2xx response has a value of 'uas', and the Supported header field in the 2xx response has a value of 'uas', and the Supported header field
the request contained the value 'timer', the UAS SHOULD place a in the request contained the value 'timer', the UAS SHOULD place a
Require header field into the response with the value 'timer'. In 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 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 BYE if it never receives a refresh. Since the call will still
without the UAC doing this, insertion of the Require is a SHOULD succeed without the UAC doing this, insertion of the Require is a
here, rather than a MUST. SHOULD here, rather than a MUST.
The UAS, just like the UAC, stores state for the session timer. This The UAS, just like the UAC, stores state for the session timer. This
state includes the session interval, the session expiration, and the state includes the session interval, the session expiration, and the
identity of the refresher. This state is bound to the dialog used to 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 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 delta-time from the Session-Expires header field in the most recent
2xx response to a session refresh request on that dialog. It also 2xx response to a session refresh request on that dialog. It also
remembers whether it, or its peer, is the refresher on the leg, based remembers whether it, or its peer, is the refresher on the leg, based
on the value of the refresher parameter from the most recent 2xx on the value of the refresher parameter from the most recent 2xx
response to a session refresh request on that dialog. If the most response to a session refresh request on that dialog. If the most
recent 2xx response had no Session-Expires header field, there is no recent 2xx response had no Session-Expires header field, there is no
session expiration, and no refreshes need to be performed. session expiration, and no refreshes need to be performed.
If the UAS must refresh the session, it computes the session If the UAS must refresh the session, it computes the session
expiration. The session expiration is the time of transmission of the expiration. The session expiration is the time of transmission of
last 2xx response to a session refresh request on that dialog plus the last 2xx response to a session refresh request on that dialog
the session interval. If UA wishes to continue with the session plus the session interval. If UA wishes to continue with the session
beyond the session expiration, it MUST generate a refresh before the beyond the session expiration, it MUST generate a refresh before the
session expiration. It is RECOMMENDED that this refresh be sent once session expiration. It is RECOMMENDED that this refresh be sent once
half the session interval has elapsed. Additional procedures for this half the session interval has elapsed. Additional procedures for
refresh are described in Section 10. this refresh are described in Section 10.
10. Performing Refreshes 10. Performing Refreshes
The side generating a refresh does so according to the UAC procedures 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 defined in Section 7. Note that only a 2xx response to a session
refresh request extends the session expiration. This means that a UA refresh request extends the session expiration. This means that a UA
could attempt a refresh, and receive a 422 response with a Min-SE could attempt a refresh, and receive a 422 response with a Min-SE
header field that contains a value much larger than the current header field that contains a value much larger than the current
session interval. The UA will still need to send a session refresh session interval. The UA will still need to send a session refresh
request before the session expiration (which has not changed), even request before the session expiration (which has not changed), even
though this request will contain a value of the Session-Expires that though this request will contain a value of the Session-Expires that
is much larger than the current session interval. is much larger than the current session interval.
If the session refresh request transaction times out or generates a If the session refresh request transaction times out or generates a
408 or 481 response, then the UAC sends a BYE request per the rules 408 or 481 response, then the UAC sends a BYE request per the rules
in Section 12.2.1.2 of RFC 3261 [1]. If the session refresh request in 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 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 not refreshed), and a response other than 408 or 481 is received, the
UAC SHOULD follow the rules specific to that response code, and retry UAC SHOULD follow the rules specific to that response code, and retry
if possible. For example, if the response is a 401, the UAC would if possible. For example, if the response is a 401, the UAC would
retry the request with new credentials. However, the UAC SHOULD NOT retry the request with new credentials. However, the UAC SHOULD NOT
continuously retry the request if the server indicates the same error continuously retry the request if the server indicates the same error
response. response.
Similarly, if the side not performing refreshes does not receive a Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, they SHOULD session refresh request before the session expiration, they SHOULD
skipping to change at page 23, line 25 skipping to change at page 23, line 25
11.1 Inside Attacks 11.1 Inside Attacks
This introduces the possibility of rogue proxies or UAs introducing This introduces the possibility of rogue proxies or UAs introducing
denial-of-service attacks. However, the mechanisms in this denial-of-service attacks. However, the mechanisms in this
specification prevent that from happening. specification prevent that from happening.
First, consider the case of a rogue UAC that wishes to force a UAS to 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 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 Session-Expires header field into an INVITE with a low duration and a
refresher parameter equal to uas. Assume it places a Supported header refresher parameter equal to uas. Assume it places a Supported
field into the request. Any proxy, or the UAS, which objects to this header field into the request. Any proxy, or the UAS, which objects
low timer will reject the request with a 422, therefore preventing to this low timer will reject the request with a 422, therefore
the attack. If no Supported header field was present, the proxies preventing the attack. If no Supported header field was present, the
will insert a Min-SE header field into the request before forwarding proxies will insert a Min-SE header field into the request before
it. As a result, the UAS will not choose a session timer lower than forwarding it. As a result, the UAS will not choose a session timer
the minimum acceptable one to all elements on the path. This too lower than the minimum acceptable one to all elements on the path.
prevents the attack. This too prevents the attack.
Next, consider the case of a rogue UAS that wishes to force a UAC to 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 generate refreshes at a rapid rate. In that case, the UAC has to
support session timer. The initial INVITE arrives at the rogue UAS, support session timer. The initial INVITE arrives at the rogue UAS,
which returns a 2xx with a very small session interval. The UAC uses which returns a 2xx with a very small session interval. The UAC uses
this timer, and quickly sends a refresh. Section 7.1 requires the UAC this timer, and quickly sends a refresh. Section 7.4 requires the
to copy the current session interval into the Session-Expires header UAC to copy the current session interval into the Session-Expires
field in the request. This enables the proxies to see the current header field in the request. This enables the proxies to see the
value. The proxies will reject this request, and provide a Min-SE current value. The proxies will reject this request, and provide a
with a higher minimum. The UAC will then use this higher minimum. Min-SE with a higher minimum. The UAC will then use this higher
Note, that if the proxies did not reject the request, but rather minimum. Note, that if the proxies did not reject the request, but
proxied the request with a Min-SE header field, an attack would still rather proxied the request with a Min-SE header field, an attack
be possible. The UAS could discard this header field in a 2xx would still be possible. The UAS could discard this header field in
response, and force the UAC to continue to generate rapid requests. 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 In a similar fashion, a rogue proxy cannot force either the UAC or
UAS to generate refreshes unless the proxy remains on the signaling UAS to generate refreshes unless the proxy remains on the signaling
path, and sees every request and response. path, and sees every request and response.
11.2 Outside Attacks 11.2 Outside Attacks
An element that can observe and modify a request or response in An element that can observe and modify a request or response in
transit can force rapid session refreshes. To prevent that, requests transit can force rapid session refreshes. To prevent that, requests
and responses need to be protected by message integrity. Since the and responses need to be protected by message integrity. Since the
skipping to change at page 25, line 8 skipping to change at page 25, line 8
obtained only if security is applied on each hop, it is RECOMMENDED obtained only if security is applied on each hop, it is RECOMMENDED
that the SIPS URI scheme be used in conjunction with this extension. that the SIPS URI scheme be used in conjunction with this extension.
This means that proxies that record-route and request session timer, This means that proxies that record-route and request session timer,
SHOULD record-route with a SIPS URI. A UA that inserts a SHOULD record-route with a SIPS URI. A UA that inserts a
Session-Expires header into a request or response SHOULD include a Session-Expires header into a request or response SHOULD include a
Contact URI that is a SIPS URI. Contact URI that is a SIPS URI.
12. IANA Considerations 12. IANA Considerations
This extension defines two new header fields, a new response code, This extension defines two new header fields, a new response code,
and a new option tag. SIP [1] defines IANA procedures for registering and a new option tag. SIP [2] defines IANA procedures for
these. registering these.
12.1 IANA Registration of Min-SE and Session-Expires Header Fields 12.1 IANA Registration of Min-SE and Session-Expires Header Fields
The following is the registration for the Min-SE header field: The following is the registration for the Min-SE header field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Header Name: Min-SE Header Name: Min-SE
Compact Form: none Compact Form: none
The following is the registration for the Session-Expires header The following is the registration for the Session-Expires header
field: field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Header Name: Session-Expires Header Name: Session-Expires
Compact Form: x Compact Form: x
12.2 IANA Registration of the 422 (Session Interval Too Small) Response 12.2 IANA Registration of the 422 (Session Interval Too Small) Response
Code Code
The following is the registration for the 422 (Session Interval Too The following is the registration for the 422 (Session Interval Too
Small) response code: Small) response code:
Response Code: 422 Response Code: 422
Default Reason Phrase: Session Interval Too Small Default Reason Phrase: Session Interval Too Small
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
12.3 IANA Registration of the 'timer' Option Tag 12.3 IANA Registration of the 'timer' Option Tag
The following is the registration for the 'timer' option tag: The following is the registration for the 'timer' option tag:
Name: timer Name: timer
Description: This option tag is for support of the session timer Description: This option tag is for support of the session timer
extension. Inclusion in a Supported header field in a request or extension. Inclusion in a Supported header field in a request or
response indicates that the UA is capable of performing refreshes response indicates that the UA is capable of performing refreshes
according to that specification. Inclusion in a Require header in according to that specification. Inclusion in a Require header in
a request means that the UAS must understand the session timer a request means that the UAS must understand the session timer
extension to process the request. Inclusion in a Require header extension to process the request. Inclusion in a Require header
field in a response indicates that the UAC must look for the field in a response indicates that the UAC must look for the
Session-Expires header field in the response, and process Session-Expires header field in the response, and process
accordingly. accordingly.
skipping to change at page 29, line 5 skipping to change at page 28, line 5
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Alice's SDP not shown) (Alice's SDP not shown)
This request indicates that Alice supports the session timer, and is This request indicates that Alice supports the session timer, and is
request session refreshes every 50 seconds. This arrives at the first request session refreshes every 50 seconds. This arrives at the
proxy, P1. This session interval is below the minimum allowed value first proxy, P1. This session interval is below the minimum allowed
of 3600. So, P1 rejects the request with a 422 (message 2): value of 3600. So, P1 rejects the request with a 422 (message 2):
SIP/2.0 422 Session Interval Too Small SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
;received=192.0.2.1 ;received=192.0.2.1
Min-SE: 3600 Min-SE: 3600
To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
skipping to change at page 30, line 26 skipping to change at page 29, line 26
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Alice's SDP not shown) (Alice's SDP not shown)
P1 record-routes once again, but P2 does not (this wouldn't normally P1 record-routes once again, but P2 does not (this wouldn't normally
happen; presumably, if it asked for session timer, it would happen; presumably, if it asked for session timer, it would
record-route the subsequent request). The UAS receives the request. record-route the subsequent request). The UAS receives the request.
It copies the Session-Expires header from the request to the It copies the Session-Expires header from the request to the
response, and adds a refresher parameter with value 'uac'. This 200 response, and adds a refresher parameter with value 'uac'. This 200
OK is forwarded back to Alice. The response she receives (message 15) OK is forwarded back to Alice. The response she receives (message
might look like: 15) might look like:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
;received=192.0.2.1 ;received=192.0.2.1
Require: timer Require: timer
Supported: timer Supported: timer
Record-Route: sips:p1.atlanta.example.com;lr Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314161 INVITE CSeq: 314161 INVITE
Contact: <sips:bob@192.0.2.4> Contact: <sips:bob@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Bob's SDP not shown) (Bob's SDP not shown)
Alice generates an ACK (message 16), which is routed through P1 and Alice generates an ACK (message 16), which is routed through P1 and
then to Bob. Since Alice is the refresher, around 3000 seconds later, then to Bob. Since Alice is the refresher, around 3000 seconds
Alice sends an UPDATE request to refresh the session. Since this later, Alice sends an UPDATE request to refresh the session. Since
request is part of an established dialog, and Alice has not received this request is part of an established dialog, and Alice has not
any 422 responses or requests on that dialog, there is no Min-SE received any 422 responses or requests on that dialog, there is no
header field in her request (message 18): Min-SE header field in her request (message 18):
UPDATE sips:bob@192.0.2.4 SIP/2.0 UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sips:p1.atlanta.example.com;lr Route: sips:p1.atlanta.example.com;lr
Supported: timer Supported: timer
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE CSeq: 314162 UPDATE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
the Session-Expires header field into the response. This is forwarded the Session-Expires header field into the response. This is
through P1, and arrives at Alice. The response she receives (message forwarded through P1, and arrives at Alice. The response she
21) might look like: receives (message 21) might look like:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
;received=192.0.2.1 ;received=192.0.2.1
Require: timer Require: timer
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE CSeq: 314162 UPDATE
Contact: <sips:bob@192.0.2.4> Contact: <sips:bob@192.0.2.4>
Shortly afterwards, Alice's UA crashes. As a result, she never sends Shortly afterwards, Alice's UA crashes. As a result, she never sends
a session refresh request. 3968 seconds later, Bob times out, and 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 sends a BYE request (message 22). This is sent to P1. P1 attempts
deliver it, but fails (since Alice's UA has crashed). P1 then returns to deliver it, but fails (since Alice's UA has crashed). P1 then
a 408 (Request Timeout) to Bob. returns a 408 (Request Timeout) to Bob.
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Brett Tate for his contributions to this The authors wish to thank Brett Tate for his contributions to this
work. Brian Rosen completed the editing of the document. work. Brian Rosen completed the editing of the document.
Normative References 15. References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 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: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
15.2 Informative References
[5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 3550, July 2003.
Informative References
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002. 2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
skipping to change at page 35, line 8 skipping to change at page 34, line 8
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/