draft-ietf-sip-session-timer-09.txt   draft-ietf-sip-session-timer-10.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft S.Donovan Internet Draft S.Donovan
dynamicsoft dynamicsoft
J.Rosenberg J.Rosenberg
dynamicsoft dynamicsoft
draft-ietf-sip-session-timer-09.txt draft-ietf-sip-session-timer-10.txt
July 1, 2002 November 4, 2002
Expires: January 2003 Expires: May 2003
Session Initiation Protocol Extension for Session Timer Session Timers in the Session Initiation Protocol (SIP)
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 2, line 5
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
agents and proxies to determine if the SIP session is still active. agents and proxies to determine if the SIP session is still active.
The extension defines two new header fields, Session-Expires, which The extension defines two new header fields, Session-Expires, which
conveys the lifetime of the session, and Min-SE, which conveys the conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer. minimum allowed value for the session timer.
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 4
3 Overview of Operation ............................... 4
4 Session-Expires Header Field Definition ............. 6
5 Min-SE Header Field Definition ...................... 7
6 422 Response Code Definition ........................ 8
7 UAC Behavior ........................................ 8
7.1 Generating a Session Refresh Request ................ 8
7.2 Processing a 2xx Response ........................... 10
7.3 Processing a 422 Response ........................... 11
8 Proxy Behavior ...................................... 11
8.1 Processing of Requests .............................. 11
8.2 Processing of Responses ............................. 13
8.3 Session Expiration .................................. 13
9 UAS Behavior ........................................ 14
10 Performing Refreshes ................................ 16
11 Security Considerations ............................. 16
11.1 Inside Attacks ...................................... 17
11.2 Outside Attacks ..................................... 17
12 IANA Considerations ................................. 18
12.1 IANA Registration of Min-SE and Session-Expires
Header Fields .................................................. 18
12.2 IANA Registration of the 422 (Session Interval Too
Small) Response Code ........................................... 18
12.3 IANA Registration of the "timer" Option Tag ......... 18
13 Example Call Flow ................................... 19
14 Acknowledgements .................................... 24
15 Author's Addresses .................................. 24
16 Normative References ................................ 24
17 Informative References .............................. 24
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1], does not define a The Session Initiation Protocol (SIP) [1], 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
skipping to change at page 1, line 140 skipping to change at page 4, line 51
request, defined in Section 6 of [1], which is a request request, defined in Section 6 of [1], which is a request
that can update the remote target of a dialog. that can update the remote target of a dialog.
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.
Session refreshes are accomplished using SIP INVITE or UPDATE [2] This extension has the property that it works even when only one UA
requests. The initial session refresh request establishes the in a dialog supports it. The processing steps differ for handling
duration of the session, which is carried in the Session-Expires each of the four cases (UAC supports it, or doesn't, and UAS supports
header field in the 2xx response to the session refresh request. The it, or doesn't). For simplicity's sake, this section will describe
Session-Expires header field in the 2xx response also indicates which basic operation in the case where both sides support the extension.
side will be responsible for generating these refreshes - the UAC or
the UAS. The responsible side generates a refresh (using a re-INVITE
or UPDATE) before the session expires. If the refresher never gets a
response to that session refresh request, it sends a BYE to terminate
the session. Similarly, if the other side never gets the session
refresh request before the session expires, it sends a BYE. All
session refresh requests are processed identically to the initial
session refresh request, so that the 2xx response to a session
refresh request carries the new time at which the session will
expire.
It is an explicit goal of this extension to operate so long as one of A UAC starts by sending an INVITE. It includes a Supported header
the two UAs in a dialog support the extension. That side, of course, with the option tag "timer", indicating support for this extension.
ends up performing the refreshes. The other side will merely see them This request passes through proxies and B2BUAs, any one of which may
as repetitive re-INVITE or UPDATE requests. This facilitates have an interest in establishing a session timer. Each of them can
interoperability. insert a Session-Expires header field into the request if none is
already there, containing the desired interval. If one is already
there, a proxy or B2BUA can reduce the interval, but not to a value
lower than the 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 proxies configured minimum.
The extension supports negotiation of a reasonable value for the If the Session-Expires interval is too low for a proxy, it can reject
session interval, and negotiation of which side of the dialog is the request with a 422 response. That response contains the Min-SE
performing the refreshes. Negotiation of the session interval is header field, identifying the minimum session interval it is willing
critical. The value must be small enough to provide a useful to support. The UAC will try again, this time including the Min-SE
expiration, but not so small to overload the proxies with messages. header in the request. The header field contains the largest Min-SE
The goal of the negotiation algorithm is to choose a session interval header field it observed in all 422 responses received previously.
that is the smallest of all the values requested by all elements on This way, the minimum timer meets the constraints of all proxies
the dialog path, but only if that value is larger than the largest along the path.
minimum timer requested by all elements. Negotiation of the refresher
role is simpler. If only one side supports the extension, that side
acts as refresher. Otherwise, one side chooses who will refresh. This
negotiation takes place as part of session refresh request
processing, and due to the idempotency of that processing, is redone
each time the session is refreshed.
To negotiate the value of the refresh interval, the Min-SE and After several INVITE/422 iterations, the request eventually arrives
Session-Expires header fields are used. The UAC generates a session at the UAS. The UAS can adjust the value of the session interval as
refresh request, and includes a Session-Expires header field if it if it was a proxy, and when done, it places the final session
wishes to use the session timer. The Session-Expires header field interval into the Session-Expires header field in a 2xx response. The
value contains the session interval. As the session refresh request Session-Expires header field also contains a "refresher" parameter,
traverses proxies, the proxies (and the UAS) can reduce the value of which indicates who is doing the refreshing - the UA that is
the session interval, but not lower than the value of the Min-SE currently the UAC, or the UA that is currently the UAS. As the 2xx
header field. If a proxy or UAS receives a request with a Session- response travels back through the proxy chain, each proxy or B2BUA
Expires header field value lower than a configured minimum, it can can observe the final session interval (they can't change it).
reject the request with a 422 response. This response contains a
Min-SE header field with the minimum allowed value. The client
retries the request, inserting a Min-SE header field containing the
maximum value of the Min-SE header fields returned in previous 422
responses for the call. In the case where the UAC isn't aware of the
session timer extension, a proxy that receives a session refresh
request with a Session-Expires lower than the configured minimum
places the Min-SE header field in the proxied request, and increases
the Session-Expires header field value to that minimum. When the
request eventually reaches the UAS (potentially after a few retries
resulting from a 422), it will contain a Session-Expires header field
whose value meets the design criteria described above. The UAS
returns a 200 OK with a Session-Expires header field containing that
value. The header field also contains a parameter, called refresher,
that indicates which side is performing the refreshes.
When only the UAC supports the session timer extension, one of the From the Session-Expires header field in the response, both UAs know
proxies "fills the shoes" of the UAS. Specifically, when the UAS does that a session timer is active, they know when it will expire, and
support session timer, it places the value of the session interval they know who is refreshing. At some point before the expiration, the
into the Session-Expires header field in the 2xx response. When the currently active refresher generates a session refresh request, which
UAS doesn't support it, the proxy closest to the UAS that asked for a is a re-INVITE or UPDATE [2] request. If the refresher never gets a
session expiration performs that job, and inserts the value of the response to that session refresh request, it sends a BYE to terminate
session interval into the 2xx response as it passes by. the session. Similarly, if the other side never gets the session
refresh request before the session expires, it sends a BYE.
The refresh requests sent once the session is established are
processed identically to the initial requests, as described above.
This means that a successful session refresh request will extend the
session, as desired.
The extension introduces additional complications beyond this basic
flow to support cases where only one of the UA support it. One such
complication is that a proxy may need to insert the Session-Expires
header into the response, in the event that the UAS doesn't support
the extension. The negotiation of the role of refresher is also
affected by this capability; it takes into consideration which
participants support the extension.
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, and is SIP session. It is placed only in INVITE or UPDATE requests, and is
skipping to change at page 1, line 423 skipping to change at page 10, line 40
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 be
sent. A 2xx without a Session-Expires can come for both initial and sent. A 2xx without a Session-Expires can come for both initial and
mid-dialog session refresh requests. mid-dialog session refresh requests. This means that the session
timer can be "turned-off" mid dialog by receiving a response without
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.
If the UAC must perform the refreshes, it computes the session If the UAC must perform the refreshes, it computes the session
skipping to change at page 1, line 447 skipping to change at page 11, line 17
to continue with the session beyond the session expiration, it MUST to continue with the session beyond the session expiration, it MUST
generate a refresh before the session expiration. It is RECOMMENDED generate a refresh before the session expiration. It is RECOMMENDED
that this refresh be sent once half the session interval has elapsed. that this refresh be sent once half the session interval has elapsed.
Additional procedures for this refresh are described in Section 10. Additional procedures for this refresh are described in Section 10.
7.3 Processing a 422 Response 7.3 Processing a 422 Response
If the response to a session refresh request is a 422 (Session If the response to a session refresh request is a 422 (Session
Interval Too Small) response message, then the UAC MAY retry the Interval Too Small) response message, then the UAC MAY retry the
request. The procedures for retrying are described in Section 7.1. request. The procedures for retrying are described in Section 7.1.
This new request constitutes a new transaction and SHOULD have the
same value of the Call-ID, To, and From of the previous request, but
the CSeq should contain a new sequence number that is one higher than
the previous.
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
However, a stateful proxy server MAY also follow the rules described and B2BUAs. However, a stateful proxy server MAY also follow the
here. Stateless proxies MUST NOT attempt to request session timers. rules described here. Stateless proxies MUST NOT attempt to request
Proxies which ask for session timers SHOULD record-route, since they session timers. Proxies which ask for session timers SHOULD record-
won't receive refreshes if they don't. route, since they 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 information between the request and response, ruling out
stateless proxies. stateless 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
for that session. A proxy MAY insert a Session-Expires header field for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it, if none was present in the in the request before forwarding it, if none was present in the
request. This Session-Expires header field may contain any desired request. This Session-Expires header field may contain any desired
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 or B2BUA MAY reduce its value, but MUST NOT set it to a duration
the value in the Min-SE header field in the request, if present. If lower than the value in the Min-SE header field in the request, if
the value of the Session-Expires header field is greater than or present. If the value of the Session-Expires header field is greater
equal to the value in the Min-SE header field (recall that the than or equal to the value in the Min-SE header field (recall that
default is zero when the Min-SE header field is not present), the the default is zero when the Min-SE header field is not present), the
proxy MUST NOT increase the value of the Session-Expires header 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
skipping to change at page 1, line 616 skipping to change at page 14, line 47
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. Table 2 defines how the value in the response field in the request. Table 2 defines how the value in the response
is set. A value of 'none' in the 2nd column means that there was no 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
column means that this particular combination shouldn't happen, as column means that this particular combination shouldn't happen, as
it's disallowed by the protocol. it's disallowed by the protocol.
The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and the UAC did not select who
will perform refreshes. This allows the UAS to decide whether it, or
the UAC, will perform the refreshes. However, as the table indicates,
UAC supports? refresher parameter refresher parameter UAC supports? refresher parameter refresher parameter
in request in response in request in response
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
Table 2: UAS Behavior Table 2: UAS Behavior
The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and the UAC did not select who
will perform refreshes. This allows the UAS to decide whether it, or
the UAC, will perform the refreshes. However, as the table indicates,
the UAS cannot overried the UAC's choice of refresher, if it made the UAS cannot overried the UAC's choice of refresher, if it made
one. 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
skipping to change at page 1, line 884 skipping to change at page 20, line 40
Contact: <sip:alice@pc33.atlanta.com> Contact: <sip:alice@pc33.atlanta.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)
Proxy P1 record-routes. Since the session interval is now acceptable Proxy P1 record-routes. Since the session interval is now acceptable
to it, it forwards the request to P2 (message 5). However, the to it, it forwards the request to P2 (message 5). However, the
session interval is below its minimum configured amount of 4000. So, session interval is below its minimum configured amount of 4000. So,
it rejects the request with a 422 response code (message 6), and it rejects the request with a 422 response code (message 6), and
includes a Min-SE header field with the value of 4000. Once more,
Alice retries the INVITE. This time, the Min-SE header field in her
INVITE is the maximum of all Min-SE she has received (3600 and 4000).
Message 10 might look like:
Alice Proxy P1 Proxy P2 Bob Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | | |(1) INVITE | | |
|SE: 50 | | | |SE: 50 | | |
|----------->| | | |----------->| | |
|(2) 422 | | | |(2) 422 | | |
|MSE: 3600 | | | |MSE: 3600 | | |
|<-----------| | | |<-----------| | |
|(3) ACK | | | |(3) ACK | | |
|----------->| | | |----------->| | |
|(4) INVITE | | | |(4) INVITE | | |
skipping to change at page 1, line 956 skipping to change at page 22, line 4
|SE:4000 | | | |SE:4000 | | |
|<-----------| | | |<-----------| | |
| |(22) BYE | | | |(22) BYE | |
| |<------------------------| | |<------------------------|
|(23) BYE | | | |(23) BYE | | |
|<-----------| | | |<-----------| | |
| |(24) 408 | | | |(24) 408 | |
| |------------------------>| | |------------------------>|
Figure 1: Example Session Timer Flow Figure 1: Example Session Timer Flow
includes a Min-SE header field with the value of 4000. Once more,
Alice retries the INVITE. This time, the Min-SE header field in her
INVITE is the maximum of all Min-SE she has received (3600 and 4000).
Message 10 might look like:
INVITE sip:bob@biloxi.com SIP/2.0 INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds10
Supported: timer Supported: timer
Session-Expires: 4000 Session-Expires: 4000
Min-SE: 4000 Min-SE: 4000
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.com> To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774 From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314161 INVITE CSeq: 314161 INVITE
skipping to change at page 1, line 1065 skipping to change at page 24, line 28
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
16 Normative References 16 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
protocol," Internet Draft, Internet Engineering Task Force, Feb. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
2002. Work in progress. initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[2] J. Rosenberg, "The session initiation protocol UPDATE method," [2] J. Rosenberg, "The session initiation protocol (SIP) UPDATE
Internet Draft, Internet Engineering Task Force, May 2002. Work in method," RFC 3311, Internet Engineering Task Force, Oct. 2002.
progress.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement [3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. session description protocol (SDP)," RFC 3264, Internet Engineering
Work in progress. Task Force, June 2002.
17 Informative References 17 Informative References
[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," RFC 1889, Internet transport protocol for real-time applications," RFC 1889, Internet
Engineering Task Force, Jan. 1996. Engineering Task Force, Jan. 1996.
[6] P. Srisuresh and M. Holdrege, "IP network address translator [6] P. Srisuresh and M. Holdrege, "IP network address translator
(NAT) terminology and considerations," RFC 2663, Internet Engineering (NAT) terminology and considerations," RFC 2663, Internet Engineering
Task Force, Aug. 1999. Task Force, Aug. 1999.
[7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional [7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force, responses in session initiation protocol (SIP)," RFC 3262, Internet
Feb. 2002. Work in progress. Engineering Task Force, June 2002.
[8] A. Roach, "SIP-specific event notification," Internet Draft, [8] A. B. Roach, "Session initiation protocol (sip)-specific event
Internet Engineering Task Force, Mar. 2002. Work in progress. notification," RFC 3265, Internet Engineering Task Force, June 2002.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
skipping to change at page 1, line 1124 skipping to change at line 1152
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 assigns. revoked by the Internet Society or its successors or assigns.
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.
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 4
3 Overview of Operation ............................... 4
4 Session-Expires Header Field Definition ............. 6
5 Min-SE Header Field Definition ...................... 7
6 422 Response Code Definition ........................ 8
7 UAC Behavior ........................................ 8
7.1 Generating a Session Refresh Request ................ 8
7.2 Processing a 2xx Response ........................... 10
7.3 Processing a 422 Response ........................... 11
8 Proxy Behavior ...................................... 11
8.1 Processing of Requests .............................. 11
8.2 Processing of Responses ............................. 13
8.3 Session Expiration .................................. 14
9 UAS Behavior ........................................ 14
10 Performing Refreshes ................................ 16
11 Security Considerations ............................. 16
11.1 Inside Attacks ...................................... 17
11.2 Outside Attacks ..................................... 17
12 IANA Considerations ................................. 18
12.1 IANA Registration of Min-SE and Session-Expires
Header Fields .................................................. 18
12.2 IANA Registration of the 422 (Session Interval Too
Small) Response Code ........................................... 18
12.3 IANA Registration of the "timer" Option Tag ......... 19
13 Example Call Flow ................................... 19
14 Acknowledgements .................................... 24
15 Author's Addresses .................................. 24
16 Normative References ................................ 24
17 Informative References .............................. 25
 End of changes. 

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