idnits 2.17.1 draft-ietf-sipcore-rfc4028bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4028, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 734 has weird spacing: '...rameter refre...' -- The document date (December 21, 2018) is 1925 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 (Obsoleted by RFC 6665) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Obsoletes: 4028 (if approved) S. Donovan 5 Intended status: Standards Track J. Rosenberg 6 Expires: June 24, 2019 Cisco Systems 7 December 21, 2018 9 Session Timers in the Session Initiation Protocol (SIP) 10 draft-ietf-sipcore-rfc4028bis-00 12 Abstract 14 This document defines an extension to the Session Initiation Protocol 15 (SIP). This extension allows for a periodic refresh of SIP sessions 16 through a re-INVITE or UPDATE request. The refresh allows both user 17 agents and proxies to determine whether the SIP session is still 18 active. The extension defines two new header fields: Session- 19 Expires, which conveys the lifetime of the session, and Min-SE, which 20 conveys the minimum allowed value for the session timer. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 24, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 60 5. Session-Expires Header Field Definition . . . . . . . . . . . 6 61 6. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8 62 7. 422 Response Code Definition . . . . . . . . . . . . . . . . 8 63 8. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9. Generating an Initial Session Refresh Request . . . . . . . . 9 65 10. Processing a 2xx Response . . . . . . . . . . . . . . . . . . 9 66 11. Processing a 422 Response . . . . . . . . . . . . . . . . . . 11 67 12. Generating Subsequent Session Refresh Requests . . . . . . . 11 68 13. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 69 14. Processing of Requests . . . . . . . . . . . . . . . . . . . 13 70 15. Processing of Responses . . . . . . . . . . . . . . . . . . . 14 71 16. Session Expiration . . . . . . . . . . . . . . . . . . . . . 15 72 17. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15 73 18. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17 74 19. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 20. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . . 18 76 21. Outside Attacks . . . . . . . . . . . . . . . . . . . . . . . 19 77 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 23. IANA Registration of Min-SE and Session-Expires Header Fields 19 79 24. IANA Registration of the 422 (Session Interval Too Small) 80 Response Code . . . . . . . . . . . . . . . . . . . . . . . . 20 81 25. IANA Registration of the 'timer' Option Tag . . . . . . . . . 20 82 26. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 20 83 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 84 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 28.1. Normative References . . . . . . . . . . . . . . . . . . 25 86 28.2. Informative References . . . . . . . . . . . . . . . . . 25 87 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 The Session Initiation Protocol (SIP) [RFC3261] does not define a 93 keepalive mechanism for the sessions it establishes. Although the 94 user agents may be able to determine whether the session has timed 95 out by using session specific mechanisms, proxies will not be able to 96 do so. The result is that call stateful proxies will not always be 97 able to determine whether a session is still active. For instance, 98 when a user agent fails to send a BYE message at the end of a 99 session, or when the BYE message gets lost due to network problems, a 100 call stateful proxy will not know when the session has ended. In 101 this situation, the call stateful proxy will retain state for the 102 call and has no method to determine when the call state information 103 no longer applies. 105 To resolve this problem, this extension defines a keepalive mechanism 106 for SIP sessions. UAs send periodic re-INVITE or UPDATE [RFC3311] 107 requests (referred to as session refresh requests) to keep the 108 session alive. The interval for the session refresh requests is 109 determined through a negotiation mechanism defined here. If a 110 session refresh request is not received before the interval passes, 111 the session is considered terminated. Both UAs are supposed to send 112 a BYE, and call stateful proxies can remove any state for the call. 114 This refresh mechanism has additional applications. A user agent 115 would like to determine whether the session is still active for the 116 same reasons a call stateful proxy server would. This determination 117 can be made at a user agent without the use of SIP level mechanisms; 118 for audio sessions, periodic RTCP packets serve as an indication of 119 liveness [RFC3550]. However, it is desirable to separate indications 120 of SIP session liveness from the details of the particular session. 122 Another application of the session timer is in the construction of a 123 SIP Network Address Translator (NAT) Application Level Gateway (ALG) 124 [RFC2663]. The ALG embedded in a NAT will need to maintain state for 125 the duration of a call. This state must eventually be removed. 126 Relying on a BYE to trigger the removal of state, besides being 127 unreliable, introduces a potential denial of service attack. 129 This document provides an extension to SIP that defines a session 130 expiration mechanism. Periodic refreshes, through re-INVITEs or 131 UPDATEs, are used to keep the session active. The extension is 132 sufficiently backward compatible with SIP that it works as long as 133 either one of the two participants in a dialog understands the 134 extension. Two new header fields (Session-Expires and Min-SE) and a 135 new response code (422) are defined. Session-Expires conveys the 136 duration of the session, and Min-SE conveys the minimum allowed value 137 for the session expiration. The 422 response code indicates that the 138 session timer duration was too small. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. Terminology 150 Session Interval: The maximum amount of time that can occur between 151 session refresh requests in a dialog before the session will be 152 considered timed out. The session interval is conveyed in the 153 Session-Expires header field, which is defined here. The UAS 154 obtains this value from the Session-Expires header field in a 2xx 155 response to a session refresh request that it sends. Proxies and 156 UACs determine this value from the Session-Expires header field in 157 a 2xx response to a session refresh request that they receive. 159 Minimum Timer: Because of the processing load of mid-dialog requests, 161 all elements (proxy, UAC, UAS) can have a configured minimum value 162 for the session interval that they are willing to accept. This 163 value is called the minimum timer. 165 Session Expiration: The time at which an element will consider the 166 session timed out, if no successful session refresh transaction 167 occurs beforehand. 169 Session Refresh Request: An INVITE or UPDATE request processed 170 according to the rules of this specification. If the request 171 generates a 2xx response, the session expiration is increased to 172 the current time plus the session interval obtained from the 173 response. A session refresh request is not to be confused with a 174 target refresh request, defined in Section 6 of [RFC3261], which 175 is a request that can update the remote target of a dialog. 177 Initial Session Refresh Request: The first session refresh request 178 sent with a particular Call-ID value. 180 Subsequent Session Refresh Request: Any session refresh request sent 182 with a particular Call-ID after the initial session refresh 183 request. 185 Refresh: Same as a session refresh request. 187 4. Overview of Operation 189 This section provides a brief overview of the operation of the 190 extension. It is tutorial in nature and should not be considered 191 normative. 193 This extension has the property that it works even when only one UA 194 in a dialog supports it. The processing steps differ for handling 195 each of the four cases (the UAC does or doesn't support it, and the 196 UAS does or doesn't support it). For simplicity's sake, this section 197 will describe basic operation in the case where both sides support 198 the extension. 200 A UAC starts by sending an INVITE. This includes a Supported header 201 field with the option tag 'timer', indicating support for this 202 extension. 204 This request passes through proxies, any one of which may have an 205 interest in establishing a session timer. Each proxy can insert a 206 Session-Expires header field and a Min-SE header field into the 207 request (if none is already there) or alter the value of existing 208 Session-Expires and Min-SE header fields as described below. 210 The Min-SE header field establishes the lower bound for the session 211 refresh interval; i.e., the fastest rate any proxy servicing this 212 request will be allowed to require. The purpose of this header field 213 is to prevent hostile proxies from setting arbitrarily short refresh 214 intervals so that their neighbors are overloaded. Each proxy 215 processing the request can raise this lower bound (increase the 216 period between refreshes) but is not allowed to lower it. 218 The Session-Expires header field establishes the upper bound for the 219 session refresh interval; i.e., the time period after processing a 220 request for which any session-stateful proxy must retain its state 221 for this session. Any proxy servicing this request can lower this 222 value, but it is not allowed to decrease it below the value specified 223 in the Min-SE header field. 225 If the Session-Expires interval is too low for a proxy (i.e., lower 226 than the value of Min-SE that the proxy would wish to assert), the 227 proxy rejects the request with a 422 response. That response 228 contains a Min-SE header field identifying the minimum session 229 interval it is willing to support. The UAC will try again, this time 230 including the Min-SE header field in the request. The header field 231 contains the largest Min-SE header field it observed in all 422 232 responses previously received. This way, the minimum timer meets the 233 constraints of all proxies along the path. 235 After several INVITE/422 iterations, the request eventually arrives 236 at the UAS. The UAS can adjust the value of the session interval as 237 if it were a proxy; when done, it places the final session interval 238 into the Session-Expires header field in a 2xx response. The 239 Session-Expires header field also contains a 'refresher' parameter, 240 which indicates who is doing the refreshing -- the UA that is 241 currently the UAC, or the UA that is currently the UAS. As the 2xx 242 response travels back through the proxy chain, each proxy can observe 243 the final session interval but can't change it. 245 From the Session-Expires header field in the response, both UAs know 246 that a session timer is active, when it will expire, and who is 247 refreshing. At some point before the expiration, the currently 248 active refresher generates a session refresh request, which is a re- 249 INVITE or UPDATE [RFC3311] request. If the refresher never gets a 250 response to that session refresh request, it sends a BYE to terminate 251 the session. Similarly, if the other side never gets the session 252 refresh request before the session expires, it sends a BYE. 254 The refresh requests sent once the session is established are 255 processed identically to the initial requests, as described above. 256 This means that a successful session refresh request will extend the 257 session, as desired. 259 The extension introduces additional complications beyond this basic 260 flow to support cases where only one of the UAs supports it. One 261 such complication is that a proxy may need to insert the Session- 262 Expires header field into the response, in the event that the UAS 263 doesn't support the extension. The negotiation of the role of 264 refresher is also affected by this capability; it takes into 265 consideration which participants support the extension. 267 Note that the session timer refreshes the session, not the dialog 268 used to establish the session. Of course, the two are related. If 269 the session expires, a BYE is sent, which terminates the session and, 270 generally, the dialog. 272 5. Session-Expires Header Field Definition 274 The Session-Expires header field conveys the session interval for a 275 SIP session. It is placed only in INVITE or UPDATE requests, as well 276 as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires 277 header field, it contains a delta-time. 279 The absolute minimum for the Session-Expires header field is 90 280 seconds. This value represents a bit more than twice the duration 281 that a SIP transaction can take in the event of a timeout. This 282 allows sufficient time for a UA to attempt a refresh at the halfpoint 283 of the session interval, and for that transaction to complete 284 normally before the session expires. However, 1800 seconds (30 285 minutes) is RECOMMENDED as the value for the Session-Expires header 286 field. In other words, SIP entities MUST be prepared to handle 287 Session-Expires header field values of any duration greater than 90 288 seconds, but entities that insert the Session-Expires header field 289 SHOULD NOT choose values of less than 30 minutes. 291 Small session intervals can be destructive to the network. They 292 cause excessive messaging traffic that affects both user agents and 293 proxy servers. They increase the possibility of 'glare' that can 294 occur when both user agents send a re-INVITE or UPDATE at the same 295 time. Since the primary purpose of the session timer is to provide a 296 means to time out state in SIP elements, very small values won't 297 generally be needed. 30 minutes was chosen because 95% of phone 298 calls are shorter than this duration. However, the 30 minute minimum 299 is listed as a SHOULD, and not as a MUST, since the exact value for 300 this number is dependent on many network factors, including network 301 bandwidths and latencies, computing power, memory availability, 302 network topology, and, of course, the application scenario. After 303 all, SIP can set up any kind of session, not just a phone call. At 304 the time of publication of this document, 30 minutes seems 305 appropriate. Advances in technologies may result in the number being 306 excessively large five years in the future. 308 The default value of the Session-Expires header field is undefined. 309 This means that the absence of the Session-Expires header field 310 implies no expiration of the session, using the mechanism defined in 311 this specification. Note that other mechanisms not defined in this 312 specification, such as locally configured timers, may apply. 314 The syntax of the Session-Expires header field is as follows: 316 Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds 317 *(SEMI se-params) 318 se-params = refresher-param / generic-param 319 refresher-param = "refresher" EQUAL ("uas" / "uac") 321 Note that a compact form, the letter x, has been reserved for 322 Session-Expires. The BNF for delta-seconds and generic-param is 323 defined in Section 25 of RFC 3261 [RFC3261]. 325 Table 1 is an extension of Tables 2 and 3 in [RFC3261] for the 326 Session-Expires and Min-SE header fields. The column 'PRA' is for 327 the PRACK method [RFC3262], 'UPD' is for the UPDATE method [RFC3311], 328 'SUB' is for the SUBSCRIBE method [RFC3265], and 'NOT' is for the 329 NOTIFY method [RFC3265]. 331 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 332 | Header | wh | pr | A | BY | CA | IN | OP | RE | PR | UP | SU | NO | 333 | | er | ox | C | E | N | V | T | G | A | D | B | T | 334 | | e | y | K | | | | | | | | | | 335 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 336 | Sessio | R | am | - | - | - | o | - | - | - | o | - | - | 337 | n-Expi | | r | | | | | | | | | | | 338 | res | | | | | | | | | | | | | 339 | Sessio | 2x | ar | - | - | - | o | - | - | - | o | - | - | 340 | n-Expi | x | | | | | | | | | | | | 341 | res | | | | | | | | | | | | | 342 | Min-SE | R | am | - | - | - | o | - | - | - | o | - | - | 343 | | | r | | | | | | | | | | | 344 | Min-SE | 42 | | - | - | - | m | - | - | - | m | - | - | 345 | | 2 | | | | | | | | | | | | 346 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 348 Table 1: Session-Expires and Min-SE Header Fields 350 6. Min-SE Header Field Definition 352 The Min-SE header field indicates the minimum value for the session 353 interval, in units of delta-seconds. When used in an INVITE or 354 UPDATE request, it indicates the smallest value of the session 355 interval that can be used for that session. When present in a 356 request or response, its value MUST NOT be less than 90 seconds. 358 When the header field is not present, its default value for is 90 359 seconds. 361 The Min-SE header field MUST NOT be used in responses except for 362 those with a 422 response code. It indicates the minimum value of 363 the session interval that the server is willing to accept. 365 The syntax of the Min-SE header field is as follows: 367 Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param) 369 7. 422 Response Code Definition 371 This extension introduces the 422 (Session Interval Too Small) 372 response code. It is generated by a UAS or proxy when a request 373 contains a Session-Expires header field with a duration below the 374 minimum timer for the server. The 422 response MUST contain a Min-SE 375 header field with the minimum timer for that server. 377 8. UAC Behavior 379 9. Generating an Initial Session Refresh Request 381 A UAC that supports the session timer extension defined here MUST 382 include a Supported header field in each request (except ACK), 383 listing the option tag 'timer' [RFC3261]. It MUST do so even if the 384 UAC is not requesting usage of the session timer for this session. 386 The UAC MAY include a Require header field in the request with the 387 value 'timer' to indicate that the UAS must support the session timer 388 to participate in the session. This does not mean that the UAC is 389 requiring the UAS to perform the refreshes, only that it is requiring 390 the UAS to support the extension. In addition, the UAC MAY include a 391 Proxy-Require header field in the request with the value 'timer' to 392 indicate that proxies must support the session timer in order to 393 correctly process the request. However, usage of either Require or 394 Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, 395 since the extension works even when only the UAC supports the 396 extension. The Supported header field containing 'timer' MUST still 397 be included, even if the Require or Proxy-Require header fields are 398 present containing 'timer'. 400 A UAC MAY include the Min-SE header field in the initial INVITE 401 request. 403 A UAC MAY include a Session-Expires header field in an initial 404 session refresh request if it wants a session timer applied to the 405 session. The value of this header field indicates the session 406 interval desired by the UAC. If a Min-SE header is included in the 407 initial session refresh request, the value of the Session-Expires 408 MUST be greater than or equal to the value in Min-SE. 410 The UAC MAY include the refresher parameter with value 'uac' if it 411 wants to perform the refreshes. However, it is RECOMMENDED that the 412 parameter be omitted so that it can be selected by the negotiation 413 mechanisms described below. 415 10. Processing a 2xx Response 417 The session timer requires a UA to create and maintain state. This 418 state includes the session interval, the session expiration, and the 419 identity of the refresher. This state is associated with the dialog 420 on which the session has been negotiated. 422 When a 2xx response to a session refresh request arrives, it may or 423 may not contain a Require header field with the value 'timer'. If it 424 does, the UAC MUST look for the Session-Expires header field to 425 process the response. 427 If there was a Require header field in the response with the value 428 'timer', the Session-Expires header field will always be present. 429 UACs MUST be prepared to receive a Session-Expires header field in a 430 response, even if none were present in the request. The 'refresher' 431 parameter will be present in the Session-Expires header field, 432 indicating who will perform the refreshes. The UAC MUST set the 433 identity of the refresher to the value of this parameter. If the 434 parameter contains the value 'uac', the UAC will perform them. It is 435 possible that the UAC requested the session timer (and thus included 436 a Session-Expires header field in the request) and that there was no 437 Require or Session-Expires header field in the 2xx response. This 438 will happen when the UAS doesn't support the session timer extension 439 and only the UAC has asked for a session timer (no proxies have 440 requested it). In this case, if the UAC still wishes to use the 441 session timer (which is purely for its benefit alone), it has to 442 perform them. To do this, the UAC follows the procedures defined in 443 this specification as if the Session-Expires header field were in the 444 2xx response, and its value was the same as that in the request, but 445 with a refresher parameter of 'uac'. 447 If the 2xx response did not contain a Session-Expires header field, 448 there is no session expiration. In this case, no refreshes need to 449 be sent. A 2xx without a Session-Expires can come for both initial 450 and subsequent session refresh requests. This means that the session 451 timer can be 'turned-off' in mid dialog by receiving a response 452 without a Session-Expires header field. 454 The UAC remembers the session interval for a session as the value of 455 the delta-time from the Session-Expires header field in the most 456 recent 2xx response to a session refresh request on a dialog. It is 457 explicitly allowed for there to be differing session intervals (or 458 none at all) on differing dialogs established as a result of a single 459 INVITE. The UAC also remembers whether it or its peer is the 460 refresher on for the session. 462 If the UAC must perform the refreshes, it computes the session 463 expiration for that session. The session expiration is the time of 464 reception of the last 2xx response to a session refresh request on 465 that dialog plus the session interval for that session. If the UA 466 seeks to continue with the session beyond the session expiration, it 467 MUST generate a refresh before the session expiration. It is 469 RECOMMENDED that this refresh be sent once half the session interval 470 has elapsed. Additional procedures for this refresh are described in 471 Section 18. 473 Similarly, a re-INVITE or UPDATE request sent within a dialog for 474 purposes other than session refreshes will also have the effect of 475 refreshing the session, and its processing will follow the procedures 476 defined in this specification. 478 11. Processing a 422 Response 480 If the response to a session refresh request is a 422 (Session 481 Interval Too Small) response message, then the UAC MAY retry the 482 request. The procedures for retrying are described in Section 12. 483 This new request constitutes a new transaction and SHOULD have the 484 same value as the Call-ID, To, and From of the previous request, but 485 the CSeq should contain a new sequence number that is one higher than 486 the previous. 488 12. Generating Subsequent Session Refresh Requests 490 The values of Supported, Require, and Proxy-Require used in the 491 initial Session refresh request MUST be used. 493 The UAC MUST insert the Min-SE header field into a session refresh 494 request for a particular dialog if it has ever received a 422 495 response to a previous session refresh request on the same dialog, or 496 if it has received a session refresh request on that dialog that 497 contained a Min-SE header field. Similarly, if no dialog has been 498 established yet, a UAC MUST insert the Min-SE header field into an 499 INVITE request if it has ever received a 422 response to a previous 500 INVITE request with the same Call-ID. 502 The value of the Min-SE header field present in a session refresh 503 request MUST be the largest value among all Min-SE header field 504 values returned in all 422 responses or received in session refresh 505 requests, on the same dialog, if a dialog has been established. If 506 no dialog has been established, the Min-SE header field value is set 507 to the largest value among all Min-SE header field values returned in 508 all 422 responses for an INVITE request with the same Call-ID. A 509 result of this rule is that the maximum value of the Min-SE is 510 effectively 'cleared' once the dialog is established, and from that 511 point on, only the values from proxies known to be on the proxy path 512 will end up being used. 514 The UAC may have its own opinions about the minimum session interval. 515 In that case, if the value above is too small, the UAC MAY increase 516 it. 518 In a session refresh request sent within a dialog with an active 519 session timer, the Session-Expires header field SHOULD be present. 520 When present, it SHOULD be equal to the maximum of the Min-SE header 521 field (recall that its default value when not present is 90 seconds) 522 and the current session interval. Inclusion of the Session-Expires 523 header field with this value avoids certain denial-of-service 524 attacks, as documented in Section 19. As such, a UA should only 525 ignore the SHOULD in unusual and singular cases where it is desirable 526 to change the session interval mid-dialog. 528 If the session refresh request is not the initial one, it is 529 RECOMMENDED that the refresher parameter be set to 'uac' if the 530 element sending the request is currently performing refreshes, and to 531 'uas' if its peer is performing the refreshes. This way, the role of 532 refresher does not change on each refresh. However, if it wishes to 533 explicitly change the roles, it MAY use a value of 'uas' if it knows 534 that the other side supports the session timer. It could know this 535 by having received a request from its peer with a Supported header 536 field containing the value 'timer'. If it seeks to reselect the 537 roles, it MAY omit the parameter. 539 A re-INVITE generated to refresh the session is a normal re-INVITE, 540 and an UPDATE generated to refresh a session is a normal UPDATE. If 541 a UAC knows that its peer supports the UPDATE method, it is 542 RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can 543 make this determination if it has seen an Allow header field from its 544 peer with the value 'UPDATE', or through a mid-dialog OPTIONS 545 request. It is RECOMMENDED that the UPDATE request not contain an 546 offer [RFC3264], but a re-INVITE SHOULD contain one, even if the 547 details of the session have not changed. In that case, the offer 548 MUST indicate that it has not changed. In the case of SDP, this is 549 accomplished by including the same value for the origin field as did 550 previous SDP messages to its peer. The same is true for an answer 551 exchanged as a result of a session refresh request; if it has not 552 changed, that MUST be indicated. 554 13. Proxy Behavior 556 Session timers are mostly of interest to call stateful proxy servers 557 (that is, to servers that maintain the state of calls and dialogs 558 established through them). However, a stateful proxy server (that 559 is, a server which is aware of transaction state but does not retain 560 call or dialog state) MAY also follow the rules described here. 561 Stateless proxies MUST NOT attempt to request session timers. 562 Proxies that ask for session timers SHOULD record-route, as they 563 won't receive refreshes if they don't. 565 The proxy processing rules require the proxy to remember 566 information between the request and response, ruling out stateless 567 proxies. 569 14. Processing of Requests 571 Processing of requests is identical for all session refresh requests. 573 To request a session timer for a session, a proxy makes sure that a 574 Session-Expires header field is present in a session refresh request 575 for that session. A proxy MAY insert a Session-Expires header field 576 in the request before forwarding it if none was present in the 577 request. This Session-Expires header field may contain any desired 578 expiration time the proxy would like, but not with a duration lower 579 than the value in the Min-SE header field in the request, if it is 580 present. The proxy MUST NOT include a refresher parameter in the 581 header field value. 583 If the request already had a Session-Expires header field, the proxy 584 MAY reduce its value but MUST NOT set it to a duration lower than the 585 value in the Min-SE header field in the request, if it is present. 586 If the value of the Session-Expires header field is greater than or 587 equal to the value in the Min-SE header field (recall that the 588 default is 90 seconds when the Min-SE header field is not present), 589 the proxy MUST NOT increase the value of the Session-Expires header 590 field. If the value of the Session-Expires header field is lower 591 than the value of the Min-SE header field (possibly because the proxy 592 increased the value of the Min-SE header field, as described below), 593 the proxy MUST increase the value of the Session-Expires header field 594 to make it equal to Min-SE header field value. The proxy MUST NOT 595 insert or modify the value of the 'refresher' parameter in the 596 Session-Expires header field. 598 If the request contains a Supported header field with a value 599 'timer', the proxy MAY reject the INVITE request with a 422 (Session 600 Interval Too Small) response if the session interval in the Session- 601 Expires header field is smaller than the minimum interval defined by 602 the proxy's local policy. When sending the 422 response, the proxy 603 MUST include a Min-SE header field with the value of its minimum 604 interval. That minimum MUST NOT be lower than 90 seconds. 606 If the request doesn't indicate support for the session timer but 607 contains a session interval that is too small, the proxy cannot 608 usefully reject the request, as this would result in a call failure. 609 Rather, the proxy SHOULD insert a Min-SE header field containing its 610 minimum interval. If a Min-SE header field is already present, the 611 proxy SHOULD increase (but MUST NOT decrease) the value to its 612 minimum interval. The proxy MUST then increase the Session-Expires 613 header field value to be equal to the value in the Min-SE header 614 field, as described above. A proxy MUST NOT insert a Min-SE header 615 field or modify the value of an existing header field in a proxied 616 request if that request contains a Supported header field with the 617 value 'timer'. This is needed to protect against certain denial of 618 service attacks, described in Section 19. 620 Assuming that the proxy has requested a session timer (and thus has 621 possibly inserted the Session-Expires header field or reduced it), 622 the proxy MUST remember that it is using a session timer, and also 623 remember the value of the Session-Expires header field from the 624 proxied request. This MUST be remembered for the duration of the 625 transaction. 627 The proxy MUST remember, for the duration of the transaction, whether 628 the request contained the Supported header field with the value 629 'timer'. If the request did not contain a Supported header field 630 with the value 'timer', the proxy MAY insert a Require header field 631 with the value 'timer' into the request. However, this is NOT 632 RECOMMENDED. This allows the proxy to insist on a session timer for 633 the session. This header field is not needed if a Supported header 634 field was in the request; in this case, the proxy would already be 635 sure the session timer can be used for the session. 637 15. Processing of Responses 639 When the final response to the request arrives, it is examined by the 640 proxy. 642 If the response does not contain a Session-Expires header field but 643 the proxy remembers that it requested a session timer in the request 644 (by inserting, modifying, or examining and accepting the Session- 645 Expires header field in the proxied request), this means that the UAS 646 did not support the session timer. If the proxy remembers that the 647 UAC did not support the session timer either, the proxy forwards the 648 response upstream normally. There is no session expiration for this 649 session. If, however, the proxy remembers that the UAC did support 650 the session timer, additional processing is needed. 652 Because there is no Session-Expires or Require header field in the 653 response, the proxy knows that it is the first session-timer-aware 654 proxy to receive the response. This proxy MUST insert a Session- 655 Expires header field into the response with the value it remembered 656 from the forwarded request. It MUST set the value of the 'refresher' 657 parameter to 'uac'. The proxy MUST add the 'timer' 659 option tag to any Require header field in the response, and if none 660 was present, add the Require header field with that value before 661 forwarding it upstream. 663 If the received response contains a Session-Expires header field, no 664 modification of the response is needed. 666 In all cases, if the 2xx response forwarded upstream by the proxy 667 contains a Session-Expires header field, its value represents the 668 session interval for the session associated with that response. The 669 proxy computes the session expiration as the time when the 2xx 670 response is forwarded upstream, plus the session interval. This 671 session expiration MUST update any existing session expiration for 672 the session. The refresher parameter in the Session-Expires header 673 field in the 2xx response forwarded upstream will be present, and it 674 indicates which UA is performing the refreshes. There can be 675 multiple 2xx responses to a single INVITE, each representing a 676 different dialog, resulting in multiple session expirations, one for 677 each session associated with each dialog. 679 The proxy MUST NOT modify the value of the Session-Expires header 680 field received in the response (assuming one was present) before 681 forwarding it upstream. 683 16. Session Expiration 685 When the current time equals or passes the session expiration for a 686 session, the proxy MAY remove associated call state, and MAY free any 687 resources associated with the call. Unlike the UA, it MUST NOT send 688 a BYE. 690 17. UAS Behavior 692 The UAS must respond to a request for a session timer by the UAC or a 693 proxy in the path of the request, or it may request that a session 694 timer be used itself. 696 If an incoming request contains a Supported header field with a value 697 'timer' and a Session Expires header field, the UAS MAY reject the 698 INVITE request with a 422 (Session Interval Too Small) response if 699 the session interval in the Session-Expires header field is smaller 700 than the minimum interval defined by the UAS' local policy. When 701 sending the 422 response, the UAS MUST include a Min-SE header field 702 with the value of its minimum interval. This minimum interval MUST 703 NOT be lower than 90 seconds. 705 If the UAS wishes to accept the request, it copies the value of the 706 Session-Expires header field from the request into the 2xx response. 708 The UAS response MAY reduce its value but MUST NOT set it to a 709 duration lower than the value in the Min-SE header field in the 710 request, if it is present; otherwise the UAS MAY reduce its value but 711 MUST NOT set it to a duration lower than 90 seconds. The UAS MUST 712 NOT increase the value of the Session-Expires header field. 714 If the incoming request contains a Supported header field with a 715 value 'timer' but does not contain a Session-Expires header, it means 716 that the UAS is indicating support for timers but is not requesting 717 one. The UAS may request a session timer in the 2XX response by 718 including a Session-Expires header field. The value MUST NOT be set 719 to a duration lower than the value in the Min-SE header field in the 720 request, if it is present. 722 The UAS MUST set the value of the refresher parameter in the Session- 723 Expires header field in the 2xx response. This value specifies who 724 will perform refreshes for the dialog. The value is based on the 725 value of this parameter in the request, and on whether the UAC 726 supports the session timer extension. The UAC supports the extension 727 if the 'timer' option tag was present in a Supported header field in 728 the request. Table 2 defines how the value in the response is set. 729 A value of 'none' in the 2nd column means that there was no refresher 730 parameter in the request. A value of 'NA' in the third column means 731 that this particular combination shouldn't happen, as it is 732 disallowed by the protocol. 734 UAC supports? refresher parameter refresher parameter 735 in request in response 736 ------------------------------------------------------- 737 N none uas 738 N uac NA 739 N uas NA 740 Y none uas or uac 741 Y uac uac 742 Y uas uas 744 Figure 1: UAS Behavior 746 The fourth row of Table 2 describes a case where both the UAC and UAS 747 support the session timer extension, and where the UAC did not select 748 who will perform refreshes. This allows the UAS to decide whether it 749 or the UAC will perform the refreshes. However, as the table 750 indicates, the UAS cannot override the UAC's choice of refresher, if 751 it made one. 753 If the refresher parameter in the Session-Expires header field in the 754 2xx response has a value of 'uac', the UAS MUST place a Require 755 header field into the response with the value 'timer'. This is 756 because the uac is performing refreshes and the response has to be 757 processed for the UAC to know this. If the refresher parameter in 758 the 2xx response has a value of 'uas' and the Supported header field 759 in the request contained the value 'timer', the UAS SHOULD place a 760 Require header field into the response with the value 'timer'. In 761 this case, the UAC is not refreshing, but it is supposed to send a 762 BYE if it never receives a refresh. Since the call will still 763 succeed without the UAC sending a BYE, insertion of the Require is a 764 SHOULD here, and not a MUST. 766 Just like the UAC, the UAS stores state for the session timer. This 767 state includes the session interval, the session expiration, and the 768 identity of the refresher. This state is bound to the dialog used to 769 set up the session. The session interval is set to the value of the 770 delta-time from the Session-Expires header field in the most recent 771 2xx response to a session refresh request on that dialog. It also 772 remembers whether it or its peer is the refresher on the dialog, 773 based on the value of the refresher parameter from the most recent 774 2xx response to a session refresh request on that dialog. If the 775 most recent 2xx response had no Session-Expires header field, there 776 is no session expiration, and no refreshes have to be performed. 778 If the UAS must refresh the session, it computes the session 779 expiration. The session expiration is the time of transmission of 780 the last 2xx response to a session refresh request on that dialog 781 plus the session interval. If UA wishes to continue with the session 782 beyond the session expiration, it MUST generate a refresh before the 783 session expiration. It is RECOMMENDED that this refresh be sent once 784 half the session interval has elapsed. Additional procedures for 785 this refresh are described in Section 18. 787 18. Performing Refreshes 789 The side generating a refresh does so according to the UAC procedures 790 defined in Section 8. Note that only a 2xx response to a session 791 refresh request extends the session expiration. This means that a UA 792 could attempt a refresh and receive a 422 response with a Min-SE 793 header field that contains a value much larger than the current 794 session interval. The UA will still have to send a session refresh 795 request before the session expiration (which has not changed), even 796 though this request will contain a value of the Session-Expires that 797 is much larger than the current session interval. 799 If the session refresh request transaction times out or generates a 800 408 or 481 response, then the UAC sends a BYE request as per 801 Section 12.2.1.2 of RFC 3261 [RFC3261]. If the session refresh 802 request does not generate a 2xx response (and, as a result, the 803 session is not refreshed), and a response other than 408 or 481 is 804 received, the UAC SHOULD follow the rules specific to that response 805 code and retry if possible. For example, if the response is a 401, 806 the UAC would retry the request with new credentials. However, the 807 UAC SHOULD NOT continuously retry the request if the server indicates 808 the same error response. 810 Similarly, if the side not performing refreshes does not receive a 811 session refresh request before the session expiration, it SHOULD send 812 a BYE to terminate the session, slightly before the session 813 expiration. The minimum of 32 seconds and one third of the session 814 interval is RECOMMENDED. 816 Firewalls and NAT ALGs may be very unforgiving about allowing SIP 817 traffic to pass after the expiration time of the session. This is 818 why the BYE should be sent before the expiration. 820 19. Security Considerations 822 The session timer introduces the capability of a proxy or UA element 823 to force compliant UAs to send refreshes at a rate of the element's 824 choosing. This introduces the possibility of denial-of-service 825 attacks with significant amplification properties. These attacks can 826 be launched from 'outsiders' (elements that attempt to modify 827 messages in transit) or by 'insiders' (elements that are legitimately 828 in the request path but are intent on doing harm). Fortunately, both 829 cases are adequately handled by this specification. 831 20. Inside Attacks 833 This introduces the possibility of rogue proxies or UAs introducing 834 denial-of-service attacks. However, the mechanisms in this 835 specification prevent that from happening. 837 First, consider the case of a rogue UAC that wishes to force a UAS to 838 generate refreshes at a rapid rate. To do so, it inserts a Session- 839 Expires header field into an INVITE with a low duration and a 840 refresher parameter equal to uas. Assume it places a Supported 841 header field into the request. The UAS or any proxy that objects to 842 this low timer will reject the request with a 422, thereby preventing 843 the attack. If no Supported header field was present, the proxies 844 will insert a Min-SE header field into the request before forwarding 845 it. As a result, the UAS will not choose a session timer lower than 846 the minimum allowed by all elements on the path. This too prevents 847 the attack. 849 Next, consider the case of a rogue UAS that wishes to force a UAC to 850 generate refreshes at a rapid rate. In that case, the UAC has to 851 support session timer. The initial INVITE arrives at the rogue UAS, 852 which returns a 2xx with a very small session interval. The UAC uses 853 this timer and quickly sends a refresh. Section 12 requires that the 854 UAC copy the current session interval into the Session-Expires header 855 field in the request. This enables the proxies to see the current 856 value. The proxies will reject this request and provide a Min-SE 857 with a higher minimum, which the UAC will then use. Note, that if 858 the proxies did not reject the request, but rather proxied the 859 request with a Min-SE header field, an attack would still be 860 possible. The UAS could discard this header field in a 2xx response 861 and force the UAC to continue to generate rapid requests. 863 In a similar fashion, a rogue proxy cannot force either the UAC or 864 UAS to generate refreshes unless the proxy remains on the signaling 865 path and sees every request and response. 867 21. Outside Attacks 869 An element that can observe and modify a request or response in 870 transit can force rapid session refreshes. To prevent this, requests 871 and responses have to be protected by message integrity. Since the 872 session timer header fields are not end-to-end and are manipulated by 873 proxies, the SIP S/MIME capabilities are not suitable for this task. 874 Rather, integrity has to be protected by using hop-by-hop mechanisms. 875 As a result, it is RECOMMENDED that an element send a request with a 876 Session-Expires header field or a Supported header field with the 877 value 'timer' by using TLS. As adequate protection is obtained only 878 if security is applied on each hop, it is RECOMMENDED that the SIPS 879 URI scheme be used in conjunction with this extension. This means 880 that proxies that record-route and request session timer SHOULD 881 record-route with a SIPS URI. A UA that inserts a Session-Expires 882 header into a request or response SHOULD include a Contact URI that 883 is a SIPS URI. 885 22. IANA Considerations 887 This extension defines two new header fields, a new response code, 888 and a new option tag. SIP [RFC3261] defines IANA procedures for 889 registering these. 891 23. IANA Registration of Min-SE and Session-Expires Header Fields 893 The following is the registration for the Min-SE header field: 895 RFC Number: RFC 4028 896 Header Name: Min-SE 897 Compact Form: none 899 The following is the registration for the Session-Expires header 900 field: 902 RFC Number: RFC 4028 903 Header Name: Session-Expires 904 Compact Form: x 906 24. IANA Registration of the 422 (Session Interval Too Small) Response 907 Code 909 The following is the registration for the 422 (Session Interval Too 910 Small) response code: 912 Response Code: 422 913 Default Reason Phrase: Session Interval Too Small 914 RFC Number: RFC 4028 916 25. IANA Registration of the 'timer' Option Tag 918 The following is the registration for the 'timer' option tag: 920 Name: timer 921 Description: This option tag is for support of the session timer 922 extension. Inclusion in a Supported header field in a request or 923 response indicates that the UA can perform refreshes according to 924 that specification. Inclusion in a Require header in a request 925 means that the UAS must understand the session timer extension to 926 process the request. Inclusion in a Require header field in a 927 response indicates that the UAC must look for the Session-Expires 928 header field in the response and process it accordingly. 930 26. Example Call Flow 932 Example Session Timer Flow 934 Alice Proxy P1 Proxy P2 Bob 935 |(1) INVITE | | | 936 |SE: 50 | | | 937 |----------->| | | 938 |(2) 422 | | | 939 |MSE: 3600 | | | 940 |<-----------| | | 941 |(3) ACK | | | 942 |----------->| | | 943 |(4) INVITE | | | 944 |SE:3600 | | | 945 |MSE:3600 | | | 946 |----------->| | | 948 | |(5) INVITE | | 949 | |SE:3600 | | 950 | |MSE:3600 | | 951 | |----------->| | 952 | |(6) 422 | | 953 | |MSE:4000 | | 954 | |<-----------| | 955 | |(7) ACK | | 956 | |----------->| | 957 |(8) 422 | | | 958 |MSE:4000 | | | 959 |<-----------| | | 960 |(9) ACK | | | 961 |----------->| | | 962 |(10) INVITE | | | 963 |SE:4000 | | | 964 |MSE:4000 | | | 965 |----------->| | | 966 | |(11) INVITE | | 967 | |SE:4000 | | 968 | |MSE:4000 | | 969 | |----------->| | 970 | | |(12) INVITE | 971 | | |SE:4000 | 972 | | |MSE:4000 | 973 | | |----------->| 974 | | |(13) 200 OK | 975 | | |SE:4000 | 976 | | |<-----------| 977 | |(14) 200 OK | | 978 | |SE:4000 | | 979 | |<-----------| | 980 |(15) 200 OK | | | 981 |SE:4000 | | | 982 |<-----------| | | 983 |(16) ACK | | | 984 |----------->| | | 985 | |(17) ACK | | 986 | |------------------------>| 987 |(18) UPDATE | | | 988 |SE:4000 | | | 989 |----------->| | | 990 | |(19) UPDATE | | 991 | |SE:4000 | | 992 | |------------------------>| 993 | |(20) 200 OK | | 994 | |SE:4000 | | 995 | |<------------------------| 997 |(21) 200 OK | | | 998 |SE:4000 | | | 999 |<-----------| | | 1000 | |(22) BYE | | 1001 | |<------------------------| 1002 |(23) BYE | | | 1003 |<-----------| | | 1004 | |(24) 408 | | 1005 | |------------------------>| 1007 Figure 2: Example Session Timer Flow 1009 Figure 1 gives an example of a call flow that makes use of the 1010 session timer. In this example, both the UAC and UAS support the 1011 session timer extension. The initial INVITE request generated by the 1012 UAC, Alice (message 1), might look like this: 1014 INVITE sips:bob@biloxi.example.com SIP/2.0 1015 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1016 Supported: timer 1017 Session-Expires: 50 1018 Max-Forwards: 70 1019 To: Bob 1020 From: Alice ;tag=1928301774 1021 Call-ID: a84b4c76e66710 1022 CSeq: 314159 INVITE 1023 Contact: 1024 Content-Type: application/sdp 1025 Content-Length: 142 1027 (Alice's SDP not shown) 1029 This request indicates that Alice supports the session timer, and is 1030 requesting session refreshes every 50 seconds. This arrives at the 1031 first proxy, P1. This session interval is below the minimum allowed 1032 value of 3600. So P1 rejects the request with a 422 (message 2): 1034 SIP/2.0 422 Session Interval Too Small 1035 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1036 ;received=192.0.2.1 1037 Min-SE: 3600 1038 To: Bob ;tag=9a8kz From: Alice 1039 ;tag=1928301774 Call-ID: 1040 a84b4c76e66710 CSeq: 314159 INVITE 1042 This response contains a Min-SE header field with the value 3600. 1043 Alice then retries the request. This time, the request contains a 1044 Min-SE header, as Alice has received a 422 for other INVITE requests 1045 with the same Call-ID. The new request (message 4) might look like 1046 this: 1048 INVITE sips:bob@biloxi.example.com SIP/2.0 1049 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1050 Supported: timer 1051 Session-Expires: 3600 1052 Min-SE: 3600 1053 Max-Forwards: 70 1054 To: Bob 1055 From: Alice ;tag=1928301774 1056 Call-ID: a84b4c76e66710 1057 CSeq: 314160 INVITE 1058 Contact: 1059 Content-Type: application/sdp 1060 Content-Length: 142 1062 (Alice's SDP not shown) 1064 Proxy P1 record-routes. Since the session interval is now acceptable 1065 to it, it forwards the request to P2 (message 5). However, the 1066 session interval is below its minimum configured amount of 4000. So 1067 it rejects the request with a 422 response code (message 6) and 1068 includes a Min-SE header field with the value of 4000. Once more, 1069 Alice retries the INVITE. This time, the Min-SE header field in her 1070 INVITE is the maximum of all Min-SE she has received (3600 and 4000). 1071 Message 10 might look like this: 1073 INVITE sips:bob@biloxi.example.com SIP/2.0 1074 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1075 Supported: timer 1076 Session-Expires: 4000 1077 Min-SE: 4000 1078 Max-Forwards: 70 1079 To: Bob 1080 From: Alice ;tag=1928301774 1081 Call-ID: a84b4c76e66710 1082 CSeq: 314161 INVITE 1083 Contact: 1084 Content-Type: application/sdp 1085 Content-Length: 142 1087 (Alice's SDP not shown) 1089 P1 record-routes once again, but P2 does not (this wouldn't normally 1090 happen; presumably, if it asked for session timer, it would record- 1091 route the subsequent request). The UAS receives the request. It 1092 copies the Session-Expires header from the request to the response 1093 and adds a refresher parameter with value 'uac'. This 200 OK is 1094 forwarded back to Alice. The response she receives (message 15) 1095 might look like this: 1097 SIP/2.0 200 OK 1098 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1099 ;received=192.0.2.1 1100 Require: timer 1101 Supported: timer Record-Route: sips:p1.atlanta.example.com;lr 1102 Session-Expires: 4000;refresher=uac To: Bob 1103 ;tag=9as888nd From: Alice 1104 ;tag=1928301774 Call-ID: 1105 a84b4c76e66710 CSeq: 314161 INVITE Contact: 1106 Content-Type: application/sdp Content-Length: 142 1108 (Bob's SDP not shown) 1110 Alice generates an ACK (message 16), which is routed through P1 and 1111 then to Bob. Since Alice is the refresher, around 2000 seconds later 1112 Alice sends an UPDATE request to refresh the session. Because this 1113 request is part of an established dialog and Alice has not received 1114 any 422 responses or requests on that dialog, there is no Min-SE 1115 header field in her request (message 18): 1117 UPDATE sips:bob@192.0.2.4 SIP/2.0 1118 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1119 Route: sips:p1.atlanta.example.com;lr 1120 Supported: timer 1121 Session-Expires: 4000;refresher=uac 1122 Max-Forwards: 70 1123 To: Bob ;tag=9as888nd 1124 From: Alice ;tag=1928301774 1125 Call-ID: a84b4c76e66710 1126 CSeq: 314162 UPDATE 1127 Contact: 1129 This is forwarded through P1 to Bob. Bob generates a 200 OK, copying 1130 the Session-Expires header field into the response. This is 1131 forwarded through P1 and arrives at Alice. The response she receives 1132 (message 21) might look like this: 1134 SIP/2.0 200 OK 1135 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1136 ;received=192.0.2.1 1137 Require: timer 1138 Session-Expires: 4000;refresher=uac To: Bob 1139 ;tag=9as888nd From: Alice 1140 ;tag=1928301774 Call-ID: 1141 a84b4c76e66710 CSeq: 314162 UPDATE Contact: 1143 Shortly afterward, Alice's UA crashes. As a result, she never sends 1144 a session refresh request. 3968 seconds later, Bob times out and 1145 sends a BYE request (message 22). This is sent to P1. P1 attempts 1146 to deliver it but fails (because Alice's UA has crashed). P1 then 1147 returns a 408 (Request Timeout) to Bob. 1149 27. Acknowledgements 1151 The authors wish to thank Brett Tate for his contributions to this 1152 work. Brian Rosen completed the editing of the document. 1154 28. References 1156 28.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, 1160 DOI 10.17487/RFC2119, March 1997, . 1163 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1164 A., Peterson, J., Sparks, R., Handley, M., and E. 1165 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1166 DOI 10.17487/RFC3261, June 2002, . 1169 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1170 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1171 2002, . 1173 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1174 with Session Description Protocol (SDP)", RFC 3264, 1175 DOI 10.17487/RFC3264, June 2002, . 1178 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1179 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1180 May 2017, . 1182 28.2. Informative References 1184 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1185 Translator (NAT) Terminology and Considerations", 1186 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1187 . 1189 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1190 Provisional Responses in Session Initiation Protocol 1191 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1192 . 1194 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1195 Event Notification", RFC 3265, DOI 10.17487/RFC3265, June 1196 2002, . 1198 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1199 Jacobson, "RTP: A Transport Protocol for Real-Time 1200 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1201 July 2003, . 1203 Appendix A. 1205 Funding for the RFC Editor function is currently provided by the 1206 Internet Society. 1208 Authors' Addresses 1210 Christer Holmberg 1211 Ericsson 1212 Hirsalantie 11 1213 Jorvas 02420 1214 Finland 1216 Email: christer.holmberg@ericsson.com 1218 Steve Donovan 1219 Cisco Systems, Inc. 1220 2200 E. President George Bush Turnpike 1221 Richardson, Texas 75082 1222 US 1224 Email: srd@cisco.com 1226 Jonathan Rosenberg 1227 Cisco Systems, Inc. 1228 600 Lanidex Plaza 1229 Parsippany, New Jersey 07054 1230 US 1232 Email: jdrosen@cisco.com