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]
