idnits 2.17.1 draft-ietf-mmusic-sip-session-timer-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 327 has weird spacing: '... where enc. ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Steve Donovan 2 Internet Draft MCI Worldcom 3 June, 1999 Expires December, 1999 4 draft-ietf-mmusic-sip-session-timer-02.txt 6 SIP Session Timer 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference mate- 20 rial or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/lid-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document proposes an extension to the SIP specification [1]. 31 This extension adds a new message header, Session-Expires, which is 32 used to specify the duration of a requested session. 34 A session timer can be used to control the duration of a session if, 35 for instance, one of the participants in the session wants to limit 36 the cost of the session. Stateful SIP Proxy Servers can also use a 37 session timer to track the status of sessions for which session state 38 exists on the servers. Currently a stateful SIP Proxy Server that is 39 not handling the media stream(s) for the session has no mechanism to 40 definitively determine the state of all sessions for which it has 41 state. While the SIP Specification does provide the BYE method for 42 terminating the session, there is no mechanism for a SIP Proxy Server 43 to detect the end of a session when the BYE message is not sent or is 44 lost due to network problems. 46 1.0 Introduction 48 The need for the addition of a session timer was initially motivated 49 by the realization that stateful proxy servers currently have no 50 method of determining the end of a session in certain anomalous situ- 51 ations. For instance, when a user agent fails to send a BYE message 52 at the end of a session or the BYE message gets lost due to network 53 problems. In this situation, the stateful proxy will retain state 54 for the session and has no deterministic method of determining when 55 the state no longer applies. 57 With the addition of a session timer to the SIP protocol, the state- 58 ful proxy server will have the option of tearing down the session 59 upon the expiration of the session timer. 61 A session timer can also be used for other purposes. For instance, 62 it could be used in the implementation of a prepaid service. In this 63 case all session related signaling would be routed through a SIP 64 server that would control the session time based on a subscriber's 65 prepaid account. The SIP server could use the session timer to force 66 the tear down of the session within a specific time. The session 67 timer could also be used by the user agent as a trigger to indicate 68 to the subscriber that the prepaid account requires more funds to 69 extend the call. 71 This document proposes the addition of the Session-Expires header to 72 various SIP messages. In addition, a new Request Failure message is 73 proposed. This message would be used to indicate session timer prob- 74 lems, including the need for a session-expires header in an INVITE 75 message and the need for a smaller session-expires time. 77 2.0 Session-Expires Header Field Definition 79 The Session-Expires header shall be used by user agents or proxy 80 servers to indicate the maximum duration of a session. 82 The format of the Session-Expires header shall be equivalent to the 83 format of the Expires header (see section 6.20 in [1]). As such, the 84 end of the session can be specified as either an absolute or delta 85 time. 87 The Session-Expires header shall be valid in INVITE and ACK requests. 88 In addition it shall be valid in certain response messages. This 89 includes the 200 OK response and the new Request Failure responses 90 defined in this document. 92 The called UA or any SPS in the path of the session signaling shall 93 have the option of rejecting an INVITE that does not contain the Ses- 94 sion-Expires header if the service context in which the session 95 request is made requires the use of the session timer. 97 The called UA has the option of adding the Session-Expires header to 98 the 200 OK response in the case where there was not Session-Expires 99 header in the INVITE message. 101 An SPS shall also have the option of adding the Session-Expires 102 header to an INVITE message. 104 In addition, the called UA and SPS shall have the option of modifying 105 the value in the Session-Expires header. This modification shall 106 only be to decrease the requested duration of the session. 108 The start time of the session shall be based on receipt of the 200 OK 109 message by the calling UA and receipt of the ACK message by the SPS 110 and called UA. 112 If the called UA or the SPS requires a session timer for a requested 113 session and the calling UA does not include the Session-Expires 114 header in the INVITE message, then the called UA or the SPS should 115 reject the request with a 487 request failure message. 117 If the use of a session timer is desirable but optional for the ses- 118 sion and the calling UA does not include the Session-Expires header 119 in the INVITE then the called UA or SPS should add a Session-Expires 120 header to the next session setup message. In this case the SPS shall 121 add the Session-Expires header to the INVITE message and the called 122 UA shall add the Session-Expires header to the 200 OK response mes- 123 sage. 125 The calling UA shall have the ability to request an extension to the 126 duration of the session by sending a re-INVITE message for the ses- 127 sion with a new Session-Expires header. See section 1.4.6, Changing 128 an Existing Session, in [1]. 130 The calling UA or any SPS in the path of the session signaling shall 131 have the ability to reject the change in the session duration. 133 Upon expiration of the session timer, the calling UA and called UA 134 shall have the option of terminating the session using the normal BYE 135 method. 137 In addition, a SPS shall have the option of tearing down an expired 138 session by sending a BYE to both the called UA and the calling UA. 139 It is recommended that the SPS delay tearing down the session long 140 enough for a retry of a lost re-INVITE to be received by the SPS. 141 This will also reduce the possibility of both a UA and SPS attempting 142 to tear down the call simultaneously. 144 3.0 Behavior of SIP User Agents 146 3.1 Behavior of User Agent Clients 147 A User Agent Client (UAC) shall have the ability to include the Ses- 148 sion-Expires header in an INVITE message. 150 The UAC shall have the ability to request an extension of the session 151 timer by sending an INVITE message for an existing session with a 152 Session-Expires header. This should be done enough in advance of the 153 session timeout to prevent the called UA or the SPS from timing out 154 the session prior to receipt of the new INVITE. 156 When requesting an extension of the session, the UAC shall use a 157 value in the Session-Expires header that is less-than or equal to the 158 value of the Session-Expires header received in the 200 OK from the 159 original setup of the session. 161 The UAC shall have the ability to receive a Session-Expires header in 162 a 200 OK message. This is independent of whether or not a Session- 163 Expires was included in the original INVITE message. 165 The UAC shall have the ability to accept the session time indicated 166 in the 200 OK Session-Expires header by including unchanged Session- 167 Expires header in the ACK to the 200 OK. 169 The UAC shall have the ability to reject the session time indicated 170 in the 200 OK message by not including a Session-Expires header in 171 the ACK to the 200 OK message. 173 In general, if the UAC is able to support session timers then it 174 should accept the session time included in the 200 OK, even if it 175 changed between the INVITE and the 200 OK. 177 3.2 Behavior of User Agent Servers 179 The User Agent Server shall have the ability to reject an INVITE mes- 180 sage that does not contain a Session-Expires header if the INVITE is 181 received in a service context that requires a session timer. The UAS 182 shall reject the INVITE using the following response: 184 487 Session-Expires Header Problem 185 Session-Expires: n 187 The UAS shall have the ability to provisionally reject an INVITE 188 request based on the contents of the Session-Expires header received 189 in the INVITE message. For instance, the UAS may choose to reject 190 the INVITE if the requested session time is longer than the UAS 191 desires to participate in the session. The UAS shall use the follow- 192 ing message to reject the request: 194 487 Session-Expires Header Problem 195 Session-Expires: n 197 In both cases, the UAS shall include in the 487 response an accept- 198 able delta time for the session. 200 If the Session-Expires header contains a delta time then the UAS 201 shall calculate the end of the session based on receipt of the ACK 202 message that completes a successful session initiation: 204 End of session time = Receipt of ACK time + Session-Expires time 206 The UAS shall have the ability to reject a request to extend the 207 length of the session. The UAS shall do so by sending the following 208 response: 210 487 Session Time Request Problem 211 Session-Expires: n 213 A value of zero (0) in the Session-Expires header shall indicate that 214 the extension request is rejected. Any other value should be less 215 than that received in the re-INVITE message and should indicate an 216 acceptable extension to the session timer. 218 If the Session-Expires header in the re-INVITE contains a delta time 219 then the UAS shall calculate the new end of the session from the pre- 220 vious end of session time: 222 New end of session time = Previous end of session time + delta time 224 If a request to extend the session time is rejected by the UAS then 225 the end of session time that existed prior to the extension request 226 shall be remain in effect. 228 The UAS shall have the ability to add a Session-Expires header to a 229 200 OK response for an INVITE request that did not contain a session- 230 Expires header. 232 If the UAS adds a Session-Expires header to the 200 OK response and 233 the resulting ACK does not contain a Session-Expires header then the 234 UAS has the following options: 236 The UAS can choose to participate in the session without a session 237 timer. The UAS can choose to not participate in the session. In 238 this case, the UAS shall send a BYE message to tear down the session. 240 The UAS shall have the ability to decrease the requested session time 241 in the INVITE Session-Expires header. 243 If the UAS is sending a 200 OK to an INVITE that contained a Session- 244 Expires header then the UAS shall include a Session-Expires header in 245 the 200 OK. The content of the Session-Expires header shall be 246 either the content of the Session-Expires header contained in the 247 INVITE request, if the UAS accepts the requested duration, or a 248 decreased value of the session timer desired by the UAS. 250 4.0 Behavior of SIP Proxy Servers 252 A SIP Proxy Server has the option of tracking the duration of ses- 253 sions for which it is a proxy. 255 If the SPS receives an INVITE without a Session-Expires header, it 256 has the option of sending the following request failure response 257 indicating that the Session-Expires header is required: 259 487 Session-Expires Header Problem 260 Session-Expires: n 262 A SPS has the option of rejecting an INVITE with a Session-Expires 263 header based on the time specified in the header. For instance, if 264 the time specified is too long. The proxy server shall do so by send- 265 ing the following request failure response: 267 487 Session-Expires Header Problem 268 Session-Expires: n 270 In both cases, the SPS shall include in the 487 response an accept- 271 able delta time for the session. 273 If the Session-Expires header contains a delta time then the SPS 274 shall use the method of calculating the session time specified in 275 section 3.2. 277 A SPS has the option of rejecting a request for an extension of the 278 session timer for an existing session by sending the following 279 request failure response: 281 487 Session-Expires Header Problem 282 Session-Expires: n 284 A value of zero (0) in the Session-Expires header shall indicate that 285 the extension request is rejected. Any other value should be less 286 than that received in the re-INVITE message and should indicate an 287 acceptable extension to the session timer. 289 If the SPS accepts the request to extend the session timer then it 290 shall use the method of calculating the new end of session time spec- 291 ified in section 3.2. 293 The SPS shall have the ability to add a Session-Expires header to an 294 INVITE request that does not contain a Session-Expires header. 296 The SPS shall have the ability to decrease the requested session time 297 in the INVITE Session-Expires header. 299 The content of the Session-Expires header included in the INVITE sent 300 by the SPS shall be either the content of the Session-Expires header 301 contained in the INVITE request, if the UAS accepts the requested 302 duration, or a decreased value of the session timer desired by the 303 SPS. 305 If the SPS adds a Session-Expires header to the 200 OK response and 306 the resulting ACK does not contain a Session-Expires header then the 307 SPS has the following options: 309 - The SPS can choose to allow the session without a session timer. 311 - The SPS can choose to not allow the session. 313 A SPS shall have the option of tearing down sessions that have 314 expired. Note that the SPS should wait for the calling UA or called 315 UA to terminate the call using normal mechanisms. If the calling UA 316 and the called UA fail to send a BYE as a result of session expira- 317 tion then the SPS can choose to end the call. 319 The SPS shall terminate the call by sending BYE requests to the call- 320 ing UA and the called UA. 322 5.0 Header Field Definitions 324 The following is an extension of tables 4 and 5 in [1] for the Ses- 325 sion-Expires header: 327 where enc. e-e ACK BYE CAN INV OPT REG 328 Session-Expires R e o - - o - - 329 Session-Expires 200 e - - - o - - 330 Session-Expires 487 e - - - o - - 332 6.0 Request Failure Messages 334 6.1 487 Session-Expires Header Problem 336 The server received an INVITE request with one of the following prob- 337 lems: 339 - The server requires a Session-Expires header. In this case the 340 response should contain a Session-Expires header with an acceptable 341 session time. 343 - The server received an INVITE with a Session-Expires header with an 344 expiration time longer than the server is willing to accept. In this 345 case the response should contain a Session-Expires header with an 346 acceptable session time. 348 - The server received an INVITE with a Session-Expires header for an 349 existing session and the server does not wish to extend the session. 350 In this case the response should contain a Session-Expires header 351 with a value of zero (0). 353 - The server received an INVITE with a Session-Expires header for an 354 existing session with an expiration time longer than the server is 355 willing to accept. In this case the response should contain a Ses- 356 sion-Expires header with an acceptable session time. 358 7.0 Security Considerations 360 There are no security considerations unique to the Session-Expires 361 header. 363 8.0 Examples 365 The following examples are meant to illustrate the functionality 366 associated with the Session-Expires header. In the interest of 367 brevity, other headers are intentionally left out of the SIP mes- 368 sages. 370 8.1 Basic session-timer setup with UAS detected timeout 372 Calling UA -> Called UA 373 INVITE 374 Session-Expires: 120 376 Calling UA <- Called UA 377 200 OK 378 Session-Expires: 120 380 Calling UA -> Called UA 381 ACK Calling UA starts session timer 382 Session-Expires: 120 383 Called UA Receipt of ACK Called UA starts session timer 385 Calling UA determines need to extend session time 387 Calling UA -> Called UA 388 INVITE 389 Session-Expires: 120 391 Calling UA <- Called UA 392 200 OK 393 Session-Expires: 120 395 Calling UA -> Called UA 396 ACK Calling UA resets session end time 397 Session-Expires: 120 398 Called UA Receipt of ACK Called UA resets session timer 400 Session timeout detected by Called UA 402 Calling UA <- Called UA 403 BYE 405 Calling UA -> Called UA 406 200 OK 408 8.2 Basic negotiation with SPS Detected timeout 410 Calling UA -> SPS 411 INVITE 412 Session-Expires: 240 414 SPS -> Called UA 415 INVITE SPS wants a shorter timer 416 Session-Expires: 180 418 SPS <- Called UA 419 200 OK Called UA wants a shorter timer 420 Session-Expires: 120 422 Calling UA <- SPS 423 200 OK 424 Session-Expires: 120 426 Calling UA -> SPS 427 ACK Calling UA starts session timer 428 Session-Expires: 120 429 SPS Receipt of ACK SPS starts session timer 431 SPS -> Called UA 432 ACK Called UA starts session timer 433 Session-Expires: 120 435 Session timeout detected by SPS 437 Calling UA <- SPS 438 BYE 440 SPS -> Called UA 441 BYE 443 Calling UA -> SPS 444 200 OK 446 SPS <- Called UA 447 200 OK 449 8.3 No Session-Expires Header Rejection by SPS 451 Calling UA -> SPS 452 INVITE No Session-Expires header 454 Calling UA <- SPS 455 4xx Session-Expires Header Required 456 Session-Expires: 120 Suggested session time 458 Calling UA -> SPS 459 INVITE 460 Session-Expires: 120 462 Session setup continues 464 8.4 Invalid Session-Expires Header Rejection by SPS 466 Calling UA -> SPS 467 INVITE No Session-Expires header 468 Session-Expires: 1000 470 Calling UA <- SPS 471 4xx Session Time Request Rejected 472 Session-Expires: 120 Suggested session time 474 Calling UA -> SPS 475 INVITE 476 Session-Expires: 120 478 Session setup continues 480 8.5 Session-Expires Header Added by SPS, Rejected by UAC 482 Calling UA -> SPS 483 INVITE 485 SPS -> Called UA 486 INVITE SPS adds S-E header 487 Session-Expires: 180 489 SPS <- Called UA 490 200 OK Called UA wants shorter timer 491 Session-Expires: 120 493 Calling UA <- SPS 494 200 OK 495 Session-Expires: 120 497 Calling UA -> SPS 498 ACK Calling UA does not include S-E header 500 The SPS has the choice of allowing or not allowing the call as a 501 result of the Calling UA not supporting the Session-Expires function. 503 9.0 Changes in this version 505 The changes in this version of the document were primarily editorial 506 in nature. 508 It was also reworded to indicate that both the calling and the called 509 user agents shall be able to request extensions to the session time. 511 10.0 References 513 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 514 Session Initiation Protocol", RFC 2543, March 1999. 516 11.0 Author's Address 518 Steven R. Donovan 519 MCI Worldcom 520 1493/678 521 901 International Parkway 522 Richardson, Texas 75081 523 Email: steven.r.donovan@mci.com