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 January 14, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

There are circumstances in SIP-based communications systems in which it is useful to have a long-term, stable identifier for a particular user agent. This specification outlines requirements and discusses existing standards that can be used to satisfy this need.

Table of Contents

1.  Conventions and Definitions
2.  Introduction and Use Cases
3.  Requirements
4.  Solution
5.  Example
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgments
9.  References
    9.1  Normative References
    9.2  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Conventions and Definitions

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 RFC-2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)[7].

2. Introduction and Use Cases

There are a few cases in which it is convenient to be able to identify instances of a user agent. Some examples are described. They all require the name to be stable across reboots of the device.

• In the config framework[8] (Petrie, D., “A Framework for SIP User Agent Configuration,” March 2003.), a user agent sends a subscribe to fetch its configuration. It needs to get the same configuration each time.
• A particular user, Alice, has several user agents that all register as Alice. A registrar wishes to report which user agents are currently registered to a network management system. For this reporting to make sense, each of Alice's user agents must have a stable name.
• A system that is using the dialog package to monitor a particular user agent would like to be able to assign an alias like "My Office Phone" for display purposes to that particular user agent.
• When several presence user agents are providing presence data, it must be possible to correlate a particular set of data with the particular device that provided it.
• Allowing a registrar to understand which UA a given registration is from as done in [9] (Jennings, C., Ed. and R. Mahy, Ed., “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” July 2005.).

In all these cases, the user agent could be a "soft phone", which is a software program running on a computer with possibly more than one user. The user agent could also be a device dedicated to classic phone-like behavior referred to as a "hard phone".

3. Requirements

1. Identifiers are needed for user agents that are in dedicated pieces of hardware such as IP phones.
2. Identifiers are needed for software user agents running on multi-user computers.
3. The identifier needs to be unique.
4. The identifier needs to be stable in time such as across reboots.
5. Sometimes with IP phones, it is desirable for this same identifier to be recorded as a bar code on the outside of the box that the IP phone comes in to facilitate enrollment with out pulling the phone out of the box.

4. Solution

The requirements in this specification can be met by using the instance media feature tag that is defined in [4] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” February 2005.). This works by addressing a contact header tag that looks like +sip.instance="value", where the value is a URN that uniquely identifies the device. Today the most practical URN to use is the UUID URN (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.)[3] although other useful URNs might be defined in the future. Media feature tags are described in [2] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) and URNs are defined in [1] (Moats, R., “URN Syntax,” May 1997.).

There have been many suggestions for forming a unique identifier for the device. Generally these suggestions split into two categories: using a random number to provide a high likelihood of uniqueness, or using an administratively defined and delegated range of numbers such as ethernet MAC addresses or OIDs to allow a given device to be manufactured with a unique address. The UUID is a particularly simple way of encompassing either or both of these approaches and works for both hard phones and soft phones. A device like a soft phone, when first installed, SHOULD generate a UUID (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.)[3] and then save this in persistent storage for all future use. For a device such as a hard phone, which will only ever have a single SIP UA present, the UUID can be generated at any time because it is guaranteed that no other UUID is being generated at the same time on that physical device. This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example in Section 5 (Example)) is perfectly legal as long as the device knows no other UUIDs were generated at this time. In this case the UUID is roughly equivalent to the MAC address.

If all UAs used a common format for the instance-id, such as UUID, it would make it easier to construct facilities for logging, configuration, and management that used the UUID for correlation.

5. Example

The following are some valid Contact headers:

   Contact: <sip:line1@192.168.0.2>
     ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E128>"

   Contact: <sip:line1@192.168.0.2>
     ;+sip.instance="<urn:uuid:D5964CB6-F39D-11D9-99FC-000A95A0E128>"

Implementors often ask why the value of the sip.instance is inside angle brackets. This is a requirement of RFC 3840 (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.)[2], which defines that media feature tags in SIP. Feature tags that are strings are compared by case sensitive string comparison. To differentiate these tags from tokens (which are not case sensitive), case sensitive parameters such as the sip.instance media feature tag are placed inside angle brackets.

6. IANA Considerations

This specification has no IANA considerations.

7. Security Considerations

The unique identifier reveals further privacy related information to other people who see the SIP signaling. Currently user agents put an IP address or DNS name in the contact header, so the amount of extra information this reveals is very minimal. The MAC address may reveal the manufacturer of the user agent as do other SIP headers such as the User-Agent header field value.

8. Acknowledgments

Many thank for the useful comments and improvements from Louis Pratt, Steve Levy, Rohan Mahy, Randy Baird, and Jonathan Rosenberg.

9. References

9.1 Normative References

9.2 Informative References

Author's Address

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 © The Internet Society (2005). 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.