idnits 2.17.1 draft-ietf-sip-session-timer-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1194. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1210), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 697 has weird spacing: '...rameter refre...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2004) is 7194 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '8') (Obsoleted by RFC 6665) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP S. Donovan 2 Internet-Draft J. Rosenberg 3 Expires: January 16, 2005 dynamicsoft 4 July 18, 2004 6 Session Timers in the Session Initiation Protocol (SIP) 7 draft-ietf-sip-session-timer-15 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 16, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines an extension to the Session Initiation Protocol 41 (SIP). This extension allows for a periodic refresh of SIP sessions 42 through a re-INVITE or UPDATE request. The refresh allows both user 43 agents and proxies to determine if the SIP session is still active. 44 The extension defines two new header fields, Session-Expires, which 45 conveys the lifetime of the session, and Min-SE, which conveys the 46 minimum allowed value for the session timer. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 53 4. Session-Expires Header Field Definition . . . . . . . . . . 8 54 5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 10 55 6. 422 Response Code Definition . . . . . . . . . . . . . . . . 11 56 7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 57 7.1 Generating an Initial Session Refresh Request . . . . . . 12 58 7.2 Processing a 2xx Response . . . . . . . . . . . . . . . . 12 59 7.3 Processing a 422 Response . . . . . . . . . . . . . . . . 14 60 7.4 Generating Subsequent Session Refresh Requests . . . . . . 14 61 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 16 62 8.1 Processing of Requests . . . . . . . . . . . . . . . . . . 16 63 8.2 Processing of Responses . . . . . . . . . . . . . . . . . 17 64 8.3 Session Expiration . . . . . . . . . . . . . . . . . . . . 18 65 9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19 66 10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 22 67 11. Security Considerations . . . . . . . . . . . . . . . . . . 23 68 11.1 Inside Attacks . . . . . . . . . . . . . . . . . . . . . 23 69 11.2 Outside Attacks . . . . . . . . . . . . . . . . . . . . 24 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 71 12.1 IANA Registration of Min-SE and Session-Expires 72 Header Fields . . . . . . . . . . . . . . . . . . . . . 25 73 12.2 IANA Registration of the 422 (Session Interval Too 74 Small) Response Code . . . . . . . . . . . . . . . . . . 25 75 12.3 IANA Registration of the 'timer' Option Tag . . . . . . 25 76 13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 26 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 15.1 Normative References . . . . . . . . . . . . . . . . . . . 32 80 15.2 Informative References . . . . . . . . . . . . . . . . . . 32 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 82 Intellectual Property and Copyright Statements . . . . . . . 34 84 1. Introduction 86 The Session Initiation Protocol (SIP) [2], does not define a 87 keepalive mechanism for the sessions it establishes. Although the 88 user agents may be able to determine if the session has timed out 89 using session specific mechanisms, proxies will not be able to do so. 90 The result is that call stateful proxies will not always be able to 91 determine whether a session is still active or not. For instance, 92 when a user agent fails to send a BYE message at the end of a 93 session, or the BYE message gets lost due to network problems, a call 94 stateful proxy will not know when the session has ended. In this 95 situation, the call stateful proxy will retain state for the call and 96 has no deterministic method of determining when the call state 97 information no longer applies. 99 To resolve this problem, this extension defines a keepalive mechanism 100 for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests 101 (referred to as session refresh requests) to keep the session alive. 102 The interval for the session refresh requests is determined through a 103 negotiation mechanism defined here. If a session refresh request is 104 not received before the interval passes, the session is considered 105 terminated. Both UAs are supposed to send a BYE, and call stateful 106 proxies can remove any state for the call. 108 This refresh mechanism has additional applications. For the same 109 reasons a call stateful proxy server would like to determine whether 110 the session is still active, a user agent would like to make this 111 determination. This determination can be made at a user agent 112 without the use of SIP level mechanisms; for audio sessions, periodic 113 RTCP packets serve as an indication of liveness [5]. However, it is 114 desirable to separate SIP session liveness from the details of the 115 particular session. 117 Another application of the session timer is in the construction of a 118 SIP Network Address Translator (NAT) Application Level Gateway (ALG) 119 [6]. The ALG embedded in a NAT will need to maintain state for the 120 duration of a call. This state must eventually be removed. Relying 121 on a BYE to trigger the removal of state, besides being unreliable, 122 introduces a potential denial of service attack. 124 This document provides an extension to SIP that defines a session 125 expiration mechanism. Periodic refreshes, through re-INVITEs or 126 UPDATEs, are used to keep the session active. The extension is 127 sufficiently backwards compatible with SIP that it works so long as 128 either one of the two participants in a dialog understand the 129 extension. Two new header fields, Session-Expires and Min-SE, and a 130 new response code, 422, are defined. Session-Expires conveys the 131 duration of the session, and Min-SE conveys the minimum allowed value 132 for the session expiration. The 422 response code indicates that the 133 session timer duration was too small. 135 2. Terminology 137 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 138 'SHALL', 'SHALLNOT', 'SHOULD', 'SHOULDNOT', 'RECOMMENDED', 'MAY', and 139 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and 140 indicate requirement levels for compliant SIP implementations. 142 Additionally, we define the following terms: 143 Session Interval: The largest amount of time that can occur between 144 session refresh requests in a dialog before the session will be 145 considered timed out. The session interval is conveyed in the 146 Session-Expires header field defined here. The UAS obtains this 147 value from the Session-Expires header field in a 2xx response to a 148 session refresh request that it sends. Proxies and UACs determine 149 this value from the Session-Expires header field in a 2xx response 150 to a session refresh request that they receive. 151 Minimum Timer: Because of the processing load of mid-dialog requests, 152 all elements (proxy, UAC, UAS) can have a configured minimum value 153 for the session interval that they are willing to accept. This 154 value is called the minimum timer. 155 Session Expiration: The time at which an element will consider the 156 session timed out, if no successful session refresh transaction 157 occurs beforehand. 158 Session Refresh Request: An INVITE or UPDATE request processed 159 according to the rules of this specification. If the request 160 generates a 2xx response, the session expiration is increased to 161 the current time plus the session interval obtained from the 162 response. A session refresh request is not to be confused with a 163 target refresh request, defined in Section 6 of [2], which is a 164 request that can update the remote target of a dialog. 165 Initial Session Refresh Request: The first session refresh request 166 sent with a particular Call-ID value. 167 Subsequent Session Refresh Request: Any session refresh request sent 168 with a particular Call-ID after the initial session refresh 169 request. 170 Refresh: Same as a session refresh request. 172 3. Overview of Operation 174 This section provides a brief overview of operation of the extension. 175 It is tutorial in nature and should not be considered as normative. 177 This extension has the property that it works even when only one UA 178 in a dialog supports it. The processing steps differ for handling 179 each of the four cases (UAC supports it, or doesn't, and UAS supports 180 it, or doesn't). For simplicity's sake, this section will describe 181 basic operation in the case where both sides support the extension. 183 A UAC starts by sending an INVITE. It includes a Supported header 184 field with the option tag 'timer', indicating support for this 185 extension. 187 This request passes through proxies, any one of which may have an 188 interest in establishing a session timer. Each proxy can insert a 189 Session-Expires header field and a Min-SE header field into the 190 request if none is already there or alter the value of existing 191 Session-Expires and Min-SE header fields as described below. 193 The Min-SE header field establishes the lower bound for the session 194 refresh interval, i.e. the fastest rate that any proxy servicing 195 this request will be allowed to require. The purpose of this header 196 field is to prevent hostile proxies from setting arbitrarily short 197 refresh intervals such that their neighbors are overloaded. Each 198 proxy processing the request can raise this lower bound (increase the 199 period between refreshes) but is not allowed to lower it. 201 The Session-Expires header field establishes the upper bound for the 202 session refresh interval, i.e., the time period after processing a 203 request for which any session-stateful proxy must retain its state 204 for this session. Any proxy servicing this request can lower this 205 value, but is not allowed to decrease it below the value specified in 206 the Min-SE header field. 208 If the Session-Expires interval is too low for a proxy (i.e, lower 209 than the value of Min-SE that the proxy would wish to assert), the 210 proxy rejects the request with a 422 response. That response 211 contains a Min-SE header field, identifying the minimum session 212 interval it is willing to support. The UAC will try again, this time 213 including the Min-SE header in the request. The header field 214 contains the largest Min-SE header field it observed in all 422 215 responses received previously. This way, the minimum timer meets the 216 constraints of all proxies along the path. 218 After several INVITE/422 iterations, the request eventually arrives 219 at the UAS. The UAS can adjust the value of the session interval as 220 if it was a proxy, and when done, it places the final session 221 interval into the Session-Expires header field in a 2xx response. 222 The Session-Expires header field also contains a 'refresher' 223 parameter, which indicates who is doing the refreshing - the UA that 224 is currently the UAC, or the UA that is currently the UAS. As the 225 2xx response travels back through the proxy chain, each proxy can 226 observe the final session interval, but they can't change it. 228 From the Session-Expires header field in the response, both UAs know 229 that a session timer is active, they know when it will expire, and 230 they know who is refreshing. At some point before the expiration, 231 the currently active refresher generates a session refresh request, 232 which is a re-INVITE or UPDATE [3] request. If the refresher never 233 gets a response to that session refresh request, it sends a BYE to 234 terminate the session. Similarly, if the other side never gets the 235 session refresh request before the session expires, it sends a BYE. 237 The refresh requests sent once the session is established are 238 processed identically to the initial requests, as described above. 239 This means that a successful session refresh request will extend the 240 session, as desired. 242 The extension introduces additional complications beyond this basic 243 flow to support cases where only one of the UAs supports it. One 244 such complication is that a proxy may need to insert the 245 Session-Expires header into the response, in the event that the UAS 246 doesn't support the extension. The negotiation of the role of 247 refresher is also affected by this capability; it takes into 248 consideration which participants support the extension. 250 It is worth noting that the session timer refreshes the session, not 251 the dialog used to establish the session. Of course, the two are 252 related. If the session expires, a BYE is sent, which terminates the 253 session and generally, the dialog. 255 4. Session-Expires Header Field Definition 257 The Session-Expires header field conveys the session interval for a 258 SIP session. It is placed only in INVITE or UPDATE requests, as well 259 as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires 260 header field, it contains a delta-time. 262 The absolute minimum for the Session-Expires header field is 90 263 seconds. This value represents a bit more than twice the duration 264 that a SIP transaction can take in the event of a timeout. This 265 allows sufficient time for a UA to attempt a refresh at the halfpoint 266 of the session interval, and for that transaction to complete 267 normally before the session expires. However, 1800 seconds (30 268 minutes) is RECOMMENDED as the value for the Session-Expires header 269 field. In other words, SIP entities MUST be prepared to handle 270 Session-Expires header field values of any duration greater than 90 271 seconds, but entities that insert the Session-Expires header field 272 SHOULD NOT choose values less than 30 minutes. 274 Small session intervals can be destructive to the network. They 275 cause excessive messaging traffic that affects both user agents and 276 proxy servers. They increase the possibility of 'glare' that can 277 occur when both user agents send a re-INVITE or UPDATE at the same 278 time. Since the primary purpose of the session timer is to provide a 279 means to time out state in SIP elements, very small values won't 280 generally be needed. 30-minutes was chosen since 95% of phone calls 281 are less than this duration. However, the 30 minute minimum is 282 listed as a SHOULD, and not a MUST, since the exact value for this 283 number is dependent on many network factors, including network 284 bandwidths and latencies, computing power, memory availability, 285 network topology, and of course, the application scenario. After 286 all, SIP can set up any kind of session, not just a phone call. At 287 the time of publication of this document, 30 minutes seems 288 appropriate. Advances in technologies may result in the number being 289 excessively large five years in the future. 291 The default value of the Session-Expires header field is undefined. 292 This means that absence of the Session-Expires header field implies 293 no expiration of the session using the mechanism defined in this 294 specification. Note that other mechanisms not defined in this 295 specification, such as locally configured timers, may apply. 297 The syntax of the Session-Expires header field is: 299 Session-Expires = ('Session-Expires' / 'x') HCOLON delta-seconds 300 *(SEMI se-params) 301 se-params = refresher-param / generic-param 302 refresher-param = 'refresher' EQUAL ('uas' / 'uac') 303 Note that a compact form, the letter x, has been reserved for 304 Session-Expires. The BNF for delta-seconds and generic-param is 305 defined in Section 25 of RFC 3261 [2]. 307 Table 1 is an extension of Tables 2 and 3 in [2] for the 308 Session-Expires and Min-SE header fields. The column 'PRA' is for 309 the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is 310 for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8]. 312 +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 313 | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| 314 +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 315 |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | 316 | | | | | | | | | | | | | | 317 |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | 318 | | | | | | | | | | | | | | 319 |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | 320 | | | | | | | | | | | | | | 321 |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | 322 +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 323 Table 1 Session-Expires and Min-SE Header Fields 325 5. Min-SE Header Field Definition 327 The Min-SE header field indicates the minimum value for the session 328 interval, in units of delta-seconds. When used in an INVITE or 329 UPDATE request, it indicates the smallest value of the session 330 interval that can be used for that session. When present in a 331 request or response, its value MUST NOT be less than 90 seconds. 333 When not present, the default value for this header field is 90 334 seconds. 336 The Min-SE header field MUST NOT be used in responses except those 337 with a 422 response code. It indicates the minimum value of the 338 session interval that the server is willing to accept. 340 The syntax of the Min-SE header field is: 342 Min-SE = 'Min-SE' HCOLON delta-seconds *(SEMI generic-param) 344 6. 422 Response Code Definition 346 This extension introduces the 422 (Session Interval Too Small) 347 response code. It is generated by a UAS or proxy when a request 348 contains a Session-Expires header field with a duration that is below 349 the minimum timer for the server. The 422 response MUST contain a 350 Min-SE header field with the minimum timer for that server. 352 7. UAC Behavior 354 7.1 Generating an Initial Session Refresh Request 356 A UAC that supports the session timer extension defined here MUST 357 include a Supported header field in each request (except ACK), 358 listing the option tag 'timer' [2]. It MUST do so even if the UAC is 359 not requesting usage of the session timer for this session. 361 The UAC MAY include a Require header field in the request with the 362 value 'timer' to indicate that the UAS must support the session timer 363 to participate in the session. This does not mean that the UAC is 364 requiring the UAS to perform the refreshes, just that it is requiring 365 the UAS to support the extension. In addition, the UAC MAY include a 366 Proxy-Require header field in the request with the value 'timer' to 367 indicate that proxies must support session timer in order to 368 correctly process the request. However, usage of either Require or 369 Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, 370 since the extension works even when only the UAC supports the 371 extension. The Supported header field containing 'timer' MUST still 372 be included even if the Require or Proxy-Require header fields are 373 present containing 'timer'. 375 A UAC MAY include the Min-SE header field in the initial INVITE 376 request. 378 A UAC MAY include a Session-Expires header field in an initial 379 session refresh request if it wishes for a session timer to be 380 applied to the session. The value of this header field indicates the 381 session interval desired by the UAC. If a Min-SE header is included 382 in the initial session refresh request, the value of the 383 Session-Expires MUST be greater than the value in Min-SE. 385 The UAC MAY include the refresher parameter with value 'uac' if it 386 wishes to perform the refreshes. However, it is RECOMMENDED that the 387 parameter be omitted, so that it can be selected by the negotiation 388 mechanisms described below. 390 7.2 Processing a 2xx Response 392 Session timer requires a UA to create and maintain state. This state 393 includes the session interval, the session expiration, and the 394 identity of the refresher. This state is associated with the dialog 395 on which the session has been negotiated. 397 When a 2xx response to a session refresh request arrives, it may or 398 may not contain a Require header field with the value 'timer'. If it 399 does, the UAC MUST look for the Session-Expires header field to 400 process the response. 402 If there was a Require header field in the response with the value 403 'timer', the Session-Expires header field will always be present. 404 UACs MUST be prepared to receive a Session-Expires header field in a 405 response even if none were present in the request. The 'refresher' 406 parameter will be present in the Session-Expires header field, 407 indicating who will be performing the refreshes. The UAC MUST set 408 the identity of the refresher to the value of this parameter. If the 409 parameter contains the value 'uac', the UAC will perform them. It is 410 possible that the UAC requested session timer (and thus included a 411 Session-Expires header field in the request), but there was no 412 Require or Session-Expires header field in the 2xx response. This 413 will happen when the UAS doesn't support the session timer extension, 414 and only the UAC has asked for a session timer (no proxies have 415 requested it). In this case, if the UAC still wishes to use the 416 session timer (they are purely for its benefit alone), it has to 417 perform them. To do this, the UAC follows the procedures defined in 418 this specification as if the Session-Expires header field were in the 419 2xx response, and its value was the same as the one in the request, 420 but with a refresher parameter of 'uac'. 422 If the 2xx response did not contain a Session-Expires header field, 423 there is no session expiration. In this case, no refreshes need to 424 be sent. A 2xx without a Session-Expires can come for both initial 425 and subsequent session refresh requests. This means that the session 426 timer can be 'turned-off' mid dialog by receiving a response without 427 a Session-Expires header. 429 The UAC remembers the session interval for a session as the value of 430 the delta-time from the Session-Expires header field in the most 431 recent 2xx response to a session refresh request on a dialog. It is 432 explicitly allowed for there to be differing session intervals (or 433 none at all) on differing dialogs established as a result of a single 434 INVITE. It also remembers whether it, or its peer, is the refresher 435 on for the session. 437 If the UAC must perform the refreshes, it computes the session 438 expiration for that session. The session expiration is the time of 439 reception of the last 2xx response to a session refresh request on 440 that dialog plus the session interval for that session. If UA wishes 441 to continue with the session beyond the session expiration, it MUST 442 generate a refresh before the session expiration. It is RECOMMENDED 443 that this refresh be sent once half the session interval has elapsed. 444 Additional procedures for this refresh are described in Section 10. 446 7.3 Processing a 422 Response 448 If the response to a session refresh request is a 422 (Session 449 Interval Too Small) response message, then the UAC MAY retry the 450 request. The procedures for retrying are described in Section 7.4. 451 This new request constitutes a new transaction and SHOULD have the 452 same value of the Call-ID, To, and From of the previous request, but 453 the CSeq should contain a new sequence number that is one higher than 454 the previous. 456 7.4 Generating Subsequent Session Refresh Requests 458 The values of Supported, Require and Proxy-Require used in the 459 initial Session refresh request MUST be used. 461 The UAC MUST insert the Min-SE header field into a session refresh 462 request for a particular dialog if it has ever received a 422 463 response to a previous session refresh request on the same dialog, or 464 if it has received a session refresh request on that dialog which 465 contained a Min-SE header field. Similarly, if no dialog has been 466 established yet, a UAC MUST insert the Min-SE header field into an 467 INVITE request if it has ever received a 422 response to a previous 468 INVITE request with the same Call-ID. 470 The value of the Min-SE header field present in a session refresh 471 request MUST be the largest value amongst all Min-SE header field 472 values returned in all 422 responses, or received in session refresh 473 requests, on the same dialog, if a dialog has been established. If 474 no dialog has been established, the Min-SE header field value is set 475 to the largest value amongst all Min-SE header field values returned 476 in all 422 responses for an INVITE request with the same Call-ID. A 477 result of this rule is that the maximum value of the Min-SE is 478 effectively 'cleared' once the dialog is established, and from that 479 point on, only the values from proxies known to be on the proxy path 480 will end up being used. 482 The UAC may have its own opinions about the minimum session interval. 483 In that case, if the value above is too small, the UAC MAY increase 484 it. 486 In a session refresh request sent within a dialog with an active 487 session timer, the Sesssion-Expires header field SHOULD be present. 488 When present, it SHOULD be equal to the maximum of the Min-SE header 489 field (recall that its default value when not present is 90 seconds) 490 and the current session interval. Inclusion of the Session-Expires 491 header field with this value avoids certain denial-of-service 492 attacks, as documented in Section 11. As such, a UA should only 493 ignore the SHOULD in unusual and singular cases where it is 494 desireable to change the session interval mid-dialog. 496 If the session refresh request is not the initial one, it is 497 RECOMMENDED that the refresher parameter be set to 'uac' if the 498 element sending the request is currently performing refreshes, else 499 'uas' if its peer is performing the refreshes. This way, the role of 500 refresher does not change on each refresh. However, if it wishes to 501 explicitly change the roles, it MAY use a value of 'uas' if it knows 502 that the other side supports session timer. It could know this by 503 having received a request from its peer with a Supported header field 504 containing the value 'timer'. If it wishes to reselect the roles, it 505 MAY omit the parameter. 507 A re-INVITE generated to refresh the session is a normal re-INVITE, 508 and an UPDATE generated to refresh a session is a normal UPDATE. If 509 a UAC knows that its peer supports the UPDATE method, it is 510 RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can 511 make this determination if it has seen an Allow header field from its 512 peer with the value 'UPDATE', or through a mid-dialog OPTIONS 513 request. It is RECOMMENDED that the UPDATE request not contain an 514 offer [4], but a re-INVITE SHOULD contain one, even if the details of 515 the session have not changed. In that case, the offer MUST indicate 516 that it has not changed. In the case of SDP, this is accomplished by 517 including the same value for the origin field as previous SDP 518 messages to its peer. The same is true for an answer exchanged as a 519 result of a session refresh request; if it has not changed, that MUST 520 be indicated. 522 8. Proxy Behavior 524 Session timers are mostly of interest to call stateful proxy servers 525 (that is, servers that maintain the state of calls and dialogs 526 established through them). However, a stateful proxy server (that 527 is, a server which is aware of transaction state, but does not retain 528 call or dialog state) MAY also follow the rules described here. 529 Stateless proxies MUST NOT attempt to request session timers. 530 Proxies that ask for session timers SHOULD record-route, since they 531 won't receive refreshes if they don't. 532 The proxy processing rules require the proxy to remember 533 information between the request and response, ruling out stateless 534 proxies. 536 8.1 Processing of Requests 538 Processing of requests is identical for all session refresh requests. 540 To request a session timer for a session, a proxy makes sure that a 541 Session-Expires header field is present in a session refresh request 542 for that session. A proxy MAY insert a Session-Expires header field 543 in the request before forwarding it, if none was present in the 544 request. This Session-Expires header field may contain any desired 545 expiration time the proxy would like, but not with a duration lower 546 than the value in the Min-SE header field in the request, if present. 547 The proxy MUST NOT include a refresher parameter in the header field 548 value. 550 If the request already had a Session-Expires header field, the proxy 551 MAY reduce its value, but MUST NOT set it to a duration lower than 552 the value in the Min-SE header field in the request, if present. If 553 the value of the Session-Expires header field is greater than or 554 equal to the value in the Min-SE header field (recall that the 555 default is 90 seconds when the Min-SE header field is not present), 556 the proxy MUST NOT increase the value of the Session-Expires header 557 field. If the value of the Session-Expires header field is lower 558 than the value of the Min-SE header field (possibly because the proxy 559 increased the value of the Min-SE header field, as described below), 560 the proxy MUST increase the value of the Session-Expires header field 561 to make it equal to Min-SE header field value. The proxy MUST NOT 562 insert or modify the value of the 'refresher' parameter in the 563 Session-Expires header field. 565 If the request contains a Supported header field with a value 566 'timer', the proxy MAY reject the INVITE request with a 422 (Session 567 Interval Too Small) response if the session interval in the 568 Session-Expires header field is smaller than the minimum interval 569 defined by the proxy's local policy. When sending the 422 response, 570 the proxy MUST include a Min-SE header field with the value of its 571 minimum interval. That minimum MUST NOT be lower than 90 seconds. 573 If the request doesn't indicate support for session timer, but the 574 request contains a session interval that is too small, the proxy 575 cannot usefully reject the request, as this would result in a call 576 failure. Rather, the proxy SHOULD insert a Min-SE header field 577 containing its minimum interval. If a Min-SE header field is already 578 present, the proxy SHOULD increase (but MUST NOT decrease) the value 579 to equal its minimum interval. The proxy MUST then increase the 580 Session-Expires header field value to be equal to the value in the 581 Min-SE header field, as described above. A proxy MUST NOT insert a 582 Min-SE header field, or modify the value of an existing header field, 583 in a proxied request if that request contains a Supported header 584 field with the value 'timer'. This is needed to protect against 585 certain denial of service attacks, described in Section 11. 587 Assuming the proxy has requested a session timer (and thus has 588 possibly inserted the Session-Expires header field or reduced it), 589 the proxy MUST remember that it is using a session timer, and also 590 remember the value of the Session-Expires header field from the 591 proxied request. This MUST be remembered for the duration of the 592 transaction. The proxy MUST remember, for the duration of the 593 transaction, whether the request contained the Supported header field 594 with the value 'timer'. 596 If the request did not contain a Supported header field with the 597 value 'timer', the proxy MAY insert a Require header field into the 598 request, with the value 'timer'. However, this is NOT RECOMMENDED. 599 This allows the proxy to insist on session timer for the session. 600 This header field is not needed if a Supported header field was in 601 the request; in this case, the proxy can already be sure that the 602 session timer can be used for the session. 604 8.2 Processing of Responses 606 When the final response to the request arrives, it is examined by the 607 proxy. 609 If the response does not contain a Session-Expires header field, but 610 the proxy remembers that it requested a session timer in the request 611 (by inserting, modifying, or examining and accepting the 612 Session-Expires header field in the proxied request), this means that 613 the UAS did not support the session timer. If the proxy remembers 614 that the UAC did not support session timer either, the proxy forwards 615 the response upstream normally. There is no session expiration for 616 this session. If, however, the proxy remembers that the UAC did 617 support session timer, additional processing is needed. 619 Because there is no Session-Expires or Require header field in the 620 response, the proxy knows it is the first session-timer-aware proxy 621 to receive the response. This proxy MUST insert a Session-Expires 622 header field into the response with the value it remembered from the 623 forwarded request. It MUST set the value of the 'refresher' 624 parameter to 'uac'. The proxy MUST insert the Require header field 625 into the response, with the value 'timer', before forwarding it 626 upstream. 628 If the received response contains a Session-Expires header field, no 629 modification of the response is needed. 631 In all cases, if the 2xx response forwarded upstream by the proxy 632 contains a Session-Expires header field, its value represents the 633 session interval for the session associated with that response. The 634 proxy computes the session expiration as the time when the 2xx 635 response is forwarded upstream, plus the session interval. This 636 session expiration MUST update any existing session expiration for 637 the session. The refresher parameter in the Session-Expires header 638 field in the 2xx response forwarded upstream will be present, and it 639 indicates which UA is performing the refreshes. There can be 640 multiple 2xx responses to a single INVITE, each representing a 641 different dialog, resulting in multiple session expirations, one for 642 each session associated with each dialog. 644 The proxy MUST NOT modify the value of the Session-Expires header 645 field received in the response (assuming one was present) before 646 forwarding it upstream. 648 8.3 Session Expiration 650 When the current time equals or passes the session expiration for a 651 session, the proxy MAY remove associated call state, and MAY free any 652 resources associated with the call. Unlike the UA, it MUST NOT send 653 a BYE. 655 9. UAS Behavior 657 The UAS must respond to a request for a session timer by the UAC or a 658 proxy in the path of the request, or it may request that a session 659 Timer be used itself. 661 If an incoming request contains a Supported header field with a value 662 'timer' and a Session Expires header, the UAS MAY reject the INVITE 663 request with a 422 (Session Interval Too Small) response if the 664 session interval in the Session-Expires header field is smaller than 665 the minimum interval defined by the UAS' local policy. When sending 666 the 422 response, the UAS MUST include a Min-SE header field with the 667 value of its minimum interval. This minimum interval MUST NOT be 668 lower than 90 seconds. 670 If the UAS wishes to accept the request, it copies the value of the 671 Session-Expires header field from the request into the 2xx response. 672 The UAS response MAY reduce its value, but MUST NOT set it to a 673 duration lower than the value in the Min-SE header field in the 674 request, if present, else 90s if not. The UAS MUST NOT increase the 675 value of the Session-Expires header field. 677 If the incoming request contains a Supported header field with a 678 value 'timer' but does not contain a Session-Expires header, the UAC 679 indicated support for timers, but did not request one. The UAS may 680 request a session timer in the 2XX response by including a 681 Session-Expires header field. The value MUST NOT be set to a 682 duration lower than the value in the Min-SE header field in the 683 request, if present. 685 The UAS MUST set the value of the refresher parameter in the 686 Session-Expires header field in the 2xx response. This value 687 specifies who will perform refreshes for the dialog. The value is 688 based on the value of this parameter in the request, and on whether 689 the UAC supports the session timer extension. The UAC supports the 690 extension if the 'timer' option tag was present in a Supported header 691 field in the request. Figure 3 defines how the value in the response 692 is set. A value of 'none' in the 2nd column means that there was no 693 refresher parameter in the request. A value of 'NA' in the third 694 column means that this particular combination shouldn't happen, as 695 it's disallowed by the protocol. 697 UAC supports? refresher parameter refresher parameter 698 in request in response 699 ------------------------------------------------------- 700 N none uas 701 N uac NA 702 N uas NA 703 Y none uas or uac 704 Y uac uac 705 Y uas uas 707 Figure 3: UAS Behavior 709 The fourth row of Figure 3 describes a case where both the UAC and 710 UAS support the session timer extension, and the UAC did not select 711 who will perform refreshes. This allows the UAS to decide whether 712 it, or the UAC, will perform the refreshes. However, as the table 713 indicates, the UAS cannot override the UAC's choice of refresher, if 714 it made one. 716 If the refresher parameter in the Session-Expires header field in the 717 2xx response has a value of 'uac', the UAS MUST place a Require 718 header field into the response with the value 'timer'. This is 719 because the uac is performing refreshes and the response has to be 720 processed for the UAC to know this. If the refresher parameter in 721 the 2xx response has a value of 'uas', and the Supported header field 722 in the request contained the value 'timer', the UAS SHOULD place a 723 Require header field into the response with the value 'timer'. In 724 this case, the UAC is not refreshing, but it is supposed to send a 725 BYE if it never receives a refresh. Since the call will still 726 succeed without the UAC doing this, insertion of the Require is a 727 SHOULD here, rather than a MUST. 729 The UAS, just like the UAC, stores state for the session timer. This 730 state includes the session interval, the session expiration, and the 731 identity of the refresher. This state is bound to the dialog used to 732 set up the session. The session interval is set to the value of the 733 delta-time from the Session-Expires header field in the most recent 734 2xx response to a session refresh request on that dialog. It also 735 remembers whether it, or its peer, is the refresher on the leg, based 736 on the value of the refresher parameter from the most recent 2xx 737 response to a session refresh request on that dialog. If the most 738 recent 2xx response had no Session-Expires header field, there is no 739 session expiration, and no refreshes need to be performed. 741 If the UAS must refresh the session, it computes the session 742 expiration. The session expiration is the time of transmission of 743 the last 2xx response to a session refresh request on that dialog 744 plus the session interval. If UA wishes to continue with the session 745 beyond the session expiration, it MUST generate a refresh before the 746 session expiration. It is RECOMMENDED that this refresh be sent once 747 half the session interval has elapsed. Additional procedures for 748 this refresh are described in Section 10. 750 10. Performing Refreshes 752 The side generating a refresh does so according to the UAC procedures 753 defined in Section 7. Note that only a 2xx response to a session 754 refresh request extends the session expiration. This means that a UA 755 could attempt a refresh, and receive a 422 response with a Min-SE 756 header field that contains a value much larger than the current 757 session interval. The UA will still need to send a session refresh 758 request before the session expiration (which has not changed), even 759 though this request will contain a value of the Session-Expires that 760 is much larger than the current session interval. 762 If the session refresh request transaction times out or generates a 763 408 or 481 response, then the UAC sends a BYE request per the rules 764 in Section 12.2.1.2 of RFC 3261 [2]. If the session refresh request 765 does not generate a 2xx response (and, as a result, the session is 766 not refreshed), and a response other than 408 or 481 is received, the 767 UAC SHOULD follow the rules specific to that response code, and retry 768 if possible. For example, if the response is a 401, the UAC would 769 retry the request with new credentials. However, the UAC SHOULD NOT 770 continuously retry the request if the server indicates the same error 771 response. 773 Similarly, if the side not performing refreshes does not receive a 774 session refresh request before the session expiration, they SHOULD 775 send a BYE to terminate the session, slightly before the session 776 expiration. The minimum of 32 seconds and one third the session 777 interval is RECOMMENDED. 778 Firewalls and NAT ALGs may be very unforgiving about allowing SIP 779 traffic to pass after the expiration time of the session. It is 780 for this reason that the BYE should be sent before the expiration. 782 11. Security Considerations 784 The session timer introduces the capability of a proxy or UA element 785 to force compliant UAs to send refreshes at a rate of the element's 786 choosing. This introduces the possibility of denial-of-service 787 attacks with significant amplification properties. These attacks can 788 be launched from 'outsiders' - elements that attempt to modify 789 messages in transit, or by 'insiders' - elements which are 790 legitimately in the request path, but are intent on doing harm. 791 Fortunately, both cases are adequately handled by this specification. 793 11.1 Inside Attacks 795 This introduces the possibility of rogue proxies or UAs introducing 796 denial-of-service attacks. However, the mechanisms in this 797 specification prevent that from happening. 799 First, consider the case of a rogue UAC that wishes to force a UAS to 800 generate refreshes at a rapid rate. To do so, it inserts a 801 Session-Expires header field into an INVITE with a low duration and a 802 refresher parameter equal to uas. Assume it places a Supported 803 header field into the request. Any proxy, or the UAS, which objects 804 to this low timer will reject the request with a 422, therefore 805 preventing the attack. If no Supported header field was present, the 806 proxies will insert a Min-SE header field into the request before 807 forwarding it. As a result, the UAS will not choose a session timer 808 lower than the minimum acceptable one to all elements on the path. 809 This too prevents the attack. 811 Next, consider the case of a rogue UAS that wishes to force a UAC to 812 generate refreshes at a rapid rate. In that case, the UAC has to 813 support session timer. The initial INVITE arrives at the rogue UAS, 814 which returns a 2xx with a very small session interval. The UAC uses 815 this timer, and quickly sends a refresh. Section 7.4 requires the 816 UAC to copy the current session interval into the Session-Expires 817 header field in the request. This enables the proxies to see the 818 current value. The proxies will reject this request, and provide a 819 Min-SE with a higher minimum. The UAC will then use this higher 820 minimum. Note, that if the proxies did not reject the request, but 821 rather proxied the request with a Min-SE header field, an attack 822 would still be possible. The UAS could discard this header field in 823 a 2xx response, and force the UAC to continue to generate rapid 824 requests. 826 In a similar fashion, a rogue proxy cannot force either the UAC or 827 UAS to generate refreshes unless the proxy remains on the signaling 828 path, and sees every request and response. 830 11.2 Outside Attacks 832 An element that can observe and modify a request or response in 833 transit can force rapid session refreshes. To prevent that, requests 834 and responses need to be protected by message integrity. Since the 835 session timer headers are not end-to-end, and are manipulated by 836 proxies, the SIP S/MIME capabilities are not suitable for this task. 837 Rather, integrity needs to be protected using hop-by-hop mechanisms. 838 As a result, it is RECOMMENDED that an element that sends a request 839 with a Session-Expires header field, or a Supported header field with 840 the value 'timer', do so using TLS. Since adequate protection is 841 obtained only if security is applied on each hop, it is RECOMMENDED 842 that the SIPS URI scheme be used in conjunction with this extension. 843 This means that proxies that record-route and request session timer, 844 SHOULD record-route with a SIPS URI. A UA that inserts a 845 Session-Expires header into a request or response SHOULD include a 846 Contact URI that is a SIPS URI. 848 12. IANA Considerations 850 This extension defines two new header fields, a new response code, 851 and a new option tag. SIP [2] defines IANA procedures for 852 registering these. 854 12.1 IANA Registration of Min-SE and Session-Expires Header Fields 856 The following is the registration for the Min-SE header field: 857 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 858 this specification.] 859 Header Name: Min-SE 860 Compact Form: none 862 The following is the registration for the Session-Expires header 863 field: 864 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 865 this specification.] 866 Header Name: Session-Expires 867 Compact Form: x 869 12.2 IANA Registration of the 422 (Session Interval Too Small) Response 870 Code 872 The following is the registration for the 422 (Session Interval Too 873 Small) response code: 874 Response Code: 422 875 Default Reason Phrase: Session Interval Too Small 876 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 877 this specification.] 879 12.3 IANA Registration of the 'timer' Option Tag 881 The following is the registration for the 'timer' option tag: 883 Name: timer 884 Description: This option tag is for support of the session timer 885 extension. Inclusion in a Supported header field in a request or 886 response indicates that the UA is capable of performing refreshes 887 according to that specification. Inclusion in a Require header in 888 a request means that the UAS must understand the session timer 889 extension to process the request. Inclusion in a Require header 890 field in a response indicates that the UAC must look for the 891 Session-Expires header field in the response, and process 892 accordingly. 894 13. Example Call Flow 896 Example Session Timer Flow 898 Alice Proxy P1 Proxy P2 Bob 899 |(1) INVITE | | | 900 |SE: 50 | | | 901 |----------->| | | 902 |(2) 422 | | | 903 |MSE: 3600 | | | 904 |<-----------| | | 905 |(3) ACK | | | 906 |----------->| | | 907 |(4) INVITE | | | 908 |SE:3600 | | | 909 |MSE:3600 | | | 910 |----------->| | | 911 | |(5) INVITE | | 912 | |SE:3600 | | 913 | |MSE:3600 | | 914 | |----------->| | 915 | |(6) 422 | | 916 | |MSE:4000 | | 917 | |<-----------| | 918 | |(7) ACK | | 919 | |----------->| | 920 |(8) 422 | | | 921 |MSE:4000 | | | 922 |<-----------| | | 923 |(9) ACK | | | 924 |----------->| | | 925 |(10) INVITE | | | 926 |SE:4000 | | | 927 |MSE:4000 | | | 928 |----------->| | | 929 | |(11) INVITE | | 930 | |SE:4000 | | 931 | |MSE:4000 | | 932 | |----------->| | 933 | | |(12) INVITE | 934 | | |SE:4000 | 935 | | |MSE:4000 | 936 | | |----------->| 937 | | |(13) 200 OK | 938 | | |SE:4000 | 939 | | |<-----------| 940 | |(14) 200 OK | | 941 | |SE:4000 | | 942 | |<-----------| | 943 |(15) 200 OK | | | 944 |SE:4000 | | | 945 |<-----------| | | 946 |(16) ACK | | | 947 |----------->| | | 948 | |(17) ACK | | 949 | |------------------------>| 950 |(18) UPDATE | | | 951 |SE:4000 | | | 952 |----------->| | | 953 | |(19) UPDATE | | 954 | |SE:4000 | | 955 | |------------------------>| 956 | |(20) 200 OK | | 957 | |SE:4000 | | 958 | |<------------------------| 959 |(21) 200 OK | | | 960 |SE:4000 | | | 961 |<-----------| | | 962 | |(22) BYE | | 963 | |<------------------------| 964 |(23) BYE | | | 965 |<-----------| | | 966 | |(24) 408 | | 967 | |------------------------>| 968 Figure 1: Example Session Timer Flow 970 Figure 1 gives an example of a call flow that makes use of the 971 session timer. In this example, both the UAC and UAS support the 972 session timer extension. The initial INVITE request generated by the 973 UAC, Alice (message 1), might look like: 975 INVITE sips:bob@biloxi.example.com SIP/2.0 976 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 977 Supported: timer 978 Session-Expires: 50 979 Max-Forwards: 70 980 To: Bob 981 From: Alice ;tag=1928301774 982 Call-ID: a84b4c76e66710 983 CSeq: 314159 INVITE 984 Contact: 985 Content-Type: application/sdp 986 Content-Length: 142 988 (Alice's SDP not shown) 989 This request indicates that Alice supports the session timer, and is 990 request session refreshes every 50 seconds. This arrives at the 991 first proxy, P1. This session interval is below the minimum allowed 992 value of 3600. So, P1 rejects the request with a 422 (message 2): 994 SIP/2.0 422 Session Interval Too Small 995 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 996 ;received=192.0.2.1 997 Min-SE: 3600 998 To: Bob ;tag=9a8kz 999 From: Alice ;tag=1928301774 1000 Call-ID: a84b4c76e66710 1001 CSeq: 314159 INVITE 1003 This response contains a Min-SE header field with the value of 3600. 1004 Alice then retries the request. This time, the request contains a 1005 Min-SE header, since Alice has received a 422 for other INVITE 1006 requests with the same Call-ID. The new request (message 4) might 1007 look like: 1009 INVITE sips:bob@biloxi.example.com SIP/2.0 1010 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1011 Supported: timer 1012 Session-Expires: 3600 1013 Min-SE: 3600 1014 Max-Forwards: 70 1015 To: Bob 1016 From: Alice ;tag=1928301774 1017 Call-ID: a84b4c76e66710 1018 CSeq: 314160 INVITE 1019 Contact: 1020 Content-Type: application/sdp 1021 Content-Length: 142 1023 (Alice's SDP not shown) 1025 Proxy P1 record-routes. Since the session interval is now acceptable 1026 to it, it forwards the request to P2 (message 5). However, the 1027 session interval is below its minimum configured amount of 4000. So, 1028 it rejects the request with a 422 response code (message 6), and 1029 includes a Min-SE header field with the value of 4000. Once more, 1030 Alice retries the INVITE. This time, the Min-SE header field in her 1031 INVITE is the maximum of all Min-SE she has received (3600 and 4000). 1032 Message 10 might look like: 1034 INVITE sips:bob@biloxi.example.com SIP/2.0 1035 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1036 Supported: timer 1037 Session-Expires: 4000 1038 Min-SE: 4000 1039 Max-Forwards: 70 1040 To: Bob 1041 From: Alice ;tag=1928301774 1042 Call-ID: a84b4c76e66710 1043 CSeq: 314161 INVITE 1044 Contact: 1045 Content-Type: application/sdp 1046 Content-Length: 142 1048 (Alice's SDP not shown) 1050 P1 record-routes once again, but P2 does not (this wouldn't normally 1051 happen; presumably, if it asked for session timer, it would 1052 record-route the subsequent request). The UAS receives the request. 1053 It copies the Session-Expires header from the request to the 1054 response, and adds a refresher parameter with value 'uac'. This 200 1055 OK is forwarded back to Alice. The response she receives (message 1056 15) might look like: 1058 SIP/2.0 200 OK 1059 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1060 ;received=192.0.2.1 1061 Require: timer 1062 Supported: timer 1063 Record-Route: sips:p1.atlanta.example.com;lr 1064 Session-Expires: 4000;refresher=uac 1065 To: Bob ;tag=9as888nd 1066 From: Alice ;tag=1928301774 1067 Call-ID: a84b4c76e66710 1068 CSeq: 314161 INVITE 1069 Contact: 1070 Content-Type: application/sdp 1071 Content-Length: 142 1073 (Bob's SDP not shown) 1075 Alice generates an ACK (message 16), which is routed through P1 and 1076 then to Bob. Since Alice is the refresher, around 3000 seconds 1077 later, Alice sends an UPDATE request to refresh the session. Since 1078 this request is part of an established dialog, and Alice has not 1079 received any 422 responses or requests on that dialog, there is no 1080 Min-SE header field in her request (message 18): 1082 UPDATE sips:bob@192.0.2.4 SIP/2.0 1083 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1084 Route: sips:p1.atlanta.example.com;lr 1085 Supported: timer 1086 Session-Expires: 4000;refresher=uac 1087 Max-Forwards: 70 1088 To: Bob ;tag=9as888nd 1089 From: Alice ;tag=1928301774 1090 Call-ID: a84b4c76e66710 1091 CSeq: 314162 UPDATE 1092 Contact: 1094 This is forwarded through P1 to Bob. Bob generates a 200 OK, copying 1095 the Session-Expires header field into the response. This is 1096 forwarded through P1, and arrives at Alice. The response she 1097 receives (message 21) might look like: 1099 SIP/2.0 200 OK 1100 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1101 ;received=192.0.2.1 1102 Require: timer 1103 Session-Expires: 4000;refresher=uac 1104 To: Bob ;tag=9as888nd 1105 From: Alice ;tag=1928301774 1106 Call-ID: a84b4c76e66710 1107 CSeq: 314162 UPDATE 1108 Contact: 1110 Shortly afterwards, Alice's UA crashes. As a result, she never sends 1111 a session refresh request. 3968 seconds later, Bob times out, and 1112 sends a BYE request (message 22). This is sent to P1. P1 attempts 1113 to deliver it, but fails (since Alice's UA has crashed). P1 then 1114 returns a 408 (Request Timeout) to Bob. 1116 14. Acknowledgements 1118 The authors wish to thank Brett Tate for his contributions to this 1119 work. Brian Rosen completed the editing of the document. 1121 15. References 1123 15.1 Normative References 1125 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1126 Levels", BCP 14, RFC 2119, March 1997. 1128 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1129 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1130 Session Initiation Protocol", RFC 3261, June 2002. 1132 [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1133 Method", RFC 3311, October 2002. 1135 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1136 Session Description Protocol (SDP)", RFC 3264, June 2002. 1138 15.2 Informative References 1140 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1141 "RTP: A Transport Protocol for Real-Time Applications", RFC 1142 3550, July 2003. 1144 [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1145 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1147 [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1148 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 1149 2002. 1151 [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1152 Notification", RFC 3265, June 2002. 1154 Authors' Addresses 1156 Steven Donovan 1157 dynamicsoft 1158 5100 Tennyson Parkway 1159 Suite 1200 1160 Plano, TX 75024 1161 US 1163 EMail: sdonovan@dynamicsoft.com 1164 Jonathan Rosenberg 1165 dynamicsoft 1166 600 Lanidex Plaza 1167 Parsippany, NJ 07054 1168 US 1170 EMail: jdrosen@dynamicsoft.com 1172 Intellectual Property Statement 1174 The IETF takes no position regarding the validity or scope of any 1175 Intellectual Property Rights or other rights that might be claimed to 1176 pertain to the implementation or use of the technology described in 1177 this document or the extent to which any license under such rights 1178 might or might not be available; nor does it represent that it has 1179 made any independent effort to identify any such rights. Information 1180 on the procedures with respect to rights in RFC documents can be 1181 found in BCP 78 and BCP 79. 1183 Copies of IPR disclosures made to the IETF Secretariat and any 1184 assurances of licenses to be made available, or the result of an 1185 attempt made to obtain a general license or permission for the use of 1186 such proprietary rights by implementers or users of this 1187 specification can be obtained from the IETF on-line IPR repository at 1188 http://www.ietf.org/ipr. 1190 The IETF invites any interested party to bring to its attention any 1191 copyrights, patents or patent applications, or other proprietary 1192 rights that may cover technology that may be required to implement 1193 this standard. Please address the information to the IETF at 1194 ietf-ipr@ietf.org. 1196 Disclaimer of Validity 1198 This document and the information contained herein are provided on an 1199 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1200 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1201 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1202 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1203 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1204 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1206 Copyright Statement 1208 Copyright (C) The Internet Society (2004). This document is subject 1209 to the rights, licenses and restrictions contained in BCP 78, and 1210 except as set forth therein, the authors retain all their rights. 1212 Acknowledgment 1214 Funding for the RFC Editor function is currently provided by the 1215 Internet Society.