SIP Working Group C. Holmberg Internet-Draft Ericsson Intended status: Informational J. van Elburg Expires: July 14, 2008 Ericsson Telecommunicatie B.V. January 11, 2008 Target URI delivery in the Session Initiation Protocol (SIP) draft-holmberg-sip-target-uri-delivery-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies an alternative mechanism how to deliver the current target URI to the UAS, e.g. in order to implement the use- cases specified in draft-rosenberg-sip-ua-loose-route-01 [8]. The document also shows how the P-Called-Party-ID header can be used to solve some use-cases. Holmberg & van Elburg Expires July 14, 2008 [Page 1] Internet-Draft Request-URI delivery January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Issues with the mechanism proposed in draft-rosenberg-sip-ua-loose-route-01 . . . . . . . . . . . . 3 4. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Alternative: Target header . . . . . . . . . . . . . . . . 4 4.3. Advantages of alternative mechanism . . . . . . . . . . . 5 4.4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. Unknown Aliases . . . . . . . . . . . . . . . . . . . 6 4.4.3. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . 6 4.4.4. Limited Use Addresses . . . . . . . . . . . . . . . . 6 4.4.5. Sub-Addressing . . . . . . . . . . . . . . . . . . . . 6 4.4.6. Service Invocation . . . . . . . . . . . . . . . . . . 6 4.4.7. Emergency Services . . . . . . . . . . . . . . . . . . 7 4.4.8. Freephone Numbers . . . . . . . . . . . . . . . . . . 7 4.4.9. Conclusion . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Usage of P-Called-Party-ID . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Holmberg & van Elburg Expires July 14, 2008 [Page 2] Internet-Draft Request-URI delivery January 2008 1. Introduction draft-rosenberg-sip-ua-loose-route-01 [8] describes use-cases where the Request-URI is re-written by one or more entities in the signaling path towards the terminating UA, potential problems if the previous Request-URI is lost, and defines a new mechanism where the Request-URI is not re-written for translation/rerouting cases. Instead in these translation/rerouting cases the Request-URI is kept unchanged, and a new route is instead inserted into a Route header. In case of a retarget operation, still the Request URI is rewritten as this implies that the request is targeted at another identity. This draft describes issues with the mechanism proposed in [8] and describes an alternative solution, which do not have the same issues. The alternative is based on a new SIP header. Key of the alternative solution is that it is backward compatible and do not change the existing routing logic. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. 3. Issues with the mechanism proposed in draft-rosenberg-sip-ua-loose-route-01 Some issues have been identified with the mechanism described in [8]. The main issue with the mechanism proposed in [8] is that it requires that an entity using the solution knows whether the next physical hop also supports the solution. In addition, if previous entities in the signaling path have used the mechanism, and an entity realizes that the next hop does not support it, it must "fix" the message (putting the correct value back into the R-URI etc) in order for that next hop to be able to process and route the message correctly. Also, services which rely on receiving entities having knowledge about the "previous" R-URI will only work if entities (which have nothing to do with the service as such) in the message path support the mechanism, which makes the usage of such services very limited and unpredictable. The reason for being required to know whether the next hop supports Holmberg & van Elburg Expires July 14, 2008 [Page 3] Internet-Draft Request-URI delivery January 2008 the mechanismis that the mechanism makes a backward incompatible change to the core routing mechanism of SIP. Some examples of scenarios where the application of the mechanism proposed in [8] will make the SIP routing fail: 1. Intermediate proxy that does not support the mechanism: 1. Receives a Route header with one entry representing the proxy.d 2. It will remove the Route entry.d 3. It will try to route based on the Request URI, using RFC 3263 [3] procedures. It will find the first proxy that the target identity resolves to.d 4. We have a loop back to the first proxy that the target normally resolves to.d 5. Routing failed 2. Home proxy that does not support the mechanism: 1. Receives a Route header with one entry representing the proxy. 2. It will remove the Route entry. 3. It will look at the Request URI to see if it is a registered AOR, it is not. 4. It will try to route based on the Request URI, using RFC 3263 [3] procedures. It will find the first proxy that the target identity resolves to. 5. We have a loop back to the first proxy that the target normally resolves to. 6. Routing failed 3. An MGC that receives the request that is routed in such manner may find a URN in the Request URI, it can not interwork this so the call setup fails. 4. Overview of operation 4.1. General This chapter describes an alternative mechanism for solving the problem described in [8]. 4.2. Alternative: Target header The alternative is based on the usage of a new SIP header. Within this document we call the header "Target", but a better name can be chosen should the group decide to adopt this alternative. If a SIP entity supporting this extension re-writes the Request URI value, then: Holmberg & van Elburg Expires July 14, 2008 [Page 4] Internet-Draft Request-URI delivery January 2008 o if the re-write is due to a retarget operation, then the proxy MUST remove any existing Target header; or o if the re-write is due to a re-route or translation operation and the request does not contain a Target header field, then the proxy MUST insert a Target header field with the value of the Request URI before it was rewritten. If a SIP entity, which acts as registrar/home proxy for the terminating user, re-writes the Request-URI with the contact address of the registered UA it may additionally insert a P-Called-Party-ID header field with the previous value of the Request-URI , as described in RFC3455 [5]. Note that the Target header field and P-Called-Party-ID header fields have different semantics, where the Target header field represents the initial target identity that was used to initiate a session to the target, the P-Called-Party-ID represents the last AOR used to reach the user before Request-URI value for cases where the last route taken presents significant information. 4.3. Advantages of alternative mechanism The alternative mechanism in this document can be used towards any proxy/terminating UA. There is no need for entities using the mechanism to have knowledge whether the next hop supports it, and there is no need for the terminating UA to inform its home proxy whether it supports the mechanism or not. In case one of the proxies that is traversed in the course of routing does not understand the mechanism, routing will still succeed as the routing mechanism of SIP itself is not changed. The worst thing that can happen is that a terminating UA gets the wrong information about the intended target identity by which it has been reached. The mechanism in this document is fully backward compatible with MGCs that are using the Request-URI value for mapping and routing towards the PSTN network, according to the interworking procedures described in RFC3398 [4], 3GPP TS 29.163 [7] and ITU-T Recommendation Q.1912.5. The mechanism in this document is fully compatible with the mechanisms described in 3GPP TS 24.229 [6], which specifies the SIP signaling procedures for the IP Multimedia Subsystem (IMS). 4.4. Use-cases Holmberg & van Elburg Expires July 14, 2008 [Page 5] Internet-Draft Request-URI delivery January 2008 4.4.1. General This chapter describes how the alternative mechanism defined in this draft can be used to solve the use-cases listed in [8], using the proposed new Target header. It is also indicated whether the P-Called-Party-ID header can be used to solve a specific use-case. 4.4.2. Unknown Aliases P-Called-Party-ID [5] header field was introduced just to address this scenario. The new Target header field would also solve this use-case. 4.4.3. Unknown GRUU As this is just a variant of the "Unknown Aliases" problem, P-Called- Party-ID [5] clearly addresses this. The new Target header field would also solve this use-case, for GRUU's used as initial target. The new Target header might miss cases where a proxy equipped with some user policy may decide to route an incoming call to a specific GRUU of that same user. This is clearly not a retargeting case. 4.4.4. Limited Use Addresses As this is just a variant of the "Unknow Aliases" problem, P-Called- Party-ID [5] clearly addresses this. The new Target header field would also solve this use-case. 4.4.5. Sub-Addressing As this is just a variant of the "Unknown Aliases" problem, P-Called- Party-ID [5] clearly addresses this. The new Target header field would also solve this use-case, for sub addresses used as initial target. The new Target header might miss cases where a proxy equipped with some user policy may decide to route an incoming call to a specific sub address of that same user. Considering this a retargeting case would be justified if this case can be distinguished. 4.4.6. Service Invocation The new Target header field would solve this use-case as it will retain the original URI containing all the service invocation Holmberg & van Elburg Expires July 14, 2008 [Page 6] Internet-Draft Request-URI delivery January 2008 information. 4.4.7. Emergency Services The new Target header field would solve this use-case as it will retain the emergency URN. 4.4.8. Freephone Numbers The new Target header field would solve this use-case as it will retain the Freephone Number. 4.4.9. Conclusion Analysis of the use-cases in this section shows that the new Target header field can be used to solve the use-cases. Some use-cases can also be solved using the P-Called-Party-ID header. 4.5. Usage of P-Called-Party-ID Analysis in this document shows that a new Target header field can be used to solve the use cases in [8]. It is noted that due to the difference in semantics between the P-Called-Party-ID and the Target header, at least 3GPP IMS would also need to continue to use P-Called-Party-ID. However both mechanisms can exist in parallel. It has been claimed that it would be difficult to specify a generic mechanism using an existing P- header, since it is not defined in a standards track RFC. If needed, that can be fixed in IETF, and we consider this more an "administrative exercise" than a technical problem. 5. Security Considerations The mechanism in this draft reveals to the UA the target address by which it was contacted. Previously, this was hidden from the UA. It may be possible that a UA is not permitted to know the address at which it was contacted. In such cases, the home proxy SHOULD remove the header which contains the address. 6. IANA Considerations 7. Acknowledgements We thank Alf Heidermark and Ian Elz for review comments on the early Holmberg & van Elburg Expires July 14, 2008 [Page 7] Internet-Draft Request-URI delivery January 2008 draft. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [5] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. 8.2. Informative References [6] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.21.0, December 2007. [7] 3GPP, "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks", 3GPP TS 29.163 6.11.0, October 2007. [8] Rosenberg, J., "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", draft-rosenberg-sip-ua-loose-route-01 (work in progress), June 2007. Holmberg & van Elburg Expires July 14, 2008 [Page 8] Internet-Draft Request-URI delivery January 2008 Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Hans Erik van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ML The Netherlands Email: HansErik.van.Elburg@ericsson.com Holmberg & van Elburg Expires July 14, 2008 [Page 9] Internet-Draft Request-URI delivery January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Holmberg & van Elburg Expires July 14, 2008 [Page 10]