Instance Identifiers for SIP User Agents

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.

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, 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 . 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".

Identifiers are needed for user agents that are in dedicated pieces of hardware such as IP phones. Identifiers are needed for software user agents running on multi-user computers. The identifier needs to be unique. The identifier needs to be stable in time such as across reboots. 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.

The requirements in this specification can be met by using the instance media feature tag that is defined in . 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 although other useful URNs might be defined in the future. Media feature tags are described in and URNs are defined in . 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 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 ) 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.

The following are some valid Contact headers:

;+sip.instance="" Contact: ;+sip.instance="" ]]> Implementors often ask why the value of the sip.instance is inside angle brackets. This is a requirement of RFC 3840, 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.

This specification has no IANA 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.

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