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 where it is convenient to be able to identity instances of a user agents. Some examples are described. They all require the name to be stable across reboots of the device. In the config framework, an user agents sends a subscribe to fetch it's 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 agent are currently registerd to a network management system. Having a stable name for each of Alice's user agents is need to make this reporting make sense. 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. In all these cases, the user agent could be a software program running on a computer that is used by more than one user. Correlation of which instance is providing presence data.

The identifier needs to be unique. Identifiers are needed for user agents that are in a dedicated peices of hardware such as an IP Phone. Identifiers are needed for software users agents running on multi-user computers. In some of the cases with IP phones, it is desirable for this same identifier to be recorded as a bar code on the outside of the box that an IP phone comes in.

User agents that follow the convention of this document MUST put a unique identifier in the Display Name portion of the Contact header when sending a SIP request. They MAY omit this for a particular sequence of SIP messages if the user has requested it be removed for privacy reasons. The unique identifier has no real semantic information other than a unique identifier. In the cases where the user agent runs on a single computer and this is the only user agent on that computer, then the MAC address of the primary network card is the preferred identifier. In the cases where it is not possible to use the MAC address, then when the user agent is first run, it should generate a random 64 bit number and use this as the identifier. It MUST store this number in some non volatile storage that is stable over reboots and power outages. If the identifier is a MAC address, it MUST be formatted as the the letters "MAC-" followed by a 12 digit hexadecimal representation of the mac address. The address can not include any ":", whitespace, or other formatting. If the identifier is a random number, it MUST be formatted as the letters "RANID-" followed by a 16 digit hexadecimal representation of the number. The MAC and RANDID identify the namespace for the unique identifier. In the future it may be extended with other namespaces that use unique identifiers from things like USB, Bluetooth, or Firewire. Note the identifiers are case sensitive and all alpha characters are in all upper case. These same identifiers may be used in user portion of request URIs when that is aproerate. A SUBSDCRIBE for configuraiton information is a good example.

The contact header in a SIP request identifies an address that can be used to reach the device that sending the request. This address may change each time the devices running the user agent gets a new IP address but it is very reasonable for the display name to give a unique identifier for what the user instance agent wishes to be known by. Right now SIP does not give any recommendation on what to place in the field. This document suggests a naming convention for this. MAC address are comonly put on the outside of the box for most IP Phones in a form that can be read by humans and also by a barcode scanner. The reason for all upper case in the identifier is to minimize any chance of collision with normal names that may be placed in the Display Name.

The following ABNF follows the rules in RFC-2234.

UHEX = DIGIT / %x41-46 ;uppercase A-F MAC = %x4d.41.43 ; MAC in caps RANDID = %x52.41.4e.44.49.44 ; RANDID in caps uniq-ident = ( mac-ident / rand-ident ) mac-ident = MAC "-" 12UHEX rand-ident = RANDID "-" 16UHEX

The following are some valid Contact headers:

Contact: "MAC-123456789ABC" <sip:alice@host22.example.com> Contact: "RANDID-0123456789ABCDEF" <sip:alice@host22.example.com>

This reveals further privacy related information to other people that see the SIP signalling. Currently Users 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 manafacture of the user agent.

Would this be better in a "Instance-ID" header? Would this be better in the User-Agent header? Some systems are doing already doing this. Is 64 bits the right size for the random identifier?