Internet DRAFT - draft-holmberg-sip-target-uri-delivery
draft-holmberg-sip-target-uri-delivery
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]
