Identifying Individual Telephone Instruments in SIP

When requesting and reporting dialog status in SIP, users often want to know the status of a particular telephone instrument (which may have several "line appearances" of various Addresses of Record (AORs)), rather than the status of an Address of Record (AOR) (which may appear on several telephone instruments). ("Telephone instrument", or briefly, "instrument" is the term used for individual telephone devices in the telecom world. We adopt it here to avoid the multiple meanings of the words "telephone" and "phone".) The architecture of SIP makes it difficult to obtain the status of a telephone instrument in a way that is convenient for use in common situations, in particular, in an organization's PBX. This document describes a method by which a SIP registrar can identify which telephone instrument is making each registration request, a method that is convenient to deploy in PBXs. This information can be used by a proxy to route requests to specified instruments. This allows suitable SUBSCRIBE requests to be redirected to particular instruments, allowing the status of an instrument (as opposed to an AOR) to be obtained. The fundamental difficulty is identifying the instrument which is the source of each REGISTER request. There are a number of straightforward methods of identifying the registering instrument, all of which have significant drawbacks: The IP address from which the request originated (as given by the Contact header, the Via header, or the packet's origin address) cannot be relied upon to be the true address of the instrument due to NAT or application-level gateway processing. In addition, the IP address of an instrument can change due to network address reassignment or relocation of the instrument on the network. The MAC address of the instrument's network interface will not change over time, but it is impossible to obtain if the instrument is not on the same network segment as the registrar. The 'instance' parameter value in the Contact is easily obtainable and does not change with network modifications. However, not all instruments provide an 'instance' parameter. Also, an instrument may change its instance value when its software is updated, so as to invalidate information about the instrument that is cached by other elements, as exemplified by this guideline in [gruu-implement]: As other SIP agents may use the instance ID and/or GRUU as a key to cache information about the UA and its capabilities, it is recommended that when a new version of software is installed into the UA, the UA should obtain a new instance ID. We have also observed that some instruments use different instance parameter values for different line appearances. In addition, instance parameter values are usually UUID-based URNs, which are tedious for system administrators to enter into a provisioning system. URI parameters could be applied to the AORs of the line appearances on the instrument. But URI parameters are not configurable on some popular instruments. An alternative to URI parameters is the nonstandardized concept of "user-part parameters", that is suffixing ";name=value" on the user-part of the AOR. (User-part parameters are not described in [sip], but since ';' and '=' are syntactically allowed in user-parts, they are a semantic extension to [sip].) Since instruments allow the user-part of the AOR to be configured, user-part parameters can always be added. Unfortunately, some intermediate network elements modify or delete user-part parameters. In addition, most instruments display the entire SIP user-part to the user. It would be simple enough to have instruments provide a suitable identifier in an extension header, but it would be difficult to persuade vendors to implement the extension. The method described in this document depends on the fact that in a practical PBX, the PBX's provisioning system generates configuration files which are read by the instruments to set up their SIP configuration. The PBX provisioning system inserts into the configuration file of each instrument an identifier of the instrument, which the instrument then returns in its REGISTER requests. This allows the registrar to correlate the instrument with the configuration file that it loaded, and hence with the identity of the instrument as understood by the PBX provisioning system. In practice, each instrument uses its MAC address to obtain a unique configuration file using a network data transfer protocol (e.g., HTTP, HTTPS, FTP, or TFTP) requesting a file name that is derived from the instrument's MAC address. This makes it convenient to choose a string representation of an instrument's MAC address as the unique identifier of that instrument. For syntactic convenience, we omit the colons from the string representation, and require each identifier to have a consistent case. It is challenging to determine a way to embed the instrument identifier in a instrument's configuration in a way that will guarantee that it is returned in each REGISTER request without the instrument's specific cooperation. It appears that in practice, the sole datum that is handled opaquely from the instrument's configuration file, through the instrument and the network, to the registrar, is the "authentication user", the value of the username field of the Authorization or Proxy-Authorization header. Hence, we insert the instrument identification by configuring the authentication user as "real-user/instrument-identifier". (Because the instrument identifier does not contain '/', parsing is unique even if the real authentication user contains '/'.)

Once we have arranged for each REGISTER to carry identification of the instrument that sent it, the registrar can record the identification in the database record of the registration. This allows us to define a special set of URIs which designate the collection of all contacts registered by a given instrument. In principle, this is similar to the redirection of AORs, which are mapped into the set of all contacts for a particular AOR, but instead selecting records from the registration database based on the instrument identification datum rather than the user datum.. A further elaboration is to define another special set of URIs which designate the collection of all contacts for a given AOR that are also registered by a given instrument. This will usually select only one registration, for a single line appearance.

A typical usage pattern is as follows:

| | | | | | | | | | | F2 GET /0000DEADBEEF | | | |<-------------| | | | | | | | | | F3 200 OK | | | | | ... | | | | |--------------| | | | | | | | | F4 REGISTER sip:example.net | | | To: sip:69@example.net | | | Contact: sip:69@10.3.14.159 | | | Proxy-Authorization: Digest | | | username="69/0000DEADBEEF", ... | | | ... | | |<------------------------------| | | | | | | | | F5 200 OK | | | | |------------------------------>| | | | | | | | | F6 REGISTER sip:example.net | | | To: sip:70@example.net | | | Contact: sip:70@10.3.14.159 | | | Proxy-Authorization: Digest | | | username="70/0000DEADBEEF", ... | | | ... | | |<------------------------------| | | | | | | | | F7 200 OK | | | | |------------------------------>| | | | | | | | | F8 SUBSCRIBE sip:~~in~0000DEADBEEF@example.net | |<-------------------------------------------| | | | | | | | F9 SUBSCRIBE sip:69@10.3.14.159 | | |------------------------------>| | | | | | | | | F10 200 OK | | | | |<------------------------------| | | | | | | | | F11 SUBSCRIBE sip:70@10.3.14.159 | | |------------------------------>| | | | | | | | | F12 200 OK | | | | |<------------------------------| | | | | | | | | F13 200 OK | | | | |------------------------------------------->| | | | | | | | | F14 NOTIFY sip:71@10.9.7.8 | | | From: sip:69@10.3.14.159 | | | |----------->| | | | | | | | | | F15 200 OK | | | |<-----------| | | | | | | | | F16 NOTIFY sip:71@10.9.7.8 | | | From: sip:70@10.3.14.159 | | | |----------->| | | | | | | | | | F17 200 OK | | | |<-----------| | | | | | ]]> F1 PUT PBX Provisioning -> Configuration file for MAC 0000DEADBEEF By some means, the PBX provisioning system writes the configuration file for the instrument with MAC address 0000DEADBEEF. The configuration information specifies the first line appearance is for sip:69@example.net, with the the "authentication user" name of "69/000DEADBEEF", which is the "real" authentication user name, followed by its instrument identifier, which is its MAC address (without separators, in upper case). Similar configuration information is given for the second line appearance, sip:70@example.net. F2 GET Instrument 0000DEADBEEF requests its configuration file using its preferred method. F3 200 OK Instrument 0000DEADBEEF receives its configuration file. F4 REGISTER Instrument -> PBX Proxy/Registrar The instrument sends a REGISTER request for AOR sip:69@example.net to the proxy/registrar. After a 407 authentication challenge, the re-sent REGISTER request contains a Proxy-Authorization header whose username value is as specified in the instrument's configuration file, "69/0000DEADBEEF". The first portion, "69", is used by the proxy/registrar to look up the associated password. The second portion, "0000DEADBEEF", is stored in the registration record to identify the instrument whose contact address has been registered. F6 REGISTER Instrument -> PBX Proxy/Registrar Similarly, the instrument sends a REGISTER request for AOR sip:70@example.net to the proxy/registrar. F8 SUBSCRIBE sip:~~in~0000DEADBEEF@example.net User agent 71 sends a SUBSCRIBE request to sip:~~in~0000DEADBEEF@example.net to obtain dialog information for instrument 0000DEADBEEF. The user-part prefix shown here, "~~in~", is the one used in the sipXecs open-source PBX system. This particularly ugly string is chosen to minimize the likelihood of colliding with user-chosen user-parts. F9 SUBSCRIBE sip:69@10.3.14.159 F11 SUBSCRIBE sip:70@10.3.14.159 The SUBSCRIBE request is forked to the two contacts for sip:~~in~0000DEADBEEF@example.net, which are the two line appearances on the instrument 0000DEADBEEF. F14 NOTIFY sip:10.9.8.7 / From: sip:69@10.3.14.159 F16 NOTIFY sip:10.9.8.7 / From: sip:70@10.3.14.159 Each SUBSCRIBE request received at instrument 0000DEADBEEF generates a subscription. The NOTIFYs from these subscriptions tell user agent 71 the complete status of instrument 0000DEADBEEF.

This method makes very limited demands on components of a SIP system other than the PBX's provisioning system and proxy/registrar because the authentication user name is passed transparently by elements between the instrument and the proxy/registrar. This method does require that the configuration file for an instrument can set the authentication user for a line appearance independently of the user name of the AOR to be registered. This has been found to be possible on all models of SIP phone that have been tested to date. Industry intelligence is that some popular SIP provisioning systems require that this be possible, which suggests that all commercially successful SIP phones will have this capability. This method was implemented in the sipXecs open-source PBX system and tested at SIPit 25 using five makes of SIP phone. It was seen to work with all five makes.

As well as this method works, it is a hack that violates separation of concerns because instrument identification information is carried in a field which is intended for authentication information. This requires all elements that need to authenticate the source of a request to understand the syntax of the authentication user name. This burden is smaller for centralized systems, but in decentralized systems, there may be a large number of elements that need to authenticate requests, requiring a broad distribution of information that in principle should be encapsulated in the "user name and password" database. The philosophically ideal way to identify instruments is via the SIP "instance id". The instance id is used to support the "SIP outbound" mechanism, the GRUU mechanism, and the SIP Forum's UA configuration system. There are two distinct ways to use the SIP instance id to support instrument identification: The instance id is carried in the "+sip.instance" field parameter of each Contact in each REGISTER request. The proxy/registrar can extract the instance id and use it to label each registration database record. Once the registrations are labelled with instrument identifications, requests can be directed to special URIs that route to the registered contacts of a specific instrument. Each instrument can register a single special contact which is intended to identify the instrument as a whole rather than any line appearance on the instrument. This contact can be recognized by containing the instance id as either a component of the contact URI or as a "+sip.instance" field parameter. With this method, the functions described in this document are be implemented by sending SIP requests to this special contact. E.g., the overall dialog status of the instrument would be obtained by a dialog subscription to the special contact. A number of problems need to be overcome before the instance id can be used to provide instrument identification: While the authentication user name is a baseline part of SIP and is always configurable by a PBX's provisioning system, the SIP instance id is not part of baseline SIP, and user agents need to be upgraded to support the SIP instance id. In practice, only some makes of instrument support SIP instance ids. Ideally, all line appearances on an instrument would use the same instance id. Whether this is required by the RFCs is not entirely clear (probably because there has never been any reason to debate doing so). In practice, some instruments do use different instance ids for each line appearance that they register. However, since the preferred format of instance ids is a URN derived from a UUID, which is in turn based on the MAC address of the instrument, it is straightforward to extract the instrument's MAC address from each instance id, and the extracted MAC addresses of the various line appearances will be the same. The PBX's provisioning system needs to be able to map instance ids into its internal instrument identities, which likely requires having the user enter the instrument identifiers into the provisioning system. It would be inconvenient to use full instance id URNs for this reason: UUID-based URNs are quite long and tedious to type. However, using the base MAC addresses of the URNs as the instrument identifiers would be convenient, as they are short enough to be convenient to enter and most SIP phones are clearly labeled with their MAC address The reverse problem can happen with software-based instruments: The provisioning system needs to output an instrument identifier which can be input into the instrument, as the network interface of the hardware platform is not "owned" by the instrument, and the instrument may not be the only one on the platform. In the method of this document, doing so is relatively simple, since the instrument's interface allows the authentication user name to be entered directly by the user. To utilize the instance id, the instrument needs to allow its instance id to be configured, or else it needs to output its instance id so that it can be entered into the provisioning system.

There is one known security consideration for this method: In ordinary usage of digest authentication, the registrar (and any other element that needs to verify an Authorization or Proxy-Authorization header) does not need to know the password associated with an authentication user, but only needs to know the digest authentication A1 value, which is a hash of the authentication user, the authentication password, and the authentication realm. With this method, the registrar must know the authentication password, as the A1 value will depend on the authentication user in the request, which varies depending on the instrument sending the request. This increased exposure of the authentication password does not increase the vulnerability of a single SIP system, since disclosure of A1 also allows an attacker to impersonate the authentication user on that system. But exposure of the authentication password (as opposed to the A1 value) also compromises the authentication user on any other SIP system which the attacker can identify as using the same authentication password for that authentication user. In practice, this does not seem to be a problem as the authentication passwords are usually generated pseudorandomly by the PBX provisioning system and communicated to the instruments through their configuration files. As a result, authentication users on different systems will have different authentication passwords, so the compromise of the authentication user's password on one system will not compromise the authentication user on other systems.

Thanks to Scott Lawrence for critiquing the method presented here and suggesting the development of an improved method, leading to the discussion started in .

Initial version.