[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
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]