idnits 2.17.1 draft-elwell-sipping-redirection-reason-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 475. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 491), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** 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 409: '... 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 (October 2004) is 7133 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' == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-07 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Elwell 2 Internet Draft Siemens 3 R. Jesske 4 Deutsche Telekom 5 J. McMillen 6 Avaya Inc. 7 draft-elwell-sipping-redirection-reason-01.txt 8 Expires: April 2005 October 2004 10 SIP Reason header extension for indicating redirection reasons 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress. " 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This examines the need for signalling additional information 40 concerning the reason for redirection in SIP and proposes an 41 extension to the Reason header. 43 Indicating redirection reasons in SIP October 2004 45 Table of Contents 47 1 Introduction....................................................3 48 2 Overview of proposed solution...................................4 49 3 Extension to the Reason header..................................4 50 4 Examples........................................................5 51 4.1 Redirection with reason "Forward Immediate"...................5 52 4.2 Call Forwarding Unconditional.................................7 53 5 IANA considerations.............................................9 54 6 Security Considerations.........................................9 55 7 Author's Addresses..............................................9 56 8 Normative References...........................................10 58 Indicating redirection reasons in SIP October 2004 60 1 Introduction 62 Central to SIP [2] is the concept of redirecting or retargeting a 63 request by a proxy, whereby the Request-URI in the original request 64 is replaced before forwarding the request on the next hop. Sometimes 65 this is due to normal rerouting behaviour of the proxy (e.g., 66 resolving an address-of-record URI to a contact URI). At other times 67 it is due to more application-related reasons, e.g., where a user has 68 made arrangements for calls to that user under certain conditions to 69 be forwarded to a different destination. Also retargeting can be 70 performed as a result of a 3xx response from a redirect server. 71 Different 3xx response codes reflect different reasons for rejecting 72 the request. A 3xx response can be accompanied by a Reason header [1] 73 giving more information. 75 The History-Info header [3] provides a means for conveying 76 information about a retarget to the final destination UAS and also 77 back to the UAC. In addition to providing the retargeted-from and 78 retargeted-to URIs for each recorded retarget, this header also 79 conveys a reason by means of the Reason header. The Reason header 80 accompanies the retargeted-from URI and reflects the reason why 81 attempts to reach that target failed, normally in the form of the SIP 82 response code concerned. 84 However, there is nothing in either a 3xx response or the History- 85 Info header, including the Reason header, to indicate an explicit 86 reason for the redirection request or the retarget respectively. At 87 present the reason is implicit in the reason for failure of the 88 request to the original target. Sometimes this might give an accurate 89 picture of what is happening, but not always. Consider the following 90 cases: 92 1. A device acts as a redirect server because it is busy. None of 93 the 3xx response codes can reflect that the reason for retargeting 94 to the URI given in the Contact header of the 3xx response is 95 because the existing target is busy. 97 2. A device acts as a redirect server because it alerts the user 98 but fails to get a reply within a certain time. None of the 3xx 99 response codes can reflect that the reason for retargeting to the 100 URI given in the Contact header of the 3xx response is because the 101 existing target failed to answer. 103 3. A proxy is scripted to retarget requests without first 104 attempting to forward them to the original target. Retargeting may 105 be unconditional or based on certain conditions such as date, time, 106 the source of the request or caller preferences. Because it does 108 Indicating redirection reasons in SIP October 2004 110 this without forwarding the request to the original target, no SIP 111 response code is applicable. 113 4. A proxy is scripted to perform hunting or distribution of calls 114 among a number of different targets. When forwarding a request to a 115 target selected from a list of candidate targets, the reason for 116 retargeting is because of hunting or distribution, rather than 117 because of any failure of the existing target. 119 5. In the hunting or distribution scenario above, forwarding a 120 request to one target from the list of candidate targets may fail 121 for a particular reason (e.g., busy), leading to selection of 122 another target from the list. However, the reason for retargeting 123 is because of hunting or distribution, not specifically because the 124 previous target had a certain condition. 126 With these considerations in mind, there is a need to provide a 127 solution for conveying a more precise reason for redirection in a 3xx 128 response or a History-Info header. 130 In addition, in some circumstances a proxy can generate a 181 "Call 131 Is Being Forwarded" response. In this case no History-Info header 132 would be included, since the response does not come from a UAS. At 133 present a 181 response does not convey a precise reason for 134 forwarding. Provision of a reason for forwarding might be of use to 135 the UAC, which otherwise would need to wait for a later response 136 containing a History-Info header. 138 2 Overview of proposed solution 140 The proposed solution is to enhance the Reason header with new 141 values. This can be done by defining a new "protocol" value and then 142 defining specific new reason values under the umbrella of the new 143 "protocol" value. 145 Candidate reasons include forward unavailable, forward busy, forward 146 no reply, forward immediate, deflection, hunting, mobile not 147 reachable. 149 Note that selection of the new target may depend on several other 150 conditions (e.g., relating to date, time, the source of the request 151 or caller preferences), but the reasons suggested above should be 152 sufficient to convey the main circumstance leading to the retarget. 154 3 Extension to the Reason header 156 This document defines the following new protocol value for the 157 protocol field of the Reason header field in [1]: 159 Indicating redirection reasons in SIP October 2004 161 Redirection: The cause parameter contains a reason for redirection 162 of a request. 164 This document defines the following redirection cause codes: 166 Value Default Text Description 168 1 Normal redirection The call has been retargeted for 169 normal routing reasons 171 2 Forward unavailable The call has been retargeted 172 because the called user is 173 unavailable (no registered contact). 175 3 Forward busy The call has been retargeted 176 because the called user is busy. 178 4 Forward no reply The call has been retargeted 179 because the called user has been 180 alerted but has failed to reply. 182 5 Forward immediate The call has been retargeted 183 immediately without determining 184 whether the called user is 185 unavailable or busy and without 186 alerting the user. 188 6 Deflection The call has been retargeted as a 189 result of a request by the called 190 user in response to alerting. 192 7 Hunting The call has been retargeted to an 193 individual member of the hunt group 194 at which it was previously targeted. 196 8 Mobile not reachable The call has been retargeted 197 because the called mobile user is 198 not reachable 200 Example syntax is as follows: 202 Reason: redirection;cause=3 ;text="Forward busy" 204 4 Examples 206 4.1 Redirection with reason "Forward Immediate" 208 Alice Proxy Bob Carol 209 | | | | 211 Indicating redirection reasons in SIP October 2004 213 | INVITE F1 | | | 214 |--------------->| INVITE F2 | | 215 | |------------->| | 216 |(100 Trying) F3 | | | 217 |<---------------| 302 Moved Temporarily F4 | 218 | |<-------------| | 219 | | ACK F5 | | 220 | |------------->| | 221 | | | INVITE F6 | 222 | |--------------------------------->| 223 | | | 180 Ringing F7 | 224 | |<---------------------------------| 225 | 180 Ringing F8 | | | 226 |<---------------| | 200 OK F9 | 227 | |<---------------------------------| 228 | 200 OK F10 | | | 229 |<---------------| | | 230 | ACK F11 | | | 231 |--------------->| | ACK F12 | 232 | |--------------------------------->| 234 Assuming the entity sending the INVITE supports the History-Info 235 header, the INVITE would look like this: 237 F1 (INVITE) Alice -> Proxy 239 INVITE sip:Bob@example.com; SIP/2.0 240 From: ;tag=2 241 To: 242 Call-ID: 12345600@example.com 243 CSeq: 1 INVITE 244 History-Info: ;index=1 245 ... 247 The call is then redirected to a contact URI 248 in a 302 response. The response would be as follows: 250 F3 (302 Moved Temporarily) Bob -> Proxy 252 SIP/2.0 302 Moved temporarily 253 From: ;tag=2 254 To: ;tag=3 255 Call-ID: 12345600@example.com 256 CSeq: 1 INVITE 257 Contact: 258 Reason: Redirection;cause=5;text="Forward immediate" 259  261 Indicating redirection reasons in SIP October 2004 263 The call would be retargeted to the contact URI. The first History- 264 Info header would be augmented with the two reasons for retargeting 265 (SIP 302 and redirection 5)). A second History-Info header would be 266 added with the new retargeted-to Request-URI: 268 F6 (INVITE) � Proxy -> Carol 270 INVITE sip:Carol@example.com SIP/2.0 271 From: ;tag=2 272 To: 273 Call-ID: 12345600@example.com 274 CSeq: 1 INVITE 275 History-Info: ;index=1, ;index=2 279 The "index 1" entry indicates that the call to Bob was retargeted 280 because of SIP response code 302 and redirection reason CFI. 282 The "index 2" entry indicates that the call to Carol has not yet been 283 further retargeted. 285 4.2 Call Forwarding Unconditional 287 This example is taken from [4], augmented to show the use of History- 288 Info and Reason headers. 290 Alice Proxy Gateway 291 | | | 292 | INVITE F1 | | 293 |--------------->| | 294 |(100 Trying) F2 | | 295 |<---------------| | 296 | (181 Call Is Being Forwarded) F3 297 |<---------------| INVITE F4 | 298 | |------------->| 299 | |180 Ringing F5| 300 | 180 Ringing F6 |<-------------| 301 |<---------------| 200 OK F7 | 302 | 200 OK F8 |<-------------| 303 |<---------------| | 304 | ACK F9 | | 305 |--------------->| ACK F10 | 306 | |------------->| 307 | Both way RTP Established | 308 |<=============================>| 309 | BYE F11 | | 310 |--------------->| BYE F12 | 311 | |------------->| 313 Indicating redirection reasons in SIP October 2004 315 | | 200 OK F13 | 316 | 200 OK F14 |<-------------| 317 |<---------------| | 318 | | | 320 Bob wants all calls forwarded to a destination in the PSTN (which is 321 just another URI to the proxy server). Alice calls Bob. The proxy 322 server rewrites the Request URI, and forwards the INVITE to a 323 Gateway. Details of messaging behind the Gateway are not shown. 325 Message Details 327 F3 (181 Call is Being Forwarded) Proxy -> Alice 329 SIP/2.0 181 Call is Being Forwarded 330 Via: SIP/2.0/TLS 331 client.atlanta.example.com:5061;branch=z9hG4bK74bf9 332 ;received=192.0.2.103 333 From: Alice ;tag=1234567 334 To: Bob 335 Call-ID: 12345600@atlanta.example.com 336 CSeq: 1 INVITE 337 Content-Length: 0 338 Reason: Redirection;cause=5;text="Forward immediate" 340 F4 INVITE Proxy -> Gateway 342 INVITE sips:+19727293660@gw1.example.com;user=phone SIP/2.0 343 Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK83749.1 344 Via: SIP/2.0/TLS 345 client.atlanta.example.com:5061;branch=z9hG4bK74bf9 346 ;received=192.0.2.103 347 Record-Route: 348 Max-Forwards: 69 349 From: Alice ;tag=1234567 350 To: Bob 351 Call-ID: 12345600@atlanta.example.com 352 CSeq: 1 INVITE 353 Contact: 354 History-Info: ;index=1, 356 ;index=2 357 Content-Type: application/sdp 358 Content-Length: ... 360 v=0 361 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 362 s=Session SDP 363 c=IN IP4 client.atlanta.example.com 365 Indicating redirection reasons in SIP October 2004 367 t=3034423619 0 368 m=audio 49170 RTP/AVP 0 369 a=rtpmap:0 PCMU/8000 371 5 IANA considerations 373 This document defines one new value for the SIP Reason header [1] 374 protocol namespace. The new value is "Redirection" and indicates the 375 use of cause value defined in this document. 377 This document also creates an IANA registry for cause values that 378 populate the cause field of the Reason header when protocol value 379 "Redirection" is used and corresponding default values that populate 380 the text field. The current cause and text values in this new 381 registry are as follows: 383 Cause value Default text value Reference 384 ----------- ------------------------------ 385 1 Normal redirection This document 386 2 Forward unavailable This document 387 3 Forward busy This document 388 4 Forward no reply This document 389 5 Forward immediate This document 390 6 Deflection This document 391 7 Hunting This document 392 8 Mobile not reachable This document 394 New values for this registry can only be defined by means of a 395 published standard. 397 6 Security Considerations 399 The security considerations of [1] apply. When the Reason header 400 field is embedded within a History-Info header field, the security 401 considerations of [3] apply. 403 Unauthorised insertion, deletion of modification of the Reason header 404 field can provide misleading information to users and applications. 405 Eavesdropping on this header field can reveal information about a 406 user. Securing of SIP connections by TLS can combat this problem. 408 A SIP entity that can provide a redirection reason in a Reason header 409 field SHOULD be able to suppress this in accordance with privacy 410 requirements of the user concerned. 412 7 Author's Addresses 414 John Elwell 415 Siemens Communications 417 Indicating redirection reasons in SIP October 2004 419 Technology Drive 420 Beeston 421 Nottingham, UK, NG9 1LA 422 email: john.elwell@siemens.com 424 Roland Jesske 425 Deutsch Telekom 426 Am Kavalleriesand 3 427 Germany-64295 Darmstadt 428 email: r.jesske@t-com.net 430 Joanne McMillen 431 Avaya Inc. 432 1300 W. 120th Ave. 433 Westminster, CO 80234-2726 434 email: joanne@avaya.com 436 8 Normative References 438 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the 439 Session Initiation Protocol (SIP)", RFC 3326. 441 [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 442 protocol", RFC 3261. 444 [3] M. Barnes, "An Extension to the Session Initiation Protocol for 445 Request History Information", draft-ietf-sipping-history-info-03 446 (work in progress). 448 [4] A. Johnston et alia, "Session Initiation Protocol Service 449 Examples", draft-ietf-sipping-service-examples-07 (work in progress). 451 Intellectual Property Statement 453 The IETF takes no position regarding the validity or scope of any 454 Intellectual Property Rights or other rights that might be claimed to 455 pertain to the implementation or use of the technology described in 456 this document or the extent to which any license under such rights 457 might or might not be available; nor does it represent that it has 458 made any independent effort to identify any such rights. Information 459 on the IETF's procedures with respect to rights in IETF Documents can 460 be found in BCP 78 and BCP 79. 462 Copies of IPR disclosures made to the IETF Secretariat and any 463 assurances of licenses to be made available, or the result of an 464 attempt made to obtain a general license or permission for the use of 465 such proprietary rights by implementers or users of this 466 specification can be obtained from the IETF on-line IPR repository at 467 http://www.ietf.org/ipr. 469 Indicating redirection reasons in SIP October 2004 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary 473 rights that may cover technology that may be required to implement 474 this standard. Please address the information to the IETF at ietf- 475 ipr@ietf.org. 477 Disclaimer of Validity 479 This document and the information contained herein are provided on an 480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 482 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 483 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 484 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 487 Copyright Statement 489 Copyright (C) The Internet Society (2004). This document is subject 490 to the rights, licenses and restrictions contained in BCP 78, and 491 except as set forth therein, the authors retain all their rights. 493 Acknowledgement 495 Funding for the RFC Editor function is currently provided by the 496 Internet Society.