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]