The User Registered UA URL draft-xu- sipping - uruu -0 1.txt

1. The User Registered UA URLdraft-xu-sipping-uruu-01.txt Peili Xu xupeili@huawei.com

2. Introduction • People may have multiple UAs • Cell phone, Soft-Phone, Office phone and Home phone... • To group them with one AOR is fine to use • Forking, in parallel or by sequence… • But, can we achieve more ? • To manage those phones more delicately • To let people call exactly the related phone(s) he want • Maybe more…

3. Definition • 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 logically have two parts: the AOR and the sub-name of the UA(s) under that AOR.The sub-name part is normally human-readable.

4. Relationship with GRUU • GRUU is to identify the specified UA instance while URUU is to give personalized sub-name of one or more UA. • GRUU is a kind of basic mechanism while URUU is more service and user oriented. • URUU do not have GRUU property, i.e. it can not guarantee the routing to specific UA instance. • The UA which have sub-name may also have GRUU. • The may co-exist and serve different requirements.

5. Use Case • One user with multiple UAs • Bob have several phones under "bob@com“. • He may want to name them as "home", "office", "cell" etc. • If people call "bob@com" with sub-name "office", the call will route to his office. • Interworking with ISDN • ISDN has "sub-address" feature for phones connected to different ports of one ISDN line.

6. Requirements • Req 1: When one user has multiple SIP UAs which share the same AOR, he can provide a name for each such UA to further classify and manipulate the communication services for them. • Req 2: 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 3: One AOR may have multiple extension names under it, and each extension name may have one or more UAs associated. • Req 4: The other user can make call to the associated UA(s) by specify the destination AOR and extension name together. • Req 5: 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.

7. Discussion • Naming vs. Feature • What is the basic characteristic of URUU? • Features are characteristics of UAs which are normally defined in a standardized way and have mutual understanding on both sides. • While sub-name extension serves as a kind of logical identity which may have several UAs associated. • According to the requirement, I prefer it to be naming oriented.

8. Creation of URUU • The User • Select good names, pre-config the UA and publish them to people. • The UA • Send REGISTER with the sub-name. • The Registrar • Enforce policy on URUU if needed. • Store the URUU (AOR and sub name) for further use.

9. Use of URUU • The Caller • Make call with the sub-name if he want to reach the callee`s URUU. • The Serving Proxy • Look up for the contact(s) with the URUU. • Forward the request by enforce policy on the query result. • Be sure to carry the sub-name in the forwarded request to let the callee know which name is actually destined. • The Callee • Process the request and may enforce some URUU related policy

10. Comments • We want more opinion about this topic. • Please consider the solution. Thanks!

11. Backlog Discussion • Sub-name vs. AOR grouping • There are similar services that several AORs grouped by one AOR. • AOR is controlled by provider while Sub-name is controlled by the user. • They are different service requirements, and should not have conflict between them.

12. Backlog Discussion • Whether URUU can have service treatment property? • Maybe applicable if the service is provided by UA • Whether one UA instance can have multiple sub-name? • Seems reasonable to have for the user