Internet DRAFT - draft-jennings-sipping-instance-id
draft-jennings-sipping-instance-id
SIPPING WG C. Jennings
Internet-Draft Cisco Systems, Inc.
Expires: January 14, 2006 July 13, 2005
Instance Identifiers for SIP User Agents
draft-jennings-sipping-instance-id-01.txt
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 (C) 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.
Jennings Expires January 14, 2006 [Page 1]
Internet-Draft SIP UA Instance ID July 2005
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction and Use Cases . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1 Normative References . . . . . . . . . . . . . . . . . . . 5
9.2 Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Jennings Expires January 14, 2006 [Page 2]
Internet-Draft SIP UA Instance ID July 2005
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 [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.
o In the config framework[8], a user agent sends a subscribe to
fetch its configuration. It needs to get the same configuration
each time.
o 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.
o 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.
o 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.
o Allowing a registrar to understand which UA a given registration
is from as done in [9].
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.
Jennings Expires January 14, 2006 [Page 3]
Internet-Draft SIP UA Instance ID July 2005
4. Solution
The requirements in this specification can be met by using the
instance media feature tag that is defined in [4]. 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 [3] although other useful URNs might be defined in the
future. Media feature tags are described in [2] and URNs are defined
in [1].
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 [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) 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 [2], which defines
that media feature tags in SIP. Feature tags that are strings are
Jennings Expires January 14, 2006 [Page 4]
Internet-Draft SIP UA Instance ID July 2005
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
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[3] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[4] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-03 (work in progress), February 2005.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] 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.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Jennings Expires January 14, 2006 [Page 5]
Internet-Draft SIP UA Instance ID July 2005
Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
[8] Petrie, D., "A Framework for SIP User Agent Configuration",
draft-ietf-sipping-config-framework-00 (work in progress),
March 2003.
[9] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-01 (work in progress), July 2005.
Author's Address
Cullen Jennings
Cisco Systems, Inc.
170 West Tasman Dr.
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902 3341
Email: fluffy@cisco.com
Jennings Expires January 14, 2006 [Page 6]
Internet-Draft SIP UA Instance ID July 2005
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 (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.
Jennings Expires January 14, 2006 [Page 7]
