idnits 2.17.1 draft-ietf-sipcore-rfc4028bis-03.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 729 has weird spacing: '...rameter refre...' -- The document date (June 29, 2020) is 1387 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: December 31, 2020 Cisco Systems 7 June 29, 2020 9 Session Timers in the Session Initiation Protocol (SIP) 10 draft-ietf-sipcore-rfc4028bis-03 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 https://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 December 31, 2020. 39 Copyright Notice 41 Copyright (c) 2020 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 (https://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. 158 Minimum Timer: Because of the processing load of mid-dialog requests, 160 all elements (proxy, UAC, UAS) can have a configured minimum value 161 for the session interval that they are willing to accept. This 162 value is called the minimum timer. 163 Session Expiration: The time at which an element will consider the 164 session timed out, if no successful session refresh transaction 165 occurs beforehand. 166 Session Refresh Request: An INVITE or UPDATE request processed 167 according to the rules of this specification. If the request 168 generates a 2xx response, the session expiration is increased to 169 the current time plus the session interval obtained from the 170 response. A session refresh request is not to be confused with a 171 target refresh request, defined in Section 6 of [RFC3261], which 172 is a request that can update the remote target of a dialog. 173 Initial Session Refresh Request: The first session refresh request 174 sent with a particular Call-ID value. 175 Subsequent Session Refresh Request: Any session refresh request sent 177 with a particular Call-ID after the initial session refresh 178 request. 180 Refresh: Same as a session refresh request. 182 4. Overview of Operation 184 This section provides a brief overview of the operation of the 185 extension. It is tutorial in nature and should not be considered 186 normative. 188 This extension has the property that it works even when only one UA 189 in a dialog supports it. The processing steps differ for handling 190 each of the four cases (the UAC does or doesn't support it, and the 191 UAS does or doesn't support it). For simplicity's sake, this section 192 will describe basic operation in the case where both sides support 193 the extension. 195 A UAC starts by sending an INVITE. This includes a Supported header 196 field with the option tag 'timer', indicating support for this 197 extension. 199 This request passes through proxies, any one of which may have an 200 interest in establishing a session timer. Each proxy can insert a 201 Session-Expires header field and a Min-SE header field into the 202 request (if none is already there) or alter the value of existing 203 Session-Expires and Min-SE header fields as described below. 205 The Min-SE header field establishes the lower bound for the session 206 refresh interval; i.e., the fastest rate any proxy servicing this 207 request will be allowed to require. The purpose of this header field 208 is to prevent hostile proxies from setting arbitrarily short refresh 209 intervals so that their neighbors are overloaded. Each proxy 210 processing the request can raise this lower bound (increase the 211 period between refreshes) but is not allowed to lower it. 213 The Session-Expires header field establishes the upper bound for the 214 session refresh interval; i.e., the time period after processing a 215 request for which any session-stateful proxy must retain its state 216 for this session. Any proxy servicing this request can lower this 217 value, but it is not allowed to decrease it below the value specified 218 in the Min-SE header field. 220 If the Session-Expires interval is too low for a proxy (i.e., lower 221 than the value of Min-SE that the proxy would wish to assert), the 222 proxy rejects the request with a 422 response. That response 223 contains a Min-SE header field identifying the minimum session 224 interval it is willing to support. The UAC will try again, this time 225 including the Min-SE header field in the request. The header field 226 contains the largest Min-SE header field it observed in all 422 227 responses previously received. This way, the minimum timer meets the 228 constraints of all proxies along the path. 230 After several INVITE/422 iterations, the request eventually arrives 231 at the UAS. The UAS can adjust the value of the session interval as 232 if it were a proxy; when done, it places the final session interval 233 into the Session-Expires header field in a 2xx response. The 234 Session-Expires header field also contains a 'refresher' parameter, 235 which indicates who is doing the refreshing -- the UA that is 236 currently the UAC, or the UA that is currently the UAS. As the 2xx 237 response travels back through the proxy chain, each proxy can observe 238 the final session interval but can't change it. 240 From the Session-Expires header field in the response, both UAs know 241 that a session timer is active, when it will expire, and who is 242 refreshing. At some point before the expiration, the currently 243 active refresher generates a session refresh request, which is a re- 244 INVITE or UPDATE [RFC3311] request. If the refresher never gets a 245 response to that session refresh request, it sends a BYE to terminate 246 the session. Similarly, if the other side never gets the session 247 refresh request before the session expires, it sends a BYE. 249 The refresh requests sent once the session is established are 250 processed identically to the initial requests, as described above. 251 This means that a successful session refresh request will extend the 252 session, as desired. 254 The extension introduces additional complications beyond this basic 255 flow to support cases where only one of the UAs supports it. One 256 such complication is that a proxy may need to insert the Session- 257 Expires header field into the response, in the event that the UAS 258 doesn't support the extension. The negotiation of the role of 259 refresher is also affected by this capability; it takes into 260 consideration which participants support the extension. 262 Note that the session timer refreshes the session, not the dialog 263 used to establish the session. Of course, the two are related. If 264 the session expires, a BYE is sent, which terminates the session and, 265 generally, the dialog. 267 5. Session-Expires Header Field Definition 269 The Session-Expires header field conveys the session interval for a 270 SIP session. It is placed only in INVITE or UPDATE requests, as well 271 as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires 272 header field, it contains a delta-time. 274 The absolute minimum for the Session-Expires header field is 90 275 seconds. This value represents a bit more than twice the duration 276 that a SIP transaction can take in the event of a timeout. This 277 allows sufficient time for a UA to attempt a refresh at the halfpoint 278 of the session interval, and for that transaction to complete 279 normally before the session expires. However, 1800 seconds (30 280 minutes) is RECOMMENDED as the value for the Session-Expires header 281 field. In other words, SIP entities MUST be prepared to handle 282 Session-Expires header field values of any duration greater than 90 283 seconds, but entities that insert the Session-Expires header field 284 SHOULD NOT choose values of less than 30 minutes. 286 Small session intervals can be destructive to the network. They 287 cause excessive messaging traffic that affects both user agents and 288 proxy servers. They increase the possibility of 'glare' that can 289 occur when both user agents send a re-INVITE or UPDATE at the same 290 time. Since the primary purpose of the session timer is to provide a 291 means to time out state in SIP elements, very small values won't 292 generally be needed. 30 minutes was chosen because 95% of phone 293 calls are shorter than this duration. However, the 30 minute minimum 294 is listed as a SHOULD, and not as a MUST, since the exact value for 295 this number is dependent on many network factors, including network 296 bandwidths and latencies, computing power, memory availability, 297 network topology, and, of course, the application scenario. After 298 all, SIP can set up any kind of session, not just a phone call. At 299 the time of publication of this document, 30 minutes seems 300 appropriate. Advances in technologies may result in the number being 301 excessively large five years in the future. 303 The default value of the Session-Expires header field is undefined. 304 This means that the absence of the Session-Expires header field 305 implies no expiration of the session, using the mechanism defined in 306 this specification. Note that other mechanisms not defined in this 307 specification, such as locally configured timers, may apply. 309 The syntax of the Session-Expires header field is as follows: 311 Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds 312 *(SEMI se-params) 313 se-params = refresher-param / generic-param 314 refresher-param = "refresher" EQUAL ("uas" / "uac") 316 Note that a compact form, the letter x, has been reserved for 317 Session-Expires. The BNF for delta-seconds and generic-param is 318 defined in Section 25 of RFC 3261 [RFC3261]. 320 Table 1 is an extension of Tables 2 and 3 in [RFC3261] for the 321 Session-Expires and Min-SE header fields. The column 'PRA' is for 322 the PRACK method [RFC3262], 'UPD' is for the UPDATE method [RFC3311], 323 'SUB' is for the SUBSCRIBE method [RFC3265], and 'NOT' is for the 324 NOTIFY method [RFC3265]. 326 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 327 | Header | wh | pr | A | BY | CA | IN | OP | RE | PR | UP | SU | NO | 328 | | er | ox | C | E | N | V | T | G | A | D | B | T | 329 | | e | y | K | | | | | | | | | | 330 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 331 | Sessio | R | am | - | - | - | o | - | - | - | o | - | - | 332 | n-Expi | | r | | | | | | | | | | | 333 | res | | | | | | | | | | | | | 334 | Sessio | 2x | ar | - | - | - | o | - | - | - | o | - | - | 335 | n-Expi | x | | | | | | | | | | | | 336 | res | | | | | | | | | | | | | 337 | Min-SE | R | am | - | - | - | o | - | - | - | o | - | - | 338 | | | r | | | | | | | | | | | 339 | Min-SE | 42 | | - | - | - | m | - | - | - | m | - | - | 340 | | 2 | | | | | | | | | | | | 341 +--------+----+----+---+----+----+----+----+----+----+----+----+----+ 343 Table 1: Session-Expires and Min-SE Header Fields 345 6. Min-SE Header Field Definition 347 The Min-SE header field indicates the minimum value for the session 348 interval, in units of delta-seconds. When used in an INVITE or 349 UPDATE request, it indicates the smallest value of the session 350 interval that can be used for that session. When present in a 351 request or response, its value MUST NOT be less than 90 seconds. 353 When the header field is not present, its default value for is 90 354 seconds. 356 The Min-SE header field MUST NOT be used in responses except for 357 those with a 422 response code. It indicates the minimum value of 358 the session interval that the server is willing to accept. 360 The syntax of the Min-SE header field is as follows: 362 Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param) 364 7. 422 Response Code Definition 366 This extension introduces the 422 (Session Interval Too Small) 367 response code. It is generated by a UAS or proxy when a request 368 contains a Session-Expires header field with a duration below the 369 minimum timer for the server. The 422 response MUST contain a Min-SE 370 header field with the minimum timer for that server. 372 8. UAC Behavior 374 9. Generating an Initial Session Refresh Request 376 A UAC that supports the session timer extension defined here MUST 377 include a Supported header field in each request (except ACK), 378 listing the option tag 'timer' [RFC3261]. It MUST do so even if the 379 UAC is not requesting usage of the session timer for this session. 381 The UAC MAY include a Require header field in the request with the 382 value 'timer' to indicate that the UAS must support the session timer 383 to participate in the session. This does not mean that the UAC is 384 requiring the UAS to perform the refreshes, only that it is requiring 385 the UAS to support the extension. In addition, the UAC MAY include a 386 Proxy-Require header field in the request with the value 'timer' to 387 indicate that proxies must support the session timer in order to 388 correctly process the request. However, usage of either Require or 389 Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, 390 since the extension works even when only the UAC supports the 391 extension. The Supported header field containing 'timer' MUST still 392 be included, even if the Require or Proxy-Require header fields are 393 present containing 'timer'. 395 A UAC MAY include the Min-SE header field in the initial INVITE 396 request. 398 A UAC MAY include a Session-Expires header field in an initial 399 session refresh request if it wants a session timer applied to the 400 session. The value of this header field indicates the session 401 interval desired by the UAC. If a Min-SE header is included in the 402 initial session refresh request, the value of the Session-Expires 403 MUST be greater than or equal to the value in Min-SE. 405 The UAC MAY include the refresher parameter with value 'uac' if it 406 wants to perform the refreshes. However, it is RECOMMENDED that the 407 parameter be omitted so that it can be selected by the negotiation 408 mechanisms described below. 410 10. Processing a 2xx Response 412 The session timer requires a UA to create and maintain state. This 413 state includes the session interval, the session expiration, and the 414 identity of the refresher. This state is associated with the dialog 415 on which the session has been negotiated. 417 When a 2xx response to a session refresh request arrives, it may or 418 may not contain a Require header field with the value 'timer'. If it 419 does, the UAC MUST look for the Session-Expires header field to 420 process the response. 422 If there was a Require header field in the response with the value 423 'timer', the Session-Expires header field will always be present. 424 UACs MUST be prepared to receive a Session-Expires header field in a 425 response, even if none were present in the request. The 'refresher' 426 parameter will be present in the Session-Expires header field, 427 indicating who will perform the refreshes. The UAC MUST set the 428 identity of the refresher to the value of this parameter. If the 429 parameter contains the value 'uac', the UAC will perform them. It is 430 possible that the UAC requested the session timer (and thus included 431 a Session-Expires header field in the request) and that there was no 432 Require or Session-Expires header field in the 2xx response. This 433 will happen when the UAS doesn't support the session timer extension 434 and only the UAC has asked for a session timer (no proxies have 435 requested it). In this case, if the UAC still wishes to use the 436 session timer (which is purely for its benefit alone), it has to 437 perform them. To do this, the UAC follows the procedures defined in 438 this specification as if the Session-Expires header field were in the 439 2xx response, and its value was the same as that in the request, but 440 with a refresher parameter of 'uac'. 442 If the 2xx response did not contain a Session-Expires header field, 443 there is no session expiration. In this case, no refreshes need to 444 be sent. A 2xx without a Session-Expires can come for both initial 445 and subsequent session refresh requests. This means that the session 446 timer can be 'turned-off' in mid dialog by receiving a response 447 without a Session-Expires header field. 449 The UAC remembers the session interval for a session as the value of 450 the delta-time from the Session-Expires header field in the most 451 recent 2xx response to a session refresh request on a dialog. It is 452 explicitly allowed for there to be differing session intervals (or 453 none at all) on differing dialogs established as a result of a single 454 INVITE. The UAC also remembers whether it or its peer is the 455 refresher on for the session. 457 If the UAC must perform the refreshes, it computes the session 458 expiration for that session. The session expiration is the time of 459 reception of the last 2xx response to a session refresh request on 460 that dialog plus the session interval for that session. If the UA 461 seeks to continue with the session beyond the session expiration, it 462 MUST generate a refresh before the session expiration. It is 464 RECOMMENDED that this refresh be sent once half the session interval 465 has elapsed. Additional procedures for this refresh are described in 466 Section 18. 468 Similarly, a re-INVITE or UPDATE request sent within a dialog for 469 purposes other than session refreshes will also have the effect of 470 refreshing the session, and its processing will follow the procedures 471 defined in this specification. 473 11. Processing a 422 Response 475 If the response to a session refresh request is a 422 (Session 476 Interval Too Small) response message, then the UAC MAY retry the 477 request. The procedures for retrying are described in Section 12. 478 This new request constitutes a new transaction and SHOULD have the 479 same value as the Call-ID, To, and From of the previous request, but 480 the CSeq should contain a new sequence number that is one higher than 481 the previous. 483 12. Generating Subsequent Session Refresh Requests 485 The values of Supported, Require, and Proxy-Require used in the 486 initial Session refresh request MUST be used. 488 The UAC MUST insert the Min-SE header field into a session refresh 489 request for a particular dialog if it has ever received a 422 490 response to a previous session refresh request on the same dialog, or 491 if it has received a session refresh request on that dialog that 492 contained a Min-SE header field. Similarly, if no dialog has been 493 established yet, a UAC MUST insert the Min-SE header field into an 494 INVITE request if it has ever received a 422 response to a previous 495 INVITE request with the same Call-ID. 497 The value of the Min-SE header field present in a session refresh 498 request MUST be the largest value among all Min-SE header field 499 values returned in all 422 responses or received in session refresh 500 requests, on the same dialog, if a dialog has been established. If 501 no dialog has been established, the Min-SE header field value is set 502 to the largest value among all Min-SE header field values returned in 503 all 422 responses for an INVITE request with the same Call-ID. A 504 result of this rule is that the maximum value of the Min-SE is 505 effectively 'cleared' once the dialog is established, and from that 506 point on, only the values from proxies known to be on the proxy path 507 will end up being used. 509 The UAC may have its own opinions about the minimum session interval. 510 In that case, if the value above is too small, the UAC MAY increase 511 it. 513 In a session refresh request sent within a dialog with an active 514 session timer, the Session-Expires header field SHOULD be present. 515 When present, it SHOULD be equal to the maximum of the Min-SE header 516 field (recall that its default value when not present is 90 seconds) 517 and the current session interval. Inclusion of the Session-Expires 518 header field with this value avoids certain denial-of-service 519 attacks, as documented in Section 19. As such, a UA should only 520 ignore the SHOULD in unusual and singular cases where it is desirable 521 to change the session interval mid-dialog. 523 If the session refresh request is not the initial one, it is 524 RECOMMENDED that the refresher parameter be set to 'uac' if the 525 element sending the request is currently performing refreshes, and to 526 'uas' if its peer is performing the refreshes. This way, the role of 527 refresher does not change on each refresh. However, if it wishes to 528 explicitly change the roles, it MAY use a value of 'uas' if it knows 529 that the other side supports the session timer. It could know this 530 by having received a request from its peer with a Supported header 531 field containing the value 'timer'. If it seeks to reselect the 532 roles, it MAY omit the parameter. 534 A re-INVITE generated to refresh the session is a normal re-INVITE, 535 and an UPDATE generated to refresh a session is a normal UPDATE. If 536 a UAC knows that its peer supports the UPDATE method, it is 537 RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can 538 make this determination if it has seen an Allow header field from its 539 peer with the value 'UPDATE', or through a mid-dialog OPTIONS 540 request. It is RECOMMENDED that the UPDATE request not contain an 541 offer [RFC3264], but a re-INVITE SHOULD contain one, even if the 542 details of the session have not changed. In that case, the offer 543 MUST indicate that it has not changed. In the case of SDP, this is 544 accomplished by including the same value for the origin field as did 545 previous SDP messages to its peer. The same is true for an answer 546 exchanged as a result of a session refresh request; if it has not 547 changed, that MUST be indicated. 549 13. Proxy Behavior 551 Session timers are mostly of interest to call stateful proxy servers 552 (that is, to servers that maintain the state of calls and dialogs 553 established through them). However, a stateful proxy server (that 554 is, a server which is aware of transaction state but does not retain 555 call or dialog state) MAY also follow the rules described here. 556 Stateless proxies MUST NOT attempt to request session timers. 557 Proxies that ask for session timers SHOULD record-route, as they 558 won't receive refreshes if they don't. 560 The proxy processing rules require the proxy to remember 561 information between the request and response, ruling out stateless 562 proxies. 564 14. Processing of Requests 566 Processing of requests is identical for all session refresh requests. 568 To request a session timer for a session, a proxy makes sure that a 569 Session-Expires header field is present in a session refresh request 570 for that session. A proxy MAY insert a Session-Expires header field 571 in the request before forwarding it if none was present in the 572 request. This Session-Expires header field may contain any desired 573 expiration time the proxy would like, but not with a duration lower 574 than the value in the Min-SE header field in the request, if it is 575 present. The proxy MUST NOT include a refresher parameter in the 576 header field value. 578 If the request already had a Session-Expires header field, the proxy 579 MAY reduce its value but MUST NOT set it to a duration lower than the 580 value in the Min-SE header field in the request, if it is present. 581 If the value of the Session-Expires header field is greater than or 582 equal to the value in the Min-SE header field (recall that the 583 default is 90 seconds when the Min-SE header field is not present), 584 the proxy MUST NOT increase the value of the Session-Expires header 585 field. If the value of the Session-Expires header field is lower 586 than the value of the Min-SE header field (possibly because the proxy 587 increased the value of the Min-SE header field, as described below), 588 the proxy MUST increase the value of the Session-Expires header field 589 to make it equal to Min-SE header field value. The proxy MUST NOT 590 insert or modify the value of the 'refresher' parameter in the 591 Session-Expires header field. 593 If the request contains a Supported header field with a value 594 'timer', the proxy MAY reject the INVITE request with a 422 (Session 595 Interval Too Small) response if the session interval in the Session- 596 Expires header field is smaller than the minimum interval defined by 597 the proxy's local policy. When sending the 422 response, the proxy 598 MUST include a Min-SE header field with the value of its minimum 599 interval. That minimum MUST NOT be lower than 90 seconds. 601 If the request doesn't indicate support for the session timer but 602 contains a session interval that is too small, the proxy cannot 603 usefully reject the request, as this would result in a call failure. 604 Rather, the proxy SHOULD insert a Min-SE header field containing its 605 minimum interval. If a Min-SE header field is already present, the 606 proxy SHOULD increase (but MUST NOT decrease) the value to its 607 minimum interval. The proxy MUST then increase the Session-Expires 608 header field value to be equal to the value in the Min-SE header 609 field, as described above. A proxy MUST NOT insert a Min-SE header 610 field or modify the value of an existing header field in a proxied 611 request if that request contains a Supported header field with the 612 value 'timer'. This is needed to protect against certain denial of 613 service attacks, described in Section 19. 615 Assuming that the proxy has requested a session timer (and thus has 616 possibly inserted the Session-Expires header field or reduced it), 617 the proxy MUST remember that it is using a session timer, and also 618 remember the value of the Session-Expires header field from the 619 proxied request. This MUST be remembered for the duration of the 620 transaction. 622 The proxy MUST remember, for the duration of the transaction, whether 623 the request contained the Supported header field with the value 624 'timer'. If the request did not contain a Supported header field 625 with the value 'timer', the proxy MAY insert a Require header field 626 with the value 'timer' into the request. However, this is NOT 627 RECOMMENDED. This allows the proxy to insist on a session timer for 628 the session. This header field is not needed if a Supported header 629 field was in the request; in this case, the proxy would already be 630 sure the session timer can be used for the session. 632 15. Processing of Responses 634 When the final response to the request arrives, it is examined by the 635 proxy. 637 If the response does not contain a Session-Expires header field but 638 the proxy remembers that it requested a session timer in the request 639 (by inserting, modifying, or examining and accepting the Session- 640 Expires header field in the proxied request), this means that the UAS 641 did not support the session timer. If the proxy remembers that the 642 UAC did not support the session timer either, the proxy forwards the 643 response upstream normally. There is no session expiration for this 644 session. If, however, the proxy remembers that the UAC did support 645 the session timer, additional processing is needed. 647 Because there is no Session-Expires or Require header field in the 648 response, the proxy knows that it is the first session-timer-aware 649 proxy to receive the response. This proxy MUST insert a Session- 650 Expires header field into the response with the value it remembered 651 from the forwarded request. It MUST set the value of the 'refresher' 652 parameter to 'uac'. The proxy MUST add the 'timer' 654 option tag to any Require header field in the response, and if none 655 was present, add the Require header field with that value before 656 forwarding it upstream. 658 If the received response contains a Session-Expires header field, no 659 modification of the response is needed. 661 In all cases, if the 2xx response forwarded upstream by the proxy 662 contains a Session-Expires header field, its value represents the 663 session interval for the session associated with that response. The 664 proxy computes the session expiration as the time when the 2xx 665 response is forwarded upstream, plus the session interval. This 666 session expiration MUST update any existing session expiration for 667 the session. The refresher parameter in the Session-Expires header 668 field in the 2xx response forwarded upstream will be present, and it 669 indicates which UA is performing the refreshes. There can be 670 multiple 2xx responses to a single INVITE, each representing a 671 different dialog, resulting in multiple session expirations, one for 672 each session associated with each dialog. 674 The proxy MUST NOT modify the value of the Session-Expires header 675 field received in the response (assuming one was present) before 676 forwarding it upstream. 678 16. Session Expiration 680 When the current time equals or passes the session expiration for a 681 session, the proxy MAY remove associated call state, and MAY free any 682 resources associated with the call. Unlike the UA, it MUST NOT send 683 a BYE. 685 17. UAS Behavior 687 The UAS must respond to a request for a session timer by the UAC or a 688 proxy in the path of the request, or it may request that a session 689 timer be used itself. 691 If an incoming request contains a Supported header field with a value 692 'timer' and a Session Expires header field, the UAS MAY reject the 693 INVITE request with a 422 (Session Interval Too Small) response if 694 the session interval in the Session-Expires header field is smaller 695 than the minimum interval defined by the UAS' local policy. When 696 sending the 422 response, the UAS MUST include a Min-SE header field 697 with the value of its minimum interval. This minimum interval MUST 698 NOT be lower than 90 seconds. 700 If the UAS wishes to accept the request, it copies the value of the 701 Session-Expires header field from the request into the 2xx response. 703 The UAS response MAY reduce its value but MUST NOT set it to a 704 duration lower than the value in the Min-SE header field in the 705 request, if it is present; otherwise the UAS MAY reduce its value but 706 MUST NOT set it to a duration lower than 90 seconds. The UAS MUST 707 NOT increase the value of the Session-Expires header field. 709 If the incoming request contains a Supported header field with a 710 value 'timer' but does not contain a Session-Expires header, it means 711 that the UAS is indicating support for timers but is not requesting 712 one. The UAS may request a session timer in the 2XX response by 713 including a Session-Expires header field. The value MUST NOT be set 714 to a duration lower than the value in the Min-SE header field in the 715 request, if it is present. 717 The UAS MUST set the value of the refresher parameter in the Session- 718 Expires header field in the 2xx response. This value specifies who 719 will perform refreshes for the dialog. The value is based on the 720 value of this parameter in the request, and on whether the UAC 721 supports the session timer extension. The UAC supports the extension 722 if the 'timer' option tag was present in a Supported header field in 723 the request. Table 2 defines how the value in the response is set. 724 A value of 'none' in the 2nd column means that there was no refresher 725 parameter in the request. A value of 'NA' in the third column means 726 that this particular combination shouldn't happen, as it is 727 disallowed by the protocol. 729 UAC supports? refresher parameter refresher parameter 730 in request in response 731 ------------------------------------------------------- 732 N none uas 733 N uac NA 734 N uas NA 735 Y none uas or uac 736 Y uac uac 737 Y uas uas 739 Figure 1: UAS Behavior 741 The fourth row of Table 2 describes a case where both the UAC and UAS 742 support the session timer extension, and where the UAC did not select 743 who will perform refreshes. This allows the UAS to decide whether it 744 or the UAC will perform the refreshes. However, as the table 745 indicates, the UAS cannot override the UAC's choice of refresher, if 746 it made one. 748 If the refresher parameter in the Session-Expires header field in the 749 2xx response has a value of 'uac', the UAS MUST place a Require 750 header field into the response with the value 'timer'. This is 751 because the uac is performing refreshes and the response has to be 752 processed for the UAC to know this. If the refresher parameter in 753 the 2xx response has a value of 'uas' and the Supported header field 754 in the request contained the value 'timer', the UAS SHOULD place a 755 Require header field into the response with the value 'timer'. In 756 this case, the UAC is not refreshing, but it is supposed to send a 757 BYE if it never receives a refresh. Since the call will still 758 succeed without the UAC sending a BYE, insertion of the Require is a 759 SHOULD here, and not a MUST. 761 Just like the UAC, the UAS stores state for the session timer. This 762 state includes the session interval, the session expiration, and the 763 identity of the refresher. This state is bound to the dialog used to 764 set up the session. The session interval is set to the value of the 765 delta-time from the Session-Expires header field in the most recent 766 2xx response to a session refresh request on that dialog. It also 767 remembers whether it or its peer is the refresher on the dialog, 768 based on the value of the refresher parameter from the most recent 769 2xx response to a session refresh request on that dialog. If the 770 most recent 2xx response had no Session-Expires header field, there 771 is no session expiration, and no refreshes have to be performed. 773 If the UAS must refresh the session, it computes the session 774 expiration. The session expiration is the time of transmission of 775 the last 2xx response to a session refresh request on that dialog 776 plus the session interval. If UA wishes to continue with the session 777 beyond the session expiration, it MUST generate a refresh before the 778 session expiration. It is RECOMMENDED that this refresh be sent once 779 half the session interval has elapsed. Additional procedures for 780 this refresh are described in Section 18. 782 18. Performing Refreshes 784 The side generating a refresh does so according to the UAC procedures 785 defined in Section 8. Note that only a 2xx response to a session 786 refresh request extends the session expiration. This means that a UA 787 could attempt a refresh and receive a 422 response with a Min-SE 788 header field that contains a value much larger than the current 789 session interval. The UA will still have to send a session refresh 790 request before the session expiration (which has not changed), even 791 though this request will contain a value of the Session-Expires that 792 is much larger than the current session interval. 794 If the session refresh request transaction times out or generates a 795 408 or 481 response, then the UAC sends a BYE request as per 796 Section 12.2.1.2 of RFC 3261 [RFC3261]. If the session refresh 797 request does not generate a 2xx response (and, as a result, the 798 session is not refreshed), and a response other than 408 or 481 is 799 received, the UAC SHOULD follow the rules specific to that response 800 code and retry if possible. For example, if the response is a 401, 801 the UAC would retry the request with new credentials. However, the 802 UAC SHOULD NOT continuously retry the request if the server indicates 803 the same error response. 805 Similarly, if the side not performing refreshes does not receive a 806 session refresh request before the session expiration, it SHOULD send 807 a BYE to terminate the session, slightly before the session 808 expiration. The minimum of 32 seconds and one third of the session 809 interval is RECOMMENDED. 811 Firewalls and NAT ALGs may be very unforgiving about allowing SIP 812 traffic to pass after the expiration time of the session. This is 813 why the BYE should be sent before the expiration. 815 19. Security Considerations 817 The session timer introduces the capability of a proxy or UA element 818 to force compliant UAs to send refreshes at a rate of the element's 819 choosing. This introduces the possibility of denial-of-service 820 attacks with significant amplification properties. These attacks can 821 be launched from 'outsiders' (elements that attempt to modify 822 messages in transit) or by 'insiders' (elements that are legitimately 823 in the request path but are intent on doing harm). Fortunately, both 824 cases are adequately handled by this specification. 826 20. Inside Attacks 828 This introduces the possibility of rogue proxies or UAs introducing 829 denial-of-service attacks. However, the mechanisms in this 830 specification prevent that from happening. 832 First, consider the case of a rogue UAC that wishes to force a UAS to 833 generate refreshes at a rapid rate. To do so, it inserts a Session- 834 Expires header field into an INVITE with a low duration and a 835 refresher parameter equal to uas. Assume it places a Supported 836 header field into the request. The UAS or any proxy that objects to 837 this low timer will reject the request with a 422, thereby preventing 838 the attack. If no Supported header field was present, the proxies 839 will insert a Min-SE header field into the request before forwarding 840 it. As a result, the UAS will not choose a session timer lower than 841 the minimum allowed by all elements on the path. This too prevents 842 the attack. 844 Next, consider the case of a rogue UAS that wishes to force a UAC to 845 generate refreshes at a rapid rate. In that case, the UAC has to 846 support session timer. The initial INVITE arrives at the rogue UAS, 847 which returns a 2xx with a very small session interval. The UAC uses 848 this timer and quickly sends a refresh. Section 12 requires that the 849 UAC copy the current session interval into the Session-Expires header 850 field in the request. This enables the proxies to see the current 851 value. The proxies will reject this request and provide a Min-SE 852 with a higher minimum, which the UAC will then use. Note, that if 853 the proxies did not reject the request, but rather proxied the 854 request with a Min-SE header field, an attack would still be 855 possible. The UAS could discard this header field in a 2xx response 856 and force the UAC to continue to generate rapid requests. 858 In a similar fashion, a rogue proxy cannot force either the UAC or 859 UAS to generate refreshes unless the proxy remains on the signaling 860 path and sees every request and response. 862 21. Outside Attacks 864 An element that can observe and modify a request or response in 865 transit can force rapid session refreshes. To prevent this, requests 866 and responses have to be protected by message integrity. Since the 867 session timer header fields are not end-to-end and are manipulated by 868 proxies, the SIP S/MIME capabilities are not suitable for this task. 869 Rather, integrity has to be protected by using hop-by-hop mechanisms. 870 As a result, it is RECOMMENDED that an element send a request with a 871 Session-Expires header field or a Supported header field with the 872 value 'timer' by using TLS. As adequate protection is obtained only 873 if security is applied on each hop, it is RECOMMENDED that the SIPS 874 URI scheme be used in conjunction with this extension. This means 875 that proxies that record-route and request session timer SHOULD 876 record-route with a SIPS URI. A UA that inserts a Session-Expires 877 header into a request or response SHOULD include a Contact URI that 878 is a SIPS URI. 880 22. IANA Considerations 882 This extension defines two new header fields, a new response code, 883 and a new option tag. SIP [RFC3261] defines IANA procedures for 884 registering these. 886 23. IANA Registration of Min-SE and Session-Expires Header Fields 888 The following is the registration for the Min-SE header field: 890 RFC Number: RFC 4028 891 Header Name: Min-SE 892 Compact Form: none 894 The following is the registration for the Session-Expires header 895 field: 897 RFC Number: RFC 4028 898 Header Name: Session-Expires 899 Compact Form: x 901 24. IANA Registration of the 422 (Session Interval Too Small) Response 902 Code 904 The following is the registration for the 422 (Session Interval Too 905 Small) response code: 907 Response Code: 422 908 Default Reason Phrase: Session Interval Too Small 909 RFC Number: RFC 4028 911 25. IANA Registration of the 'timer' Option Tag 913 The following is the registration for the 'timer' option tag: 915 Name: timer 916 Description: This option tag is for support of the session timer 917 extension. Inclusion in a Supported header field in a request or 918 response indicates that the UA can perform refreshes according to 919 that specification. Inclusion in a Require header in a request 920 means that the UAS must understand the session timer extension to 921 process the request. Inclusion in a Require header field in a 922 response indicates that the UAC must look for the Session-Expires 923 header field in the response and process it accordingly. 925 26. Example Call Flow 927 Example Session Timer Flow 929 Alice Proxy P1 Proxy P2 Bob 930 |(1) INVITE | | | 931 |SE: 50 | | | 932 |----------->| | | 933 |(2) 422 | | | 934 |MSE: 3600 | | | 935 |<-----------| | | 936 |(3) ACK | | | 937 |----------->| | | 938 |(4) INVITE | | | 939 |SE:3600 | | | 940 |MSE:3600 | | | 941 |----------->| | | 943 | |(5) INVITE | | 944 | |SE:3600 | | 945 | |MSE:3600 | | 946 | |----------->| | 947 | |(6) 422 | | 948 | |MSE:4000 | | 949 | |<-----------| | 950 | |(7) ACK | | 951 | |----------->| | 952 |(8) 422 | | | 953 |MSE:4000 | | | 954 |<-----------| | | 955 |(9) ACK | | | 956 |----------->| | | 957 |(10) INVITE | | | 958 |SE:4000 | | | 959 |MSE:4000 | | | 960 |----------->| | | 961 | |(11) INVITE | | 962 | |SE:4000 | | 963 | |MSE:4000 | | 964 | |----------->| | 965 | | |(12) INVITE | 966 | | |SE:4000 | 967 | | |MSE:4000 | 968 | | |----------->| 969 | | |(13) 200 OK | 970 | | |SE:4000 | 971 | | |<-----------| 972 | |(14) 200 OK | | 973 | |SE:4000 | | 974 | |<-----------| | 975 |(15) 200 OK | | | 976 |SE:4000 | | | 977 |<-----------| | | 978 |(16) ACK | | | 979 |----------->| | | 980 | |(17) ACK | | 981 | |------------------------>| 982 |(18) UPDATE | | | 983 |SE:4000 | | | 984 |----------->| | | 985 | |(19) UPDATE | | 986 | |SE:4000 | | 987 | |------------------------>| 988 | |(20) 200 OK | | 989 | |SE:4000 | | 990 | |<------------------------| 992 |(21) 200 OK | | | 993 |SE:4000 | | | 994 |<-----------| | | 995 | |(22) BYE | | 996 | |<------------------------| 997 |(23) BYE | | | 998 |<-----------| | | 999 | |(24) 408 | | 1000 | |------------------------>| 1002 Figure 2: Example Session Timer Flow 1004 Figure 1 gives an example of a call flow that makes use of the 1005 session timer. In this example, both the UAC and UAS support the 1006 session timer extension. The initial INVITE request generated by the 1007 UAC, Alice (message 1), might look like this: 1009 INVITE sips:bob@biloxi.example.com SIP/2.0 1010 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1011 Supported: timer 1012 Session-Expires: 50 1013 Max-Forwards: 70 1014 To: Bob 1015 From: Alice ;tag=1928301774 1016 Call-ID: a84b4c76e66710 1017 CSeq: 314159 INVITE 1018 Contact: 1019 Content-Type: application/sdp 1020 Content-Length: 142 1022 (Alice's SDP not shown) 1024 This request indicates that Alice supports the session timer, and is 1025 requesting session refreshes every 50 seconds. This arrives at the 1026 first proxy, P1. This session interval is below the minimum allowed 1027 value of 3600. So P1 rejects the request with a 422 (message 2): 1029 SIP/2.0 422 Session Interval Too Small 1030 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1031 ;received=192.0.2.1 1032 Min-SE: 3600 1033 To: Bob ;tag=9a8kz From: Alice 1034 ;tag=1928301774 Call-ID: 1035 a84b4c76e66710 CSeq: 314159 INVITE 1037 This response contains a Min-SE header field with the value 3600. 1038 Alice then retries the request. This time, the request contains a 1039 Min-SE header, as Alice has received a 422 for other INVITE requests 1040 with the same Call-ID. The new request (message 4) might look like 1041 this: 1043 INVITE sips:bob@biloxi.example.com SIP/2.0 1044 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1045 Supported: timer 1046 Session-Expires: 3600 1047 Min-SE: 3600 1048 Max-Forwards: 70 1049 To: Bob 1050 From: Alice ;tag=1928301774 1051 Call-ID: a84b4c76e66710 1052 CSeq: 314160 INVITE 1053 Contact: 1054 Content-Type: application/sdp 1055 Content-Length: 142 1057 (Alice's SDP not shown) 1059 Proxy P1 record-routes. Since the session interval is now acceptable 1060 to it, it forwards the request to P2 (message 5). However, the 1061 session interval is below its minimum configured amount of 4000. So 1062 it rejects the request with a 422 response code (message 6) and 1063 includes a Min-SE header field with the value of 4000. Once more, 1064 Alice retries the INVITE. This time, the Min-SE header field in her 1065 INVITE is the maximum of all Min-SE she has received (3600 and 4000). 1066 Message 10 might look like this: 1068 INVITE sips:bob@biloxi.example.com SIP/2.0 1069 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1070 Supported: timer 1071 Session-Expires: 4000 1072 Min-SE: 4000 1073 Max-Forwards: 70 1074 To: Bob 1075 From: Alice ;tag=1928301774 1076 Call-ID: a84b4c76e66710 1077 CSeq: 314161 INVITE 1078 Contact: 1079 Content-Type: application/sdp 1080 Content-Length: 142 1082 (Alice's SDP not shown) 1084 P1 record-routes once again, but P2 does not (this wouldn't normally 1085 happen; presumably, if it asked for session timer, it would record- 1086 route the subsequent request). The UAS receives the request. It 1087 copies the Session-Expires header from the request to the response 1088 and adds a refresher parameter with value 'uac'. This 200 OK is 1089 forwarded back to Alice. The response she receives (message 15) 1090 might look like this: 1092 SIP/2.0 200 OK 1093 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 1094 ;received=192.0.2.1 1095 Require: timer 1096 Supported: timer Record-Route: sips:p1.atlanta.example.com;lr 1097 Session-Expires: 4000;refresher=uac To: Bob 1098 ;tag=9as888nd From: Alice 1099 ;tag=1928301774 Call-ID: 1100 a84b4c76e66710 CSeq: 314161 INVITE Contact: 1101 Content-Type: application/sdp Content-Length: 142 1103 (Bob's SDP not shown) 1105 Alice generates an ACK (message 16), which is routed through P1 and 1106 then to Bob. Since Alice is the refresher, around 2000 seconds later 1107 Alice sends an UPDATE request to refresh the session. Because this 1108 request is part of an established dialog and Alice has not received 1109 any 422 responses or requests on that dialog, there is no Min-SE 1110 header field in her request (message 18): 1112 UPDATE sips:bob@192.0.2.4 SIP/2.0 1113 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1114 Route: sips:p1.atlanta.example.com;lr 1115 Supported: timer 1116 Session-Expires: 4000;refresher=uac 1117 Max-Forwards: 70 1118 To: Bob ;tag=9as888nd 1119 From: Alice ;tag=1928301774 1120 Call-ID: a84b4c76e66710 1121 CSeq: 314162 UPDATE 1122 Contact: 1124 This is forwarded through P1 to Bob. Bob generates a 200 OK, copying 1125 the Session-Expires header field into the response. This is 1126 forwarded through P1 and arrives at Alice. The response she receives 1127 (message 21) might look like this: 1129 SIP/2.0 200 OK 1130 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 1131 ;received=192.0.2.1 1132 Require: timer 1133 Session-Expires: 4000;refresher=uac To: Bob 1134 ;tag=9as888nd From: Alice 1135 ;tag=1928301774 Call-ID: 1136 a84b4c76e66710 CSeq: 314162 UPDATE Contact: 1138 Shortly afterward, Alice's UA crashes. As a result, she never sends 1139 a session refresh request. 3968 seconds later, Bob times out and 1140 sends a BYE request (message 22). This is sent to P1. P1 attempts 1141 to deliver it but fails (because Alice's UA has crashed). P1 then 1142 returns a 408 (Request Timeout) to Bob. 1144 27. Acknowledgements 1146 The authors wish to thank Brett Tate for his contributions to this 1147 work. Brian Rosen completed the editing of the document. 1149 28. References 1151 28.1. Normative References 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, 1155 DOI 10.17487/RFC2119, March 1997, 1156 . 1158 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1159 A., Peterson, J., Sparks, R., Handley, M., and E. 1160 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1161 DOI 10.17487/RFC3261, June 2002, 1162 . 1164 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1165 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1166 2002, . 1168 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1169 with Session Description Protocol (SDP)", RFC 3264, 1170 DOI 10.17487/RFC3264, June 2002, 1171 . 1173 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1175 May 2017, . 1177 28.2. Informative References 1179 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1180 Translator (NAT) Terminology and Considerations", 1181 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1182 . 1184 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1185 Provisional Responses in Session Initiation Protocol 1186 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1187 . 1189 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1190 Event Notification", RFC 3265, DOI 10.17487/RFC3265, June 1191 2002, . 1193 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1194 Jacobson, "RTP: A Transport Protocol for Real-Time 1195 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1196 July 2003, . 1198 Appendix A. 1200 Funding for the RFC Editor function is currently provided by the 1201 Internet Society. 1203 Authors' Addresses 1205 Christer Holmberg 1206 Ericsson 1207 Hirsalantie 11 1208 Jorvas 02420 1209 Finland 1211 Email: christer.holmberg@ericsson.com 1213 Steve Donovan 1214 Cisco Systems, Inc. 1215 2200 E. President George Bush Turnpike 1216 Richardson, Texas 75082 1217 US 1219 Email: srd@cisco.com 1221 Jonathan Rosenberg 1222 Cisco Systems, Inc. 1223 600 Lanidex Plaza 1224 Parsippany, New Jersey 07054 1225 US 1227 Email: jdrosen@cisco.com