idnits 2.17.1 draft-holmberg-sip-target-uri-delivery-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. 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 abstract seems to contain references ([8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 16, 2008) is 5944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 324, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3455 (ref. '5') (Obsoleted by RFC 7315) == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-ua-loose-route-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Informational J. van Elburg 5 Expires: July 19, 2008 Ericsson Telecommunicatie B.V. 6 January 16, 2008 8 Target URI delivery in the Session Initiation Protocol (SIP) 9 draft-holmberg-sip-target-uri-delivery-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies an alternative mechanism how to deliver the 43 current target URI to the UAS, e.g. in order to implement the use- 44 cases specified in draft-rosenberg-sip-ua-loose-route-01 [8]. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Reroute, Translate, Retarget . . . . . . . . . . . . . . . 3 52 3.2. Current target . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Issues with the mechanism proposed in 54 draft-rosenberg-sip-ua-loose-route-01 . . . . . . . . . . . . 3 55 5. Overview of operation . . . . . . . . . . . . . . . . . . . . 5 56 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.2. Alternative: Target header . . . . . . . . . . . . . . . . 5 58 5.3. Advantages of alternative mechanism . . . . . . . . . . . 5 59 5.4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.4.2. Unknown Aliases . . . . . . . . . . . . . . . . . . . 6 62 5.4.3. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . 6 63 5.4.4. Limited Use Addresses . . . . . . . . . . . . . . . . 6 64 5.4.5. Sub-Addressing . . . . . . . . . . . . . . . . . . . . 6 65 5.4.6. Service Invocation . . . . . . . . . . . . . . . . . . 6 66 5.4.7. Emergency Services . . . . . . . . . . . . . . . . . . 6 67 5.4.8. Freephone Numbers . . . . . . . . . . . . . . . . . . 7 68 5.4.9. Conclusion . . . . . . . . . . . . . . . . . . . . . . 7 69 5.5. Comparing to the usage of P-Called-Party-ID header . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Intellectual Property and Copyright Statements . . . . . . . . . . 10 79 1. Introduction 81 draft-rosenberg-sip-ua-loose-route-01 [8] describes use-cases where 82 the Request-URI is re-written by one or more entities in the 83 signaling path towards the terminating UA, potential problems if the 84 previous Request-URI is lost, and defines a new mechanism where the 85 Request-URI is not re-written for translation/rerouting cases. 86 Instead in these translation/rerouting cases the Request-URI is kept 87 unchanged, and a new route is instead inserted into a Route header. 88 In case of a retarget operation, still the Request URI is rewritten 89 as this implies that the request is targeted at another identity. 91 This draft describes issues with the mechanism proposed in [8] and 92 describes an alternative solution, which do not have the same issues. 93 The alternative is based on a new SIP header. Key of the alternative 94 solution is that it is backward compatible and that it does not 95 change the existing routing logic. 97 2. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 103 3. Definitions 105 3.1. Reroute, Translate, Retarget 107 The terms reroute, translate/translation and retarget are understood 108 as defined in draft-rosenberg-sip-ua-loose-route-01 [8]. 110 3.2. Current target 112 The current target of an initial request for a dialog or standalone 113 request is the name or address to which the request is targeted, i.e. 114 either the initial target inserted in the Request-URI by the UAC that 115 originates the request, or when a retarget occurred, the target 116 provided in that retarget operation. Reroute and translation 117 operations never change the current target. 119 4. Issues with the mechanism proposed in 120 draft-rosenberg-sip-ua-loose-route-01 122 Some issues have been identified with the mechanism described in [8]. 124 The main issue with the mechanism proposed in [8] is that it requires 125 that an entity using the solution knows whether the next physical hop 126 also supports the solution. 128 In addition, if previous entities in the signaling path have used the 129 mechanism, and an entity realizes that the next hop does not support 130 it, it must "fix" the message (putting the correct value back into 131 the R-URI etc) in order for that next hop to be able to process and 132 route the message correctly. 134 Also, services which rely on receiving entities having knowledge 135 about the "previous" R-URI will only work if entities (which have 136 nothing to do with the service as such) in the message path support 137 the mechanism, which makes the usage of such services very limited 138 and unpredictable. 140 The reason for being required to know whether the next hop supports 141 the mechanismis that the mechanism makes a backward incompatible 142 change to the core routing mechanism of SIP. 144 Some examples of scenarios where the application of the mechanism 145 proposed in [8] will make the SIP routing fail: 146 1. Intermediate proxy that does not support the mechanism: 147 1. Receives a Route header with one entry representing the 148 proxy. 149 2. It will remove the Route entry. 150 3. It will try to route based on the Request URI, using RFC 3263 151 [3] procedures. It will find the first proxy that the target 152 identity resolves to. 153 4. We have a loop back to the first proxy that the target 154 normally resolves to. 155 5. Routing failed 156 2. Home proxy that does not support the mechanism: 157 1. Receives a Route header with one entry representing the 158 proxy. 159 2. It will remove the Route entry. 160 3. It will look at the Request URI to see if it is a registered 161 AOR, it is not. 162 4. It will try to route based on the Request URI, using RFC 3263 163 [3] procedures. It will find the first proxy that the target 164 identity resolves to. 165 5. We have a loop back to the first proxy that the target 166 normally resolves to. 167 6. Routing failed 168 3. An MGC that receives the request that is routed in such manner 169 may find a URN in the Request URI, it can not interwork this so 170 the call setup fails. 172 5. Overview of operation 174 5.1. General 176 This chapter describes an alternative mechanism for solving the 177 problem described in [8]. 179 5.2. Alternative: Target header 181 The alternative is based on the usage of a new SIP header. Within 182 this document we call the header "Target", but a better name can be 183 chosen should the group decide to adopt this alternative. 185 The Target header, if present, represents the current target. In the 186 absence of the Target header, a receiving entity must assume that the 187 Request-URI contains the current target. Note that the Target header 188 is not used for routing, it is just a means of presenting the current 189 target to the receiving entity, information that otherwise would have 190 been lost. 192 If a SIP entity supporting this extension re-writes the Request URI 193 value, then: 194 o if the re-write is due to a retarget operation, then the proxy 195 MUST remove any existing Target header; or 196 o if the re-write is due to a re-route or translation operation and 197 the request does not contain a Target header field, then the proxy 198 MUST insert a Target header field with the value of the Request 199 URI before it was rewritten. 201 5.3. Advantages of alternative mechanism 203 The alternative mechanism in this document can be used towards any 204 proxy/terminating UA. There is no need for entities using the 205 mechanism to have knowledge whether the next hop supports it, and 206 there is no need for the terminating UA to inform its home proxy 207 whether it supports the mechanism or not. 209 In case one of the proxies that is traversed in the course of routing 210 does not understand the mechanism, routing will still succeed as the 211 routing mechanism of SIP itself is not changed. The worst thing that 212 can happen is that a terminating UA gets the wrong information about 213 the intended target identity by which it has been reached. 215 The mechanism in this document is fully backward compatible with MGCs 216 that are using the Request-URI value for mapping and routing towards 217 the PSTN network, according to the interworking procedures described 218 in RFC3398 [4], 3GPP TS 29.163 [7] and ITU-T Recommendation Q.1912.5. 220 The mechanism in this document is fully compatible with the 221 mechanisms described in 3GPP TS 24.229 [6], which specifies the SIP 222 signaling procedures for the IP Multimedia Subsystem (IMS). 224 5.4. Use-cases 226 5.4.1. General 228 This chapter describes how the alternative mechanism defined in this 229 draft can be used to solve the use-cases listed in [8], using the 230 proposed new Target header. It is also indicated whether the 231 P-Called-Party-ID header can be used to solve a specific use-case. 233 5.4.2. Unknown Aliases 235 The new Target header field would solve this use-case. 237 5.4.3. Unknown GRUU 239 The new Target header field would solve this use-case, for GRUU's 240 used as initial target. The new Target header might miss cases where 241 a proxy equipped with some user policy may decide to route an 242 incoming call to a specific GRUU of that same user. This is clearly 243 not a retargeting case. 245 5.4.4. Limited Use Addresses 247 The new Target header field would solve this use-case. 249 5.4.5. Sub-Addressing 251 The new Target header field would solve this use-case, for sub 252 addresses used as initial target. The new Target header might miss 253 cases where a proxy equipped with some user policy may decide to 254 route an incoming call to a specific sub address of that same user. 255 Considering this a retargeting case would be justified if this case 256 can be distinguished. 258 5.4.6. Service Invocation 260 The new Target header field would solve this use-case as it will 261 retain the original URI containing all the service invocation 262 information. 264 5.4.7. Emergency Services 266 The new Target header field would solve this use-case as it will 267 retain the emergency URN. 269 5.4.8. Freephone Numbers 271 The new Target header field would solve this use-case as it will 272 retain the Freephone Number. 274 5.4.9. Conclusion 276 Analysis of the use-cases in this section shows that the new Target 277 header field can be used to solve the use-cases in [8]. 279 5.5. Comparing to the usage of P-Called-Party-ID header 281 As defined in RFC3455 [5], if a SIP entity, which acts as registrar/ 282 home proxy for the terminating user, re-writes the Request-URI with 283 the contact address of the registered UA it may insert a P-Called- 284 Party-ID header field with the previous value of the Request-URI. 286 The Target header field and P-Called-Party-ID header field have 287 different semantics. The Target header field represents the current 288 target identity, while the P-Called-Party-ID represents the last 289 Request-URI value used to reach the user before the Request-URI value 290 was re-written with the Contact address of the UAS. In some cases 291 the P-Called-Party-ID may be the same as the current target but, it 292 may also be the last route taken (not equal to the current target) to 293 deliver the request. Therefore the P-Called-Party-ID can not be used 294 in a generic SIP environment to represent the current target. 296 3GPP has defined procedures for the usage of P-Called-Party-ID, so 297 3GPP would need to continue to use the header, in addition to the new 298 Target header. However, both mechanisms can exist in parallel. 300 The alternative presented in this draft, to solve the use-cases in 301 [8], does not require the usage of P-Called-Party-ID. 303 6. Security Considerations 305 The mechanism in this draft reveals to the UA the target address by 306 which it was contacted. Previously, this was hidden from the UA. It 307 may be possible that a UA is not permitted to know the address at 308 which it was contacted. In such cases, the home proxy SHOULD remove 309 the header which contains the address. 311 7. IANA Considerations 312 8. Acknowledgements 314 We thank Alf Heidermark, Ian Elz, John Elwell, Francois Audet and 315 Paul Kyzivat for review comments on the early draft. 317 9. References 319 9.1. Normative References 321 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 322 Levels", BCP 14, RFC 2119, March 1997. 324 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 325 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 326 Session Initiation Protocol", RFC 3261, June 2002. 328 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 329 (SIP): Locating SIP Servers", RFC 3263, June 2002. 331 [4] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated 332 Services Digital Network (ISDN) User Part (ISUP) to Session 333 Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. 335 [5] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header 336 (P-Header) Extensions to the Session Initiation Protocol (SIP) 337 for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, 338 January 2003. 340 9.2. Informative References 342 [6] 3GPP, "Internet Protocol (IP) multimedia call control protocol 343 based on Session Initiation Protocol (SIP) and Session 344 Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.21.0, 345 December 2007. 347 [7] 3GPP, "Interworking between the IP Multimedia (IM) Core Network 348 (CN) subsystem and Circuit Switched (CS) networks", 3GPP 349 TS 29.163 6.11.0, October 2007. 351 [8] Rosenberg, J., "Applying Loose Routing to Session Initiation 352 Protocol (SIP) User Agents (UA)", 353 draft-rosenberg-sip-ua-loose-route-01 (work in progress), 354 June 2007. 356 Authors' Addresses 358 Christer Holmberg 359 Ericsson 360 Hirsalantie 11 361 Jorvas 02420 362 Finland 364 Email: christer.holmberg@ericsson.com 366 Hans Erik van Elburg 367 Ericsson Telecommunicatie B.V. 368 Ericssonstraat 2 369 Rijen 5121 ML 370 The Netherlands 372 Email: HansErik.van.Elburg@ericsson.com 374 Full Copyright Statement 376 Copyright (C) The IETF Trust (2008). 378 This document is subject to the rights, licenses and restrictions 379 contained in BCP 78, and except as set forth therein, the authors 380 retain all their rights. 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 385 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 386 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Intellectual Property 392 The IETF takes no position regarding the validity or scope of any 393 Intellectual Property Rights or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; nor does it represent that it has 397 made any independent effort to identify any such rights. Information 398 on the procedures with respect to rights in RFC documents can be 399 found in BCP 78 and BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the use of 404 such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR repository at 406 http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention any 409 copyrights, patents or patent applications, or other proprietary 410 rights that may cover technology that may be required to implement 411 this standard. Please address the information to the IETF at 412 ietf-ipr@ietf.org. 414 Acknowledgment 416 Funding for the RFC Editor function is provided by the IETF 417 Administrative Support Activity (IASA).