idnits 2.17.1 draft-elwell-sipping-redirection-reason-00.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.5 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 363), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 32. ** 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? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 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 Security Considerations section. ** 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.) 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 (May 2004) is 7285 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) == Unused Reference: '1' is defined on line 315, but no explicit reference was found in the text -- No information found for draft-ietf-sipping-history-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 4 draft-elwell-sipping-redirection-reason-00.txt 5 Expires: November 2004 May 2004 7 Indicating redirection reasons in SIP 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3667. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress. " 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This examines the need for signalling additional information 37 concerning the reason for redirection in SIP and proposes two 38 possible solutions. 40 Table of Contents 42 1 Introduction....................................................3 43 2 Candidate solutions.............................................4 44 2.1 Solution 1 - add a new "protocol" value to the Reason header..4 45 2.2 Solution 2 - add a new redirection-reason parameter to a contact 46 URI...............................................................6 47 3 Conclusions.....................................................8 48 4 Acknowledgements................................................8 49 5 Author's Addresses..............................................8 50 6 Normative References............................................8 52 1 Introduction 54 Central to SIP [2] is the concept of redirecting or retargeting a 55 request by a proxy, whereby the Request-URI in the original request 56 is replaced before forwarding the request on the next hop. Sometimes 57 this is due to normal rerouting behaviour of the proxy (e.g., 58 resolving an address-of-record URI to a contact URI). At other times 59 it is due to more application-related reasons, e.g., where a user has 60 made arrangements for calls to that user under certain conditions to 61 be forwarded to a different destination. Also retargeting can be 62 performed as a result of a 3xx response from a redirect server. 63 Different 3xx response codes reflect different reasons for rejecting 64 the request. 66 The History-Info header [3] provides a means for conveying 67 information about a retarget to the final destination UAS and also 68 back to the UAC. In addition to providing the retargeted-from and 69 retargeted-to URIs for each recorded retarget, this header also 70 conveys a reason by means of the Reason header. The Reason header 71 accompanies the retargeted-from URI and reflects the reason why 72 attempts to reach that target failed, normally in the form of the SIP 73 response code concerned. 75 However, there is nothing in either a 3xx response or the History- 76 Info header to indicate an explicit reason for the redirection 77 request or the retarget respectively. At present the reason is 78 implicit in the reason for failure of the request to the original 79 target. Sometimes this might give an accurate picture of what is 80 happening, but not always. Consider the following cases: 82 1. A device acts as a redirect server because it is busy. None of 83 the 3xx response codes can reflect that the reason for retargeting 84 to the URI given in the Contact header of the 3xx response is 85 because the existing target is busy. 87 2. A device acts as a redirect server because it alerts the user 88 but fails to get a reply within a certain time. None of the 3xx 89 response codes can reflect that the reason for retargeting to the 90 URI given in the Contact header of the 3xx response is because the 91 existing target failed to answer. 93 3. A proxy is scripted to retarget requests without first 94 attempting to forward them to the original target. Retargeting may 95 be unconditional or based on certain conditions such as date, time, 96 the source of the request or caller preferences. Because it does 97 this without forwarding the request to the original target, no SIP 98 response code is applicable. 100 4. A proxy is scripted to perform hunting or distribution of calls 101 among a number of different targets. When forwarding a request to a 102 target selected from a list of candidate targets, the reason for 103 retargeting is because of hunting or distribution, rather than 104 because of any failure of the existing target. 106 5. In the hunting or distribution scenario above, forwarding a 107 request to one target from the list of candidate targets may fail 108 for a particular reason (e.g., busy), leading to selection of 109 another target from the list. However, the reason for retargeting 110 is because of hunting or distribution, not specifically because the 111 previous target had a certain condition. 113 This seems to point to a need to convey in a 3xx response or a 114 History-Info header the reason for selecting the retargeted-to URI. 115 Candidate reasons are: 117 CFI, "Call forwarding immediate" - immediate retargeting without 118 forwarding the request to the retargeted-from URI; 120 CFB, "Call forwarding busy" - retargeting because the retargeted-from 121 URI is busy; 123 CFNR, "Call forwarding no reply" - retargeting because there was no 124 reply at the retargeted-from URI; 126 CD, "Call deflection" - retargeting because the user at the 127 retargeted-from URI made a request in real time for retargeting; 129 HUNT, "Hunting" - selection of the target by means of hunting or 130 distribution; 132 NORMAL "Normal redirection" (default) - normal retargeting of a 133 request. 135 Note that selection of the new target may depend on several other 136 conditions (e.g., relating to date, time, the source of the request 137 or caller preferences), but the reasons suggested above should be 138 sufficient to convey the main circumstance leading to the retarget. 140 Two candidate solutions are discussed below. 142 2 Candidate solutions 144 2.1 Solution 1 - add a new "protocol" value to the Reason header 146 New reasons could be achieved by adding a new "protocol" value in the 147 Reason header. For example, assume a session was initiated to 148 sip:+14084953756@foo.com;user=phone. 150 Assuming the entity sending the INVITE supports the History-Info 151 header, the INVITE would look like this: 153 INVITE sip:+14084953756@foo.com;user=phone SIP/2.0 154 From: "Mr. Whatever" ;tag=2 155 To: 156 Call-ID: 12345600@foo.com 157 CSeq: 1 INVITE 158 History-Info: ;index=1 159 ... 161 The call is then redirected to a contact URI 162 in a 302 response. The response 163 would be as follows: 165 SIP/2.0 302 Moved temporarily 166 From: "Mr. Whatever" ;tag=2 167 To: ;tag=3 168 Call-ID: 12345600@foo.com 169 CSeq: 1 INVITE 170 Contact: 171 Reason: Redirection; cause=CFI 172 � 174 The call would be retargeted to the contact URI. The first History- 175 Info header would be augmented with the two reasons for retargeting 176 (302 and CFI)). A second History-Info header would be added with the 177 new retargeted-to Request-URI: 179 INVITE sip:+44123456789@foo.com;user=phone SIP/2.0 180 From: "Mr. Whatever" ;tag=2 181 To: 182 Call-ID: 12345600@foo.com 183 CSeq: 1 INVITE 184 History-Info: ;index=1, ;index=2 188 The "index 1" entry indicates that the call to +1-408-495-3756 was 189 retargeted because of SIP response code 302 and redirection reason 190 CFI. 192 The "index 2" entry indicates that the call to +44-123456789 has not 193 yet been further retargeted. 195 For the case where the proxy initiates retargeting (not as a result 196 of a 3xx response from a redirect server), the proxy itself would 197 need to generate the Reason header with Redirection;cause=CFI for 198 inclusion in the index 2 URI in History-Info. 200 This solution would require either a new standards track RFC or a 201 standard published by another organisation to define the new 202 "protocol" value in the Reason header. 204 There is an impact on History-Info in that History-Info is required 205 to capture the Redirection reason in a Reason header (since it's not 206 part of the Contact URI in this case). In the current History-Info 207 draft, only the SIP response code is captured in a Reason header. 209 2.2 Solution 2 - add a new redirection-reason parameter to a contact 210 URI 212 New reasons could be indicated using a new parameter in a URI. 214 For example, assume a session was initiated to 215 sip:+14084953756@foo.com;user=phone. 217 Assuming the entity sending the INVITE supports the History-Info 218 header, the INVITE would look like this: 220 INVITE sip:+14084953756@foo.com;user=phone SIP/2.0 221 From: "Mr. Whatever" ;tag=2 222 To: 223 Call-ID: 12345600@foo.com 224 CSeq: 1 INVITE 225 History-Info: ;index=1 226 ... 228 The call is then redirected to a contact URI 229 in a 302 230 response. The response would be as follows: 232 SIP/2.0 302 Moved temporarily 233 From: "Mr. Whatever" ;tag=2 234 To: ;tag=3 235 Call-ID: 12345600@foo.com 236 CSeq: 1 INVITE 237 Contact: 239 � 241 The call would be retargeted to the contact URI. The first History- 242 Info header will be augmented with the Redirection reason (302). A 243 second History-Info header is added with the new retargeted Request- 244 URI: 246 INVITE sip:+44123456789@foo.com;user=phone;redirection-reason=CFI 247 SIP/2.0 248 From: "Mr. Whatever" ;tag=2 249 To: 250 Call-ID: 12345600@foo.com 251 CSeq: 1 INVITE 252 History-Info: ;index=1, 254 ;index=2 257 The "index 1" entry indicates that the call to +1-408-495-3756 was 258 retargeted because of SIP response code 302. 260 The "index 2" entry indicates that the call to +44-123456789 has not 261 yet been further retargeted, but that it was made as a result of a 262 CFI redirection-reason. 264 For the case where the proxy initiates retargeting (not as a result 265 of a 3xx response from a redirect server), the proxy itself would 266 need to generate the redirection-reason parameter for inclusion in 267 the index 2 URI in History-Info. 269 This solution has the advantage that the redirection reason is 270 associated with a particular contact URI and would automatically get 271 copied as part of the contact URI into the Request-URI of the 272 retargeted request. It would be backward compatible with existing 273 implementations of History-Info, since it would automatically be 274 copied with the URI into the History-Info header. 276 A possible disadvantage is that URI parameters are intended to 277 influence a request constructed from the URI. It might be argued that 278 redirection-reason does not meet this requirement. 280 Note the difference between this and solution 1, whereby the 281 additional reason is placed in the index 1 URI for solution 1 but in 282 the index 2 URI for solution 2. It is arguable which is the more 283 appropriate. Also solution 1 could be adapted to use the index 2 URI, 284 if considered more appropriate. 286 The SIP and SIPS URIs are extensible in that new parameters can be 287 added and will be ignored by any implementation that does not 288 understand them. There are plans to create an IANA registry for URI 289 parameters (draft-ietf-sip-uri-parameter-reg-01), and this will 290 require that new parameters be defined in an RFC. 292 There is no impact on the History-Info draft. 294 3 Conclusions 296 The SIP community is asked to express its opinions on the two 297 proposed solutions or suggest other alternatives. 299 4 Acknowledgements 301 The author would like to acknowledge considerable assistance from 302 Francois Audet and Mary Barnes in drafting this contribution. 304 5 Author's Addresses 306 John Elwell 307 Siemens Communications 308 Technology Drive 309 Beeston 310 Nottingham, UK, NG9 1LA 311 email: john.elwell@siemens.com 313 6 Normative References 315 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the 316 Session Initiation Protocol (SIP)", RFC 3326. 318 [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 319 protocol", RFC 3261. 321 [3] M. Barnes "An Extension to the Session Initiation Protocol for 322 Request History Information", draft-ietf-sipping-history-info-02 323 (work in progress) 325 Intellectual Property Statement 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the IETF's procedures with respect to rights in IETF Documents can 334 be found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at ietf- 347 ipr@ietf.org. 349 Disclaimer of Validity 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 354 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 355 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 356 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 Copyright Statement 361 Copyright (C) The Internet Society (2004). This document is subject 362 to the rights, licenses and restrictions contained in BCP 78, and 363 except as set forth therein, the authors retain all their rights. 365 Acknowledgement 367 Funding for the RFC Editor function is currently provided by the 368 Internet Society.