draft-ietf-sip-session-timer-13.txt   draft-ietf-sip-session-timer-14.txt 
SIP S. Donovan SIP S. Donovan
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: July 14, 2004 dynamicsoft Expires: August 13, 2004 dynamicsoft
January 14, 2004 February 13, 2004
Session Timers in the Session Initiation Protocol (SIP) Session Timers in the Session Initiation Protocol (SIP)
draft-ietf-sip-session-timer-13 draft-ietf-sip-session-timer-14
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 http://
www.ietf.org/ietf/1id-abstracts.txt. 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 July 14, 2004. This Internet-Draft will expire on August 13, 2004.
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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . 13 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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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. 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 of them can insert a interest in establishing a session timer. Each proxy can insert a
Session-Expires header field into the request if none is already Session-Expires header field and a Min-SE header field into the
there, containing the desired interval. If one is already there, a request if none is already there or alter the value of existing
proxy can reduce the interval, but not to a value lower than the Session-Expires and Min-SE header fields as described below.
Min-SE header field. The Min-SE header field contains the minimum
allowed value of the session interval. Its purpose, explained below,
is to ensure that the session interval is not lower than any proxy's
configured minimum.
If the Session-Expires interval is too low for a proxy, it can reject The Min-SE header field establishes the lower bound for the session
the request with a 422 response. That response contains the Min-SE refresh interval, i.e. the fastest rate that any proxy servicing this
header field, identifying the minimum session interval it is willing request will be allowed to require. The purpose of this header field
to support. The UAC will try again, this time including the Min-SE is to prevent hostile proxies from setting arbitrarily short refresh
header in the request. The header field contains the largest Min-SE intervals such that their neighbors are overloaded. Each proxy
header field it observed in all 422 responses received previously. processing the request can raise this lower bound (increase the
This way, the minimum timer meets the constraints of all proxies period between refreshes) but is not allowed to lower it.
along the path.
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 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 in the request. The header field contains the largest
Min-SE header field it observed in all 422 responses received
previously. This way, the minimum timer meets the 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. The
Session-Expires header field also contains a 'refresher' parameter, Session-Expires header field also contains a 'refresher' parameter,
which indicates who is doing the refreshing - the UA that is 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 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 response travels back through the proxy chain, each proxy can observe
the final session interval, but they can't change it. the final session interval, but they can't change it.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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
as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires
header field, it contains a delta-time. header field, it contains a delta-time.
There is no absolute minimum value for the Session-Expires header The absolute minimum for the Session-Expires header field is 90
field. However, 1800 seconds (30 minutes) is RECOMMENDED. In other seconds. This value represents a bit more than twice the duration
words, SIP entities MUST be prepared to handle Session-Expires header that a SIP transaction can take in the event of a timeout. This
field values of any duration, but entities that insert the allows sufficient time for a UA to attempt a refresh at the halfpoint
Session-Expires header field SHOULD NOT choose values less than 30 of the session interval, and for that transaction to complete
minutes. 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 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 cause
excessive messaging traffic that affects both user agents and proxy excessive messaging traffic that affects both user agents and proxy
servers. They increase the possibility of 'glare' that can occur when 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 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 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 time out state in SIP elements, very small values won't generally be
needed. 30-minutes was chosen since 95% of phone calls are less than needed. 30-minutes was chosen since 95% of phone calls are less than
this duration. However, the 30 minute minimum is listed as a SHOULD, this duration. However, the 30 minute minimum is listed as a SHOULD,
and not a MUST, since the exact value for this number is dependent on and not a MUST, since the exact value for this number is dependent on
many network factors, including network bandwidths and latencies, many network factors, including network bandwidths and latencies,
computing power, memory availability, network topology, and of computing power, memory availability, network topology, and of
course, the application scenario. After all, SIP can set up any kind 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 of session, not just a phone call. At the time of publication of this
document, 30 minutes seems appropriate. Advances in technologies may document, 30 minutes seems appropriate. Advances in technologies may
result in the number being excessively large five years in the result in the number being excessively large five years in the
future. future.
The default value of the Session-Expires header field, when not The default value of the Session-Expires header field is undefined.
present, is infinity. This means that absence of the Session-Expires This means that absence of the Session-Expires header field implies
header field implies no expiration. 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: 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 [1].
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 [1] 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 the
PRACK method [7], 'UPD' is for the UPDATE method [2], 'SUB' is for PRACK method [7], 'UPD' is for the UPDATE method [2], 'SUB' is for
the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8]. the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
skipping to change at page 10, line 10 skipping to change at page 10, line 10
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
|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 UPDATE
request, it indicates the smallest value of the session interval that request, it indicates the smallest value of the session interval that
can be used for that session. can be used for that session. When present in a request or response,
its value MUST NOT be less than 90 seconds.
When not present, the default value for this header field is zero. When not present, the default value for this header field is 90
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:
Min-SE = 'Min-SE' HCOLON delta-seconds *(SEMI generic-param) Min-SE = 'Min-SE' HCOLON delta-seconds *(SEMI generic-param)
6. 422 Response Code Definition 6. 422 Response Code Definition
skipping to change at page 12, line 31 skipping to change at page 12, line 31
correctly process the request. However, usage of either Require or correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the since the extension works even when only the UAC supports the
extension. The Supported header field containing 'timer' MUST still extension. The Supported header field containing 'timer' MUST still
be included even if the Require or Proxy-Require header fields are be included even if the Require or Proxy-Require header fields are
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 in an initial session refresh A UAC MAY include a Session-Expires header field in an initial
request if it wishes for a session timer to be applied to the session refresh request if it wishes for a session timer to be
session. The value of this header field indicates the session applied to the session. The value of this header field indicates the
interval desired by the UAC. If a Min-SE header is included in the session interval desired by the UAC. If a Min-SE header is included
initial session refresh request, the value of the Session-Expires in the initial session refresh request, the value of the
MUST be equal to the value in Min-SE. Session-Expires MUST be equal to 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 14, line 45 skipping to change at page 14, line 48
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 MUST be equal to the maximum of the Min-SE header
field (recall that its default value when not present is zero) and field (recall that its default value when not present is 90 seconds)
the current session interval. and the current session interval.
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
skipping to change at page 16, line 39 skipping to change at page 16, line 39
expiration time the proxy would like, but not with a duration lower 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 present. than the value in the Min-SE header field in the request, if present.
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 zero when the Min-SE header field is not present), the default is 90 seconds when the Min-SE header field is not present),
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 than
the value of the Min-SE header field (possibly because the proxy 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
defined by the proxy's local policy. When sending the 422 response, 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 the proxy MUST include a Min-SE header field with the value of its
minimum interval. minimum interval. That minimum MUST NOT be lower than 90 seconds.
If the request doesn't indicate support for session timer, but the If the request doesn't indicate support for session timer, but the
request contains a session interval that is too small, the proxy request contains a session interval that is too small, the proxy
cannot usefully reject the request, as this would result in a call cannot usefully reject the request, as this would result in a call
failure. Rather, the proxy SHOULD insert a Min-SE header field failure. Rather, the proxy SHOULD insert a Min-SE header field
containing its minimum interval. If a Min-SE header field is already containing its minimum interval. If a Min-SE header field is already
present, the proxy SHOULD increase (but MUST NOT decrease) the value present, the proxy SHOULD increase (but MUST NOT decrease) the value
to equal its minimum interval. The proxy MUST then increase the to equal its minimum interval. The proxy MUST then increase the
Session-Expires header field value to be equal to the value in the Session-Expires 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, as described above. A proxy MUST NOT insert a
skipping to change at page 19, line 17 skipping to change at page 19, line 17
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
session interval in the Session-Expires header field is smaller than session interval in the Session-Expires header field is smaller than
the minimum interval defined by the UAS' local policy. When sending 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 the 422 response, the UAS MUST include a Min-SE header field with the
value of its minimum interval. 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 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. 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. If the value of the Session-Expires header field request, if present, else 90s if not. The UAS MUST NOT increase the
is greater than or equal to the value in the Min-SE header field value of the Session-Expires header field.
(recall that the default is zero when the Min-SE header field is not
present), the UAS 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 a
proxy increased the value of the Min-SE header field), the UAS MUST
increase the value of the Session-Expires header field to make it
equal to Min-SE header field value.
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. The value MUST NOT be set it to a duration 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 lower than the value in the Min-SE header field in the request, if
present. 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
skipping to change at page 20, line 17 skipping to change at page 20, line 17
------------------------------------------------------- -------------------------------------------------------
N none uas N none uas
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 Table 2 describes a case where both the UAC and UAS The fourth row of Figure 3 describes a case where both the UAC and
support the session timer extension, and the UAC did not select who UAS support the session timer extension, and the UAC did not select
will perform refreshes. This allows the UAS to decide whether it, or who will perform refreshes. This allows the UAS to decide whether it,
the UAC, will perform the refreshes. However, as the table indicates, or the UAC, will perform the refreshes. However, as the table
the UAS cannot override the UAC's choice of refresher, if it made indicates, the UAS cannot override the UAC's choice of refresher, if
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 the
2xx response has a value of 'uas', and the Supported header field in 2xx response has a value of 'uas', and the Supported header field in
the request contained the value 'timer', the UAS SHOULD place a 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
skipping to change at page 22, line 17 skipping to change at page 22, line 17
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 no 2xx response to a session refresh request is received before If the session refresh request transaction times out or generates a
the session expiration, the UA SHOULD send a BYE request to terminate 408 or 481 response, then the UAC sends a BYE request per the rules
the session. It SHOULD send this BYE slightly before session in Section 12.2.1.2 of RFC 3261 [1]. If the session refresh request
expiration. The minimum of ten seconds and one third the session does not generate a 2xx response (and, as a result, the session is
interval is RECOMMENDED. 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
For example, if the session interval is 120 seconds, one third of if possible. For example, if the response is a 401, the UAC would
this is 40 seconds. Since the minimum of 10 seconds and 40 seconds retry the request with new credentials. However, the UAC SHOULD NOT
is 10 seconds, the BYE would be sent 10 seconds before the session continuously retry the request if the server indicates the same error
expires. 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
send a BYE to terminate the session, slightly before the session send a BYE to terminate the session, slightly before the session
expiration. The minimum of ten seconds and one third the session expiration. The minimum of 32 seconds and one third the session
interval is RECOMMENDED. interval is RECOMMENDED.
Firewalls and NAT ALGs may be very unforgiving about allowing SIP Firewalls and NAT ALGs may be very unforgiving about allowing SIP
traffic to pass after the expiration time of the session. It is traffic to pass after the expiration time of the session. It is
for this reason that the BYE should be sent before the expiration. for this reason that the BYE should be sent before the expiration.
11. Security Considerations 11. Security Considerations
The session timer introduces the capability of a proxy or UA element 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 to force compliant UAs to send refreshes at a rate of the element's
skipping to change at page 31, line 35 skipping to change at page 31, line 35
;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. 3990 seconds later, Bob gives up, 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 to
deliver it, but fails (since Alice's UA has crashed). P1 then returns deliver it, but fails (since Alice's UA has crashed). P1 then returns
a 408 (Request Timeout) to Bob. 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 Normative References
skipping to change at page 36, line 7 skipping to change at page 36, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 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/