idnits 2.17.1 draft-elwell-sipping-redirection-reason-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 612. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 626), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '...his need, a 3xx response MAY contain a...' RFC 2119 keyword, line 555: '... field SHOULD be able to suppress th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6890 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) -- No information found for draft-ietf-sipping-history-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Elwell 3 Internet Draft Siemens 4 R. Jesske 5 Deutsche Telekom 6 J. McMillen 7 Avaya Inc. 8 draft-elwell-sipping-redirection-reason-02.txt 9 Expires: December 2005 June 2005 11 SIP Reason header extension for indicating redirection reasons 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress. " 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This proposes an extension to the SIP Reason header to provide 41 additional information concerning retargeting in SIP, a particular 42 motivation being improved interoperability with PSTN diversion. 44 Table of Contents 46 1 Introduction....................................................3 47 2 Requirements....................................................3 48 3 Overview of proposed solution...................................4 49 4 Extension to the Reason header..................................4 50 5 Inclusion of the Reason header in 3xx responses.................5 51 6 Examples........................................................6 52 6.1 Retargeting with reason "Forward Unconditional" to PSTN.......6 53 6.2 Retargeting with reason "Forward Busy"........................7 54 6.3 Recursion with reason "Forward Busy" to PSTN..................9 55 6.4 Redirection request from PSTN................................10 56 7 IANA considerations............................................12 57 8 Security Considerations........................................13 58 9 Author's Addresses.............................................13 59 10 Normative References..........................................13 61 1 Introduction 63 Central to SIP [2] is the concept of redirecting or retargeting a 64 request by a proxy, whereby the Request-URI in the original request 65 is replaced before forwarding the request on the next hop. Sometimes 66 this is due to normal rerouting behaviour of the proxy (e.g., 67 resolving an address-of-record URI to a contact URI). At other times 68 it is due to more application-related reasons, e.g., where a user has 69 made arrangements for calls to that user under certain conditions to 70 be forwarded to a different destination. 72 The History-Info header [3] provides a means for conveying 73 information about a retarget to the final destination UAS and also 74 back to the UAC. In addition to providing the retargeted-from and 75 retargeted-to URIs for each recorded retarget, this header also 76 conveys a reason by means of the Reason header. The Reason header 77 accompanies the retargeted-from URI and reflects the reason why 78 attempts to reach that target failed, normally in the form of the SIP 79 response code concerned. 81 However, the repertoire of reasons available for use in the Reason 82 header is sometimes insufficient to reflect application-related 83 reasons for retargeting. In particular it cannot reflect accurately 84 the range of reasons used in PSTN/ISDN for call "diversion". This 85 makes it difficult to provide interworking with PSTN/IDSN for calls 86 that undergo retargeting / diversion and also makes it difficult for 87 SIP-based networks to offer a behaviour similar to that of diversion 88 in PSTN/ISTN. 90 2 Requirements 92 REQ-1. Provide a means for a gateway to provide information in a SIP 93 INVITE request to reflect PSTN diversion reasons when mapping a 94 diverted PSTN call request to a SIP INVITE request. 96 REQ-2. Provide a means for a gateway to provide information in a 97 response to a SIP INVITE request to reflect PSTN diversion reasons 98 when mapping a response to a PSTN call establishment request to a 99 response to a SIP INVITE request. 101 REQ-3. Provide a means for a gateway to provide information in a 3xx 102 response to a SIP INVITE request to reflect PSTN diversion reasons 103 when mapping a PSTN call diversion request to a 3xx response to a SIP 104 INVITE request. 106 REQ-4. Provide a means for a gateway to obtain information from a SIP 107 retargeted or recursed SIP INVITE request for deriving PSTN diversion 108 reasons when mapping the SIP INVITE request to a PSTN call 109 establishment request. 111 REQ-5. Provide a means for a gateway to obtain information from a 112 response to a retargeted or recursed SIP INVITE request for deriving 113 PSTN diversion reasons when mapping the SIP response to a response to 114 a PSTN call establishment request. 116 REQ-6. Provide a means for a gateway to obtain information from a 3xx 117 response to a SIP INVITE request for deriving PSTN diversion reasons 118 when mapping the SIP 3xx response to a PSTN call diversion request. 120 3 Overview of proposed solution 122 The proposed solution is to enhance the Reason header with new values 123 that reflect diversion reasons in PSTN/ISDN. This can be done by 124 defining a new "protocol" value and then defining specific new reason 125 values under the umbrella of the new "protocol" value. The enhanced 126 Reason header can then be used as a parameter of a History-Info 127 header field entry. This allows the forwarding of PSTN diversion 128 reasons when mapping an INVITE request or response containing a 129 History-Info header field to/from PSTN signalling. 131 In addition the enhanced Reason header can be used in a 3xx response 132 to an INVITE request. This fulfils two functions. First, it allows 133 the forwarding of PSTN diversion reasons when mapping a 3xx response 134 to an INVITE request to/from PSTN signalling. Secondly it provides 135 information to a proxy or UAC for inclusion in the History-Info 136 header field when the request undergoes recursion. 138 Candidate reasons include forward unavailable, forward busy, forward 139 no reply, forward unconditional, deflection immediate, deflection 140 alerting, hunting, mobile not reachable. 142 Note that selection of the new target may depend on several other 143 conditions (e.g., relating to date, time, the source of the request 144 or caller preferences), but the reasons suggested above should be 145 sufficient to convey the main circumstance leading to the retarget. 147 4 Extension to the Reason header 149 This document defines the following new protocol value for the 150 protocol field of the Reason header field in [1]: 152 Redirection: The cause parameter contains a reason for redirection 153 of a request. 155 This document defines the following redirection cause codes: 157 Value Default Text Description 159 1 Normal redirection The call has been retargeted for 160 normal routing reasons 162 2 Forward unavailable The call has been retargeted 163 because the called user is 164 unavailable (no registered contact). 166 3 Forward busy The call has been retargeted 167 because the called user is busy. 169 4 Forward no reply The call has been retargeted 170 because the called user has been 171 alerted but has failed to reply. 173 5 Forward unconditional The call has been retargeted 174 immediately without determining 175 whether the called user is 176 unavailable or busy and without 177 alerting the user. 179 6 Deflection immediate The call has been retargeted as a 180 result of a request by the called 181 user's device without alerting the 182 called user. 184 7 Deflection alerting The call has been retargeted as a 185 result of action by the called user 186 in response to alerting. 188 8 Hunting The call has been retargeted to an 189 individual member of the hunt group 190 at which it was previously targeted. 192 9 Mobile not reachable The call has been retargeted 193 because the called mobile user is 194 not reachable 196 Example syntax is as follows: 198 Reason: redirection;cause=3 ;text="Forward busy" 200 5 Inclusion of the Reason header in 3xx responses 202 [1] states that the Reason header field is not usually needed in 203 responses because the status code and the reason phrase already 204 provide sufficient information. However, this is not so in the case 205 of a 3xx response, since there may be a need to provide a diversion 206 reason in the 3xx response for inclusion in the History-Info header 207 field in the event of recursion or for mapping directly to/from PSTN. 208 Therefore in order to satisfy this need, a 3xx response MAY contain a 209 Reason header field. 211 NOTE. [1] states that the Reason header can appear in any response 212 whose status code explicitly allows the presence of this field. The 213 statement above performs this function. 215 6 Examples 217 6.1 Retargeting with reason "Forward Unconditional" to PSTN 219 Alice Proxy Bob Gateway 220 | | | | 221 | INVITE F1 | | | 222 |--------------->| | | 223 | | | | 224 |(100 Trying) F2 | | | 225 |<---------------| | | 226 | | | INVITE F3 | 227 | |--------------------------------->| 228 | | | 180 Ringing F4 | 229 | |<---------------------------------| 230 | 180 Ringing F5 | | | 231 |<---------------| | 200 OK F6 | 232 | | | | 233 | |<---------------------------------| 234 | 200 OK F7 | | | 235 |<---------------| | | 236 | ACK F8 | | | 237 |--------------->| | ACK F9 | 238 | |--------------------------------->| 240 Assuming the entity sending the INVITE supports the History-Info 241 header, the INVITE would look like this: 243 F1 (INVITE) Alice -> Proxy 245 INVITE sip:Bob@example.com; SIP/2.0 246 From: ;tag=2 247 To: 248 Call-ID: 12345600@example.com 249 CSeq: 1 INVITE 250 History-Info: ;index=1 251 ... 253 The call is then retargeted to a contact URI 254 . The forwarded INVITE request would 255 be as follows: 257 F3 (INVITE) � Proxy -> Gateway 259 INVITE sip:12345@gateway.example.com SIP/2.0 260 From: ;tag=2 261 To: 262 Call-ID: 12345600@example.com 263 CSeq: 1 INVITE 264 History-Info: ;index=1, 266 ;index=2 268 Note that in accordance with [2] the following escape characters 269 are used within parameters of URL headers: %3B for semicolon, %3D 270 for equals, %22 for double quote and %20 for space. 272 The "index 1" entry indicates that the call to Bob was retargeted 273 because of redirection reason forward unconditional. 275 The "index 2" entry indicates that the call to 12345 has not yet been 276 further retargeted. 278 The Reason header field provides a diversion reason that can be 279 included in relevant PSTN messaging. 281 6.2 Retargeting with reason "Forward Busy" 283 Alice Proxy Bob Gateway 284 | | | | 285 | INVITE F1 | | | 286 |--------------->| INVITE F3 | | 287 | |------------->| | 288 |(100 Trying) F2 | | | 289 |<---------------| | | 290 | | 486 Busy | | 291 | | here F4 | | 292 | |<-------------| | 293 | | ACK F5 | | 294 | |------------->| | 295 | | | INVITE F6 | 296 | |--------------------------------->| 297 | | | 180 Ringing F7 | 298 | |<---------------------------------| 299 | 180 Ringing F8 | | | 300 |<---------------| | 200 OK F9 | 301 | |<---------------------------------| 302 | 200 OK F10 | | | 303 |<---------------| | | 304 | ACK F11 | | | 305 |--------------->| | ACK F12 | 306 | |--------------------------------->| 308 Assuming the entity sending the INVITE supports the History-Info 309 header, the INVITE would look like this: 311 F1 (INVITE) Alice -> Proxy 313 INVITE sip:Bob@example.com; SIP/2.0 314 From: ;tag=2 315 To: 316 Call-ID: 12345600@example.com 317 CSeq: 1 INVITE 318 History-Info: ;index=1 319 ... 321 Bob indicates a Busy so that a 486 response is send back. 323 F4 (486 Busy Here) Bob -> Proxy 325 SIP/2.0 486 Busy Here 326 From: ;tag=2 327 To: ;tag=3 328 Call-ID: 12345600@example.com 329 CSeq: 1 INVITE 331 � 332 On receipt of F4 (486 Busy Here) and because of forwarding on busy 333 provisioned at the proxy on behalf of Bob, the call is then 334 retargeted to a URI . This URI is pre- 335 provisioned within the Proxy. The forwarded INVITE request would be 336 as follows: 338 F6 (INVITE) � Proxy -> Gateway 340 INVITE sip:12345@gateway.example.com SIP/2.0 341 From: ;tag=2 342 To: 343 Call-ID: 12345600@example.com 344 CSeq: 1 INVITE 345 History-Info: ;index=1, 347 ;index=2 349 The "index 1" entry indicates that the call to Bob was retargeted. 351 The "index 2" entry indicates that the call to 12345 has not yet been 352 further retargeted. 354 The Reason header field for index 1 provides a diversion reason that 355 can be included in relevant PSTN messaging. 357 6.3 Recursion with reason "Forward Busy" to PSTN 359 Alice Proxy Bob Gateway 360 | | | | 361 | INVITE F1 | | | 362 |--------------->| INVITE F3 | | 363 | |------------->| | 364 |(100 Trying) F2 | | | 365 |<---------------| | | 366 | | 302 Moved | | 367 | |Temporarily F4| | 368 | |<-------------| | 369 | | ACK F5 | | 370 | |------------->| | 371 | | | INVITE F6 | 372 | |--------------------------------->| 373 | | | 180 Ringing F7 | 374 | |<---------------------------------| 375 | 180 Ringing F8 | | | 376 |<---------------| | 200 OK F9 | 377 | |<---------------------------------| 378 | 200 OK F10 | | | 379 |<---------------| | | 380 | ACK F11 | | | 381 |--------------->| | ACK F12 | 382 | |--------------------------------->| 384 Assuming the entity sending the INVITE supports the History-Info 385 header, the INVITE would look like this: 387 F1 (INVITE) Alice -> Proxy 389 INVITE sip:Bob@example.com; SIP/2.0 390 From: ;tag=2 391 To: 392 Call-ID: 12345600@example.com 393 CSeq: 1 INVITE 394 History-Info: ;index=1 395 ... 397 Because of forwarding on busy at Bob, the call is then redirected to 398 a contact URI in a 302 response. The 399 response would be as follows: 401 F4 (302 Moved Temporarily) Bob -> Proxy 403 SIP/2.0 302 Moved temporarily 404 From: ;tag=2 405 To: ;tag=3 406 Call-ID: 12345600@example.com 407 CSeq: 1 INVITE 408 Contact: 409 Reason=Redirection;cause=3;text="Forward busy" 410 � 412 The call then undergoes recursion to the contact URI 413 . The forwarded INVITE request would 414 be as follows: 416 F6 (INVITE) � Proxy -> Gateway 418 INVITE sip:12345@gateway.example.com SIP/2.0 419 From: ;tag=2 420 To: 421 Call-ID: 12345600@example.com 422 CSeq: 1 INVITE 423 History-Info: ;index=1, 425 ;index=2 427 The "index 1" entry indicates that the call to Bob was retargeted 428 (recursed). 430 The "index 2" entry indicates that the call to 12345 has not yet been 431 further retargeted. 433 The Reason header field for index 1 provides a diversion reason that 434 can be included in relevant PSTN messaging. 436 6.4 Redirection request from PSTN 438 Alice Proxy Gateway Bob 439 | | | | 440 | INVITE F1 | | | 441 |--------------->| INVITE F3 | | 442 | |------------->| | 443 |(100 Trying) F2 | | | 444 |<---------------| | | 445 | | 302 Moved | | 446 | |Temporarily F4| | 447 | |<-------------| | 448 | | ACK F5 | | 449 | |------------->| | 450 | | | INVITE F6 | 451 | |--------------------------------->| 452 | | | 180 Ringing F7 | 453 | |<---------------------------------| 454 | 180 Ringing F8 | | | 455 |<---------------| | 200 OK F9 | 456 | |<---------------------------------| 457 | 200 OK F10 | | | 458 |<---------------| | | 459 | ACK F11 | | | 460 |--------------->| | ACK F12 | 461 | |--------------------------------->| 463 Assuming the entity sending the INVITE supports the History-Info 464 header, the INVITE would look like this: 466 F1 (INVITE) Alice -> Proxy 468 INVITE sip:12345@gateway.example.com; SIP/2.0 469 From: ;tag=2 470 To: 471 Call-ID: 12345600@example.com 472 CSeq: 1 INVITE 473 History-Info: ;index=1 474 ... 476 Because of forwarding on busy in the PSTN to a number that the 477 gateway is able to resolve to Bob, the call is then redirected to a 478 contact URI in a 302 response. The response 479 would be as follows: 481 F4 (302 Moved Temporarily) Gateway -> Proxy 483 SIP/2.0 302 Moved temporarily 484 From: ;tag=2 485 To: ;tag=3 486 Call-ID: 12345600@example.com 487 CSeq: 1 INVITE 488 Contact: 489 Reason=Redirection;cause=3;text="Forward busy" 490 � 492 The Reason header field is derived from PSTN messaging. 494 The call then undergoes recursion to the contact URI 495 . The forwarded INVITE request would be as 496 follows: 498 F6 (INVITE) � Proxy -> Gateway 500 INVITE sip:Bob@example.com SIP/2.0 501 From: ;tag=2 502 To: 503 Call-ID: 12345600@example.com 504 CSeq: 1 INVITE 505 History-Info: ;index=1, 507 ;index=2 509 The "index 1" entry indicates that the call to the PSTN was 510 retargeted (recursed) with reason Forward busy, the Reason header 511 field having been copied from the 302 response. 513 The "index 2" entry indicates that the call to Bob has not yet been 514 further retargeted. 516 7 IANA considerations 518 This document defines one new value for the SIP Reason header [1] 519 protocol namespace. The new value is "Redirection" and indicates the 520 use of cause value defined in this document. 522 This document also creates an IANA registry for cause values that 523 populate the cause field of the Reason header when protocol value 524 "Redirection" is used and corresponding default values that populate 525 the text field. The current cause and text values in this new 526 registry are as follows: 528 Cause value Default text value Reference 529 ----------- ------------------------------ 530 1 Normal redirection This document 531 2 Forward unavailable This document 532 3 Forward busy This document 533 4 Forward no reply This document 534 5 Forward unconditional This document 535 6 Deflection immediate This document 536 7 Deflection alerting This document 537 8 Hunting This document 538 9 Mobile not reachable This document 540 New values for this registry can only be defined by means of a 541 published standard. 543 8 Security Considerations 545 The security considerations of [1] apply. When the Reason header 546 field is embedded within a History-Info header field, the security 547 considerations of [3] apply. 549 Unauthorised insertion, deletion of modification of the Reason header 550 field can provide misleading information to users and applications. 551 Eavesdropping on this header field can reveal information about a 552 user. Securing of SIP connections by TLS can combat this problem. 554 A SIP entity that can provide a redirection reason in a Reason header 555 field SHOULD be able to suppress this in accordance with privacy 556 requirements of the user concerned. 558 9 Author's Addresses 560 John Elwell 561 Siemens Communications 562 Technology Drive 563 Beeston 564 Nottingham, UK, NG9 1LA 565 email: john.elwell@siemens.com 567 Roland Jesske 568 Deutsch Telekom 569 Am Kavalleriesand 3 570 Germany-64295 Darmstadt 571 email: r.jesske@t-com.net 573 Joanne McMillen 574 Avaya Inc. 575 1300 W. 120th Ave. 576 Westminster, CO 80234-2726 577 email: joanne@avaya.com 579 10 Normative References 581 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the 582 Session Initiation Protocol (SIP)", RFC 3326. 584 [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 585 protocol", RFC 3261. 587 [3] M. Barnes, "An Extension to the Session Initiation Protocol for 588 Request History Information", draft-ietf-sipping-history-info-03 589 (work in progress). 591 Intellectual Property Statement 592 The IETF takes no position regarding the validity or scope of any 593 Intellectual Property Rights or other rights that might be claimed to 594 pertain to the implementation or use of the technology described in 595 this document or the extent to which any license under such rights 596 might or might not be available; nor does it represent that it has 597 made any independent effort to identify any such rights. Information 598 on the IETF's procedures with respect to rights in IETF Documents can 599 be found in BCP 78 and BCP 79. 601 Copies of IPR disclosures made to the IETF Secretariat and any 602 assurances of licenses to be made available, or the result of an 603 attempt made to obtain a general license or permission for the use of 604 such proprietary rights by implementers or users of this 605 specification can be obtained from the IETF on-line IPR repository at 606 http://www.ietf.org/ipr. 608 The IETF invites any interested party to bring to its attention any 609 copyrights, patents or patent applications, or other proprietary 610 rights that may cover technology that may be required to implement 611 this standard. Please address the information to the IETF at ietf- 612 ipr@ietf.org. 614 Disclaimer of Validity 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 619 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 620 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 621 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 624 Copyright Statement 626 Copyright (C) The Internet Society (2005). 628 This document is subject to the rights, licenses and restrictions 629 contained in BCP 78, and except as set forth therein, the authors 630 retain all their rights. 632 Acknowledgement 634 Funding for the RFC Editor function is currently provided by the 635 Internet Society.