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]