SIP Working Group C. Holmberg Internet-Draft Ericsson Intended status: Informational J. van Elburg Expires: July 19, 2008 Ericsson Telecommunicatie B.V. January 16, 2008 Target URI delivery in the Session Initiation Protocol (SIP) draft-holmberg-sip-target-uri-delivery-01.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 19, 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]. Holmberg & van Elburg Expires July 19, 2008 [Page 1] Internet-Draft Request-URI delivery January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Reroute, Translate, Retarget . . . . . . . . . . . . . . . 3 3.2. Current target . . . . . . . . . . . . . . . . . . . . . . 3 4. Issues with the mechanism proposed in draft-rosenberg-sip-ua-loose-route-01 . . . . . . . . . . . . 3 5. Overview of operation . . . . . . . . . . . . . . . . . . . . 5 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Alternative: Target header . . . . . . . . . . . . . . . . 5 5.3. Advantages of alternative mechanism . . . . . . . . . . . 5 5.4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 5.4.2. Unknown Aliases . . . . . . . . . . . . . . . . . . . 6 5.4.3. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . 6 5.4.4. Limited Use Addresses . . . . . . . . . . . . . . . . 6 5.4.5. Sub-Addressing . . . . . . . . . . . . . . . . . . . . 6 5.4.6. Service Invocation . . . . . . . . . . . . . . . . . . 6 5.4.7. Emergency Services . . . . . . . . . . . . . . . . . . 6 5.4.8. Freephone Numbers . . . . . . . . . . . . . . . . . . 7 5.4.9. Conclusion . . . . . . . . . . . . . . . . . . . . . . 7 5.5. Comparing to the usage of P-Called-Party-ID header . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Holmberg & van Elburg Expires July 19, 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 that it does 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. Definitions 3.1. Reroute, Translate, Retarget The terms reroute, translate/translation and retarget are understood as defined in draft-rosenberg-sip-ua-loose-route-01 [8]. 3.2. Current target The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. 4. Issues with the mechanism proposed in draft-rosenberg-sip-ua-loose-route-01 Some issues have been identified with the mechanism described in [8]. Holmberg & van Elburg Expires July 19, 2008 [Page 3] Internet-Draft Request-URI delivery January 2008 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 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. 2. It will remove the Route entry. 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. 4. We have a loop back to the first proxy that the target normally resolves to. 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. Holmberg & van Elburg Expires July 19, 2008 [Page 4] Internet-Draft Request-URI delivery January 2008 5. Overview of operation 5.1. General This chapter describes an alternative mechanism for solving the problem described in [8]. 5.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. The Target header, if present, represents the current target. In the absence of the Target header, a receiving entity must assume that the Request-URI contains the current target. Note that the Target header is not used for routing, it is just a means of presenting the current target to the receiving entity, information that otherwise would have been lost. If a SIP entity supporting this extension re-writes the Request URI value, then: 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. 5.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. Holmberg & van Elburg Expires July 19, 2008 [Page 5] Internet-Draft Request-URI delivery January 2008 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). 5.4. Use-cases 5.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. 5.4.2. Unknown Aliases The new Target header field would solve this use-case. 5.4.3. Unknown GRUU The new Target header field would 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. 5.4.4. Limited Use Addresses The new Target header field would solve this use-case. 5.4.5. Sub-Addressing The new Target header field would 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. 5.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 information. 5.4.7. Emergency Services The new Target header field would solve this use-case as it will retain the emergency URN. Holmberg & van Elburg Expires July 19, 2008 [Page 6] Internet-Draft Request-URI delivery January 2008 5.4.8. Freephone Numbers The new Target header field would solve this use-case as it will retain the Freephone Number. 5.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 in [8]. 5.5. Comparing to the usage of P-Called-Party-ID header As defined in RFC3455 [5], 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 insert a P-Called- Party-ID header field with the previous value of the Request-URI. The Target header field and P-Called-Party-ID header field have different semantics. The Target header field represents the current target identity, while the P-Called-Party-ID represents the last Request-URI value used to reach the user before the Request-URI value was re-written with the Contact address of the UAS. In some cases the P-Called-Party-ID may be the same as the current target but, it may also be the last route taken (not equal to the current target) to deliver the request. Therefore the P-Called-Party-ID can not be used in a generic SIP environment to represent the current target. 3GPP has defined procedures for the usage of P-Called-Party-ID, so 3GPP would need to continue to use the header, in addition to the new Target header. However, both mechanisms can exist in parallel. The alternative presented in this draft, to solve the use-cases in [8], does not require the usage of P-Called-Party-ID. 6. 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. 7. IANA Considerations Holmberg & van Elburg Expires July 19, 2008 [Page 7] Internet-Draft Request-URI delivery January 2008 8. Acknowledgements We thank Alf Heidermark, Ian Elz, John Elwell, Francois Audet and Paul Kyzivat for review comments on the early draft. 9. References 9.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. 9.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 19, 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 19, 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 19, 2008 [Page 10]