Internet DRAFT - draft-xu-sipping-uruu

draft-xu-sipping-uruu






Network Working Group                                          Peili. Xu
Internet-Draft                                       Huawei Technologies
Expires: September 24, 2006                               March 23, 2006


                  The User-registered Routable UA URL
                        draft-xu-sipping-uruu-01

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 September 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document analyses those kind of services which allow user to
   allocate his personalized extension name which can be used as
   indications to route to its currently associated UA(s).









Xu                     Expires September 24, 2006               [Page 1]

Internet-Draft     The User-registered Routable UA URL        March 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use case . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  multiple personal UAs  . . . . . . . . . . . . . . . . . .  5
     3.2.  Interworking with ISDN . . . . . . . . . . . . . . . . . .  5
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  6
   5.  Summary of the requirements  . . . . . . . . . . . . . . . . .  7
   6.  Creation of a URUU . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Using the URUU . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Example Call Flow  . . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16
































Xu                     Expires September 24, 2006               [Page 2]

Internet-Draft     The User-registered Routable UA URL        March 2006


1.  Introduction

   In typical SIP network, one user can have one or more public address
   which are normaly applied from the service provider.  The user must
   associate the AOR with the contact address of its User Agent through
   the registration procedure defined in RFC 3261 [2], so that it can be
   contacted by other users.

   It is allowed that one AOR mapped to multiple UA instances with
   different contact address.  The user can provide different priority
   of each UA instance associated with one AOR by filling different
   values in the "q=" parameter in the Contact header during the
   registration procedure.  In this case, the proxy may forward the
   incoming request to multiple associated UA instances in parallel, by
   sequence or according to other policies.

   When the user has multiple UAs under his AOR (public address), like
   cell phone, PDA, desktop phone, soft-phone in his computer, there are
   strong requirements to provide easily managable and personalized
   services among them.  One typical requirment is that the user can
   have special human-readable extension name of those UA(s) under one
   AOR, for example, to identify its home phone, office phone, cell
   phone seperately.  He may then publish these names along with his
   AOR, so that other users can intentionaly contact the callee`s
   communication destination by simply making the call to the AOR
   together with the specified name of the destination.  Different from
   AOR, the value to provide such kind of service is that it could be
   fully personalized and flexible.  The users can give and change the
   meaningful extension name of the UA instances under their AOR by
   themselves to reflect their own preferences.

   This document analyses this kind of requirements and try to fine some
   general solutions for this kind of services.

   Different from GRUU [5] which specifies the basic mechanism to
   provide global routable URI of each UA instance, the requirement for
   extension name of UAs is more service and user oriented.  Also, the
   extension name is allocated by the user himself and one extension
   name may be associated with multiple UA instances each with a GRUU.
   The requirement specified in this document allows the user to change
   his UA instance while remains its extension name unchanged.  In case
   when it is required to locate specified UA instance associated with
   an extension name, the procedure of GRUU should be followed.








Xu                     Expires September 24, 2006               [Page 3]

Internet-Draft     The User-registered Routable UA URL        March 2006


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

   This specification defines the following additional terms:

   URUU: It is a sort of address property which can be used to name one
   or more UA instances under one AOR to provide personalized naming and
   manipulation of communication services for them.  It have two logical
   parts: the AOR and the extension name of the UA(s) under the AOR.
   The extension name part is normaly human-readable.

   The terminologies defined in RFC3261 are directly used here.



































Xu                     Expires September 24, 2006               [Page 4]

Internet-Draft     The User-registered Routable UA URL        March 2006


3.  Use case

3.1.  multiple personal UAs

   Suppose "Bob" have multiple phones, each of which share the AOR
   "bob@provider.com".  He may want to give each of those phones a name
   to further classify and manipulte the communication to them, say
   "mobile" for his mobile phone, "home" for his home ip phone, and
   "office" for his office phone.  He may want to tell the network that
   calls for "home" under "bob@provider.com" would route to his home
   phone and for "office" route to his office phone.  Then, he'd be able
   to tell other people that if they want to make call to his office,
   they should make calls to sip: bob@provider.com, with the extension
   "office".  Moreover, if "Bob" changes his office, he may still name
   his new phone as "office", so that the call will be routed to his new
   office automatically.

3.2.  Interworking with ISDN

   In traditional ISDN network, there is similar service called "ISDN
   sub-address" which provide name function for phones connected to
   different ports of one ISDN line.  To interwork with ISDN, the
   similar function may also be required in SIP network, there is
   already a draft "ISDN subaddress encoding type for tel URI" [6]
   discussing about this.


























Xu                     Expires September 24, 2006               [Page 5]

Internet-Draft     The User-registered Routable UA URL        March 2006


4.  Overview of Operation

   This section is brief in nature, and does not specify any normative
   behavior.

   When the user have multiple UAs share the same AOR, he would do the
   registration for each one.  The user could pre-config the extension
   name on the phone.  During registration, the UA should send a
   REGISTER message with its extension names filled in the Contact
   header.  Also, an indication of this feature should also provided in
   the REGISTER message.  The registra should store the AOR and
   extension name pair in the location service if it support this
   feature.

   Since the extension name is the sub-address of the associated UA(s)
   under one AOR, the user may publish it to others.  When one want to
   make call to the user, he may either call the AOR or optionally with
   the extension name if he want to reach the UA(s) with the specified
   extension name.  In the later case, the caller should specify the AOR
   together with the extension name within the initial request.

   When the request with the extension name reaches the serving proxy of
   the callee, the proxy would query the location service with the AOR
   and extension name together as the key to find the exact contact of
   the associated UA instance.  After that, the proxy will forward the
   request to the destined UA(s) according to the query result.  Note
   that if the extension name is mapped to multiple contacts, the proxy
   may apply forking or some other policy.























Xu                     Expires September 24, 2006               [Page 6]

Internet-Draft     The User-registered Routable UA URL        March 2006


5.  Summary of the requirements

   The requirements for such kind of services is summarized here:

      Req 1: One user may have multiple SIP UAs which share the same
      AOR.

      Req 2: The user can provide a name for each such UA to further
      classify and manipulate the communication services for them.

      Req 3: The extension name is allocated by the user and is valid
      within the namespace of his AOR.  It is recommended to be human-
      readable.

      Req 4: One AOR may have multiple extension names under it, and one
      extension name may have one or more UAs associated.

      Req 5: The other user can make call to the associated UA(s) by
      specify the destination AOR and extension name together.

      Req 6: if the user just provide the extension name when making the
      call, it mean he is to dial the other UAs under the same AOR.  And
      the system should treat the call as if he provide the AOR and
      extension name together.

      Issue: Whether the extension name has the service treatment
      property?

      Issue: Whether to allow one UA instance to have multiple extension
      names?





















Xu                     Expires September 24, 2006               [Page 7]

Internet-Draft     The User-registered Routable UA URL        March 2006


6.  Creation of a URUU

   Several considerations are provided here, the detail will be added
   after the requirement is confirmed.

   The extension name is allocated by the user and may normally be pre-
   configed in the UA.  The extension name should be provided in the
   REGISTER during registration.  RFC 3840 [3] provides the mechanism to
   provide properties of the UA through the feature tags in Contact
   header of REGISTER. if this mechanism is used for URUU, whether to
   reuse the exiting tags like "description" or to extend another one is
   to be considered.  Another option is that we define an extension
   parameter of SIP URI, e.g. "extaddr=" to identify the extension name
   and also a new option tag is needed to indicate the support of URUU.

   The registra should extract the AOR and extension name together and
   may store it in the location service.  Before giving response, it may
   enforce some policy on the mapping of AOR, extension name and UA
   instances, for example: whether to allow one extension name to be
   associated with more than one UA instance. if the policy check fails,
   a 4xx error should be send back to the UA.






























Xu                     Expires September 24, 2006               [Page 8]

Internet-Draft     The User-registered Routable UA URL        March 2006


7.  Using the URUU

   Several considerations are provided here, the detail will be added
   after the requirement is confirmed.

   Given the extension name, caller can make the call with AOR and
   extension name specified in the initial request to guarentee that the
   call will be routed to the exact destination UA(s) with the extension
   name.

   Where to provide the URUU in the initial request depend on the
   forming of URUU.  RFC 3841 [4] provides the mechanism to provide
   caller preference through the use of extension headers with feature
   tag like "Accept-Contact" and "Reject-Contact", if the extension name
   is considered as a feature of UA, this method can be used.  Another
   option is to provide it as an extension parameter of the SIP URI.
   This may also need an indication to say that the URI is URUU.

   Since only the serving domain understand the extension name, when the
   serving proxy of the callee receives the initial request containing
   URUU, it should query the location service by combining the AOR and
   extension name as the key.  The subsequent process should be done
   according to the query result and local policy.  Before forwarding
   the request to the callee UA instance, the proxy may replace the
   Request-URI by the contact address, make sure that the extension name
   is copied to the replaced URI, so that the callee UA may know which
   extension name he is actually called.

   It should be noted that the URUU is not used to guarentee the routing
   to a specific UA instance, so it can not act as a component of remote
   contact.  Although both caller and callee can provide the extension
   name in the Contact header which will be treated as the remote-target
   by the other side.  The receiver should understand that only the AOR
   combining with extension name have the property of URUU.  In another
   word, if the callee wants to return call to the URUU of the caller,
   it should extract the extension name and combine it with the AOR of
   the callee to form a URUU.














Xu                     Expires September 24, 2006               [Page 9]

Internet-Draft     The User-registered Routable UA URL        March 2006


8.  Grammar

   The detailed grammar definition of extensions will be defined here if
   required.















































Xu                     Expires September 24, 2006              [Page 10]

Internet-Draft     The User-registered Routable UA URL        March 2006


9.  Example Call Flow

   Examples will be provided here.
















































Xu                     Expires September 24, 2006              [Page 11]

Internet-Draft     The User-registered Routable UA URL        March 2006


10.  Security Considerations

   TBD.
















































Xu                     Expires September 24, 2006              [Page 12]

Internet-Draft     The User-registered Routable UA URL        March 2006


11.  IANA Considerations

   TBD.
















































Xu                     Expires September 24, 2006              [Page 13]

Internet-Draft     The User-registered Routable UA URL        March 2006


12.  Acknowledgments

   Thanks to Jonathan Rosenberg who gave useful commens when the initial
   very brief version came out.

13.  References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", 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., Schulzrinne, H., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3840, August 2004.

   [4]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3841, August 2004.

   [5]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-07.txt , March 2006.

   [6]  Munakata, M., Schubert, S., and T. Ohba, "ISDN subaddress
        encoding type for tel URI",
        draft-munakata-iptel-isub-type-00.txt , February 2006.






















Xu                     Expires September 24, 2006              [Page 14]

Internet-Draft     The User-registered Routable UA URL        March 2006


Author's Address

   Peili Xu
   Huawei Technologies
   Bantian
   Shenzhen, Longgang  518129
   China

   Phone: +86 755 28780808
   Email: xupeili@huawei.com









































Xu                     Expires September 24, 2006              [Page 15]

Internet-Draft     The User-registered Routable UA URL        March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Xu                     Expires September 24, 2006              [Page 16]