| TOC |
|
When requesting and reporting dialog status in SIP, users often want to know the status of a particular telephone instrument, rather than the status of an Address of Record (AOR). 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 two methods for identifying which telephone instrument is making each registration request that is convenient to deploy in PBXs. This information can be used to obtain the status of individual telephone instruments.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 3, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Goals
2.
Difficulties to Be Overcome
3.
First Method
4.
Using Instrument Identifiction
5.
Example
6.
Interoperability
7.
Critique
8.
Second Method
8.1.
Considerations
8.2.
Proposal
8.3.
MAC assignment for soft phones
8.4.
Example
9.
Security Considerations
10.
Acknowledgments
11.
Revision History
11.1.
Changes from draft-worley-sipcore-instrument-identification-00 to draft-worley-sipcore-instrument-identification-01
11.2.
draft-worley-sipcore-instrument-identification-00
12.
References
12.1.
Normative References
12.2.
Informative References
§
Author's Address
| TOC |
When requesting and reporting dialog status in SIP[sip] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)[dialog] (Rosenberg, J., Schulzrinne, H., and R. Mahy, “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP),” November 2005.), 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 two methods by which a SIP registrar can identify which telephone instrument is making each registration request, methods which are 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.
| TOC |
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:
- IP address:
- 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.
- MAC address:
- 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.
- 'instance' parameter value in the Contact:
- 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] (Worley, D., “Guidelines for Implementing the GRUU Support in User Agents,” February 2007.):
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.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.
- URI parameters:
- 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.
- user-part URI parameters:
- 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.
- SIP extensions:
- 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.
| TOC |
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 '/'.)
| TOC |
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.
| TOC |
A typical usage pattern is as follows:
PBX PBX Config. file UA 69/70 UA 71
Provisioning Proxy/Registrar for 0000DEADBEEF
| | | | |
| F1 PUT /0000DEADBEEF | |
| line1.aor=sip:69@example.net | |
| line1.authuser=69/0000DEADBEEF | |
| line1.authpassword=XYZZY | |
| line1.authrealm=example.net | |
| line2.aor=sip:70@example.net | |
| line2.authuser=70/0000DEADBEEF | |
| line2.authpassword=plugh | |
| line2.authrealm=example.net | |
|------------------------------>| | |
| | | | |
| | | 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[sipXecs] (, “http://sipxecs.sipfoundry.org,” .). 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.
| TOC |
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[sipXecs] (, “http://sipxecs.sipfoundry.org,” .) and tested at SIPit 25[sipit] (, “https://www.sipit.net/SIPit25_Summary,” .) using five makes of SIP phone. It was seen to work with all five makes.
| TOC |
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.
| TOC |
| TOC |
The philosophically ideal way to identify instruments is via the SIP "instance id". The instance id is used to support the "SIP outbound" mechanism[outbound] (Jennings, C., Mahy, R., and F. Audet, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” October 2009.), the GRUU mechanism[gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2009.), and the SIP Forum's UA configuration system[ua‑config] (Lawrence, S., “User Agent Configuration Recommendation,” December 2009.).
There are two distinct ways to use the SIP instance id to support instrument identification:
A number of problems need to be overcome before the instance id can be used to provide instrument identification:
| TOC |
To use SIP instance id's in a practical way, let us fix:
This method shortens the instrument identifiers to 12 hexadecimal characters, which is convenient for human manipulation. It leverages the fact that hardware SIP telephone almost always bear labels stating the MAC address, and if they implement SIP instance id's, generate instance id's in this manner. The method also allows generating multiple SIP instance id's based on one MAC value for various purposes described in Section 2 (Difficulties to Be Overcome).
In practice, this method may require the administrator of a PBX to manually enter into the provisioning system the MAC value of a telephone to be deployed. Alternatively, the PBX may use an automatic discovery and provisioning system to determine the MAC address of the telephone.
Utilizing this method for soft phones is less straightforward. Generally, one can assign an "EUI-48" [EUI] (Wikipedia, “MAC address,” .) value to the soft phone which it can use to generate its SIP instance ids. The EUI-48 value is drawn from the same number space as MAC-48 addresses, so it behaves in the same way, but the values are not conveniently supplied by the hardware manufacturer.
| TOC |
Several EUI allocation methods can be used:
| TOC |
A typical usage pattern for the second method is as follows:
PBX Config. file UA 69/70 UA 71
Proxy/Registrar for 0000DEADBEEF
| | | |
| F1 REGISTER sip:example.net |
| To: sip:69@example.net |
| Contact: <sip:69@10.3.14.159>
| ;+sip.instance=
| "<urn:uuid:f81d4fae-7dec-11d0-a765-0000deadbeef>"
| Proxy-Authorization: Digest |
| username="69", ... |
| ... |
|<------------------------------| |
| | | |
| F2 200 OK | | |
|------------------------------>| |
| | | |
| F3 REGISTER sip:example.net |
| To: sip:70@example.net |
| Contact: <sip:70@10.3.14.159>
| ;+sip.instance=
| "<urn:uuid:f81d4faf-7dec-11d0-a765-0000deadbeef>"
| Proxy-Authorization: Digest |
| username="70", ... |
| ... |
|<------------------------------| |
| | | |
| F4 200 OK | | |
|------------------------------>| |
| | | |
| F5 SUBSCRIBE sip:~~in~0000DEADBEEF@example.net
|<-------------------------------------------|
| | | |
| F6 SUBSCRIBE sip:69@10.3.14.159 |
|------------------------------>| |
| | | |
| F7 200 OK | | |
|<------------------------------| |
| | | |
| F8 SUBSCRIBE sip:70@10.3.14.159 |
|------------------------------>| |
| | | |
| F9 200 OK | | |
|<------------------------------| |
| | | |
| F10 200 OK | | |
|------------------------------------------->|
| | | |
| | F11 NOTIFY sip:71@10.9.7.8
| | From: sip:69@10.3.14.159
| | |----------->|
| | | |
| | | F12 200 OK
| | |<-----------|
| | | |
| | F13 NOTIFY sip:71@10.9.7.8
| | From: sip:70@10.3.14.159
| | |----------->|
| | | |
| | | F14 200 OK
| | |<-----------|
| | | |
F1 REGISTER Instrument -> PBX Proxy/Registrar
The instrument sends a REGISTER request for AOR sip:69@example.net to the proxy/registrar. The +sip.instance field parameter carries the SIP instance id, which is a URN based on a UUID based on the instrument's MAC address, "0000DEADBEEF". Note that the string value which is the URN is enclosed in <...> because the +sip.instance field parameter is a user agent capability predicate.[capabilities] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.)
F3 REGISTER Instrument -> PBX Proxy/Registrar
Similarly, the instrument sends a REGISTER request for AOR sip:70@example.net to the proxy/registrar. The +sip.instance field parameter carries the SIP instance id, which is also a URN based on a UUID based on the instrument's MAC address, "0000DEADBEEF", but carries a different timestamp value (the last hex digit of the first group is "f"). Note that the string value which is the URN is enclosed in <...> because the +sip.instance field parameter is a user agent capability predicate.[capabilities] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.)
F5 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[sipXecs] (, “http://sipxecs.sipfoundry.org,” .). This particularly ugly string is chosen to minimize the likelihood of colliding with user-chosen user-parts.
F6 SUBSCRIBE sip:69@10.3.14.159
F8 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.
F11 NOTIFY sip:10.9.8.7 / From: sip:69@10.3.14.159
F13 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.
| TOC |
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.[digest] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) 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.
| TOC |
Thanks to Scott Lawrence for critiquing the method presented here and suggesting the development of an improved method, leading to the discussion started in Section 7 (Critique).
| TOC |
| TOC |
Reorganized sections.
Added the "Second Method" section, describing use of MAC addresses as instrument identifiers. Updated the Abstract accordingly.
| TOC |
Initial version.
| TOC |
| TOC |
| [capabilities] | Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” RFC 3840, August 2004 (TXT). |
| [sip] | 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 (TXT). |
| [uuid] | Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” RFC 4122, July 2005 (TXT). |
| [802] | IEEE Computer Society, “802 IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture,” IEEE Std 802-2001, February 2002. |
| TOC |
| TOC |
| Dale R. Worley | |
| Avaya | |
| 600 Technology Park Dr. | |
| Billerica, MA 01821 | |
| US | |
| Phone: | +1 978 288 5505 |
| Email: | dworley@avaya.com |
| URI: | http://www.avaya.com |