Internet DRAFT - draft-worley-instrument-identification

draft-worley-instrument-identification






SIPCORE                                                        D. Worley
Internet-Draft                                                    Nortel
Intended status: Experimental                           January 29, 2010
Expires: August 2, 2010


          Identifying Individual Telephone Instruments in SIP
               draft-worley-instrument-identification-01

Abstract

   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.

Status of this Memo

   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 2, 2010.

Copyright Notice




Worley                   Expires August 2, 2010                 [Page 1]

Internet-Draft        SIP Instrument Identification         January 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.


Table of Contents

   1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Difficulties to Be Overcome  . . . . . . . . . . . . . . . . .  4
   3.  First Method . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Using Instrument Identifiction . . . . . . . . . . . . . . . .  7
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Interoperability . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Second Method  . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Considerations . . . . . . . . . . . . . . . . . . . . . . 13
     8.2.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.3.  MAC assignment for soft phones . . . . . . . . . . . . . . 15
     8.4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   11. Revision History . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Changes from
           draft-worley-sipcore-instrument-identification-00 to
           draft-worley-sipcore-instrument-identification-01  . . . . 21
     11.2. draft-worley-sipcore-instrument-identification-00  . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24












Worley                   Expires August 2, 2010                 [Page 2]

Internet-Draft        SIP Instrument Identification         January 2010


1.  Goals

   When requesting and reporting dialog status in SIP[sip][dialog],
   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.






























Worley                   Expires August 2, 2010                 [Page 3]

Internet-Draft        SIP Instrument Identification         January 2010


2.  Difficulties to Be Overcome

   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]:

         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:  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



Worley                   Expires August 2, 2010                 [Page 4]

Internet-Draft        SIP Instrument Identification         January 2010


      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.











































Worley                   Expires August 2, 2010                 [Page 5]

Internet-Draft        SIP Instrument Identification         January 2010


3.  First Method

   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 '/'.)


















Worley                   Expires August 2, 2010                 [Page 6]

Internet-Draft        SIP Instrument Identification         January 2010


4.  Using Instrument Identifiction

   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.



































Worley                   Expires August 2, 2010                 [Page 7]

Internet-Draft        SIP Instrument Identification         January 2010


5.  Example

   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     |              |            |
       |              |------------------------------>|            |



Worley                   Expires August 2, 2010                 [Page 8]

Internet-Draft        SIP Instrument Identification         January 2010


       |              |                |              |            |
       |              |  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



Worley                   Expires August 2, 2010                 [Page 9]

Internet-Draft        SIP Instrument Identification         January 2010


   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].  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.







Worley                   Expires August 2, 2010                [Page 10]

Internet-Draft        SIP Instrument Identification         January 2010


6.  Interoperability

   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] and tested at SIPit 25[sipit] using five makes of SIP
   phone.  It was seen to work with all five makes.
































Worley                   Expires August 2, 2010                [Page 11]

Internet-Draft        SIP Instrument Identification         January 2010


7.  Critique

   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.







































Worley                   Expires August 2, 2010                [Page 12]

Internet-Draft        SIP Instrument Identification         January 2010


8.  Second Method

8.1.  Considerations

   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], the GRUU mechanism[gruu], and the SIP Forum's UA
   configuration system[ua-config].

   There are two distinct ways to use the SIP instance id to support
   instrument identification:

   1.  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.

   2.  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:

   1.  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.

   2.  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



Worley                   Expires August 2, 2010                [Page 13]

Internet-Draft        SIP Instrument Identification         January 2010


       MAC addresses of the various line appearances will be the same.

   3.  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

   4.  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.

8.2.  Proposal

   To use SIP instance id's in a practical way, let us fix:

   1.  a UA's SIP instance id is a URN-based on a UUID,

   2.  the UUID has the "version 1" format described in [uuid],

   3.  the UUID's "node" value is a 48-bit MAC value, and

   4.  the instrument identifier (a string) is the upper-case
       hexadecimal representation of the MAC value.  (The UUID contains
       the MAC value in lower case, but the universal practice of "MAC
       address labels" on hardware devices is to use upper-case.)

   5.  If the instrument is a separate network element (a "hardware
       telephone"), the MAC value is the MAC-48 address of (one of) its
       network interface(s) (see [802] section 9.2).

   6.  If the instrument is not a separate network element (often, a
       "soft phone" implemented largely in software on a general-purpose
       computing platform), the MAC value is an EUI-48 value.  EUI-48
       values are drawn from the same number space as MAC-48 addresses
       [EUI], and can be assigned in a number of ways described below



Worley                   Expires August 2, 2010                [Page 14]

Internet-Draft        SIP Instrument Identification         January 2010


       Section 8.3.

   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.

   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] 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.

8.3.  MAC assignment for soft phones

   Several EUI allocation methods can be used:

   1.  The organization owning the PBX can obtain a 24-bit OUI block
       from which to allocate EUI values.  The allocation would be done
       by the PBX, and the administrator would configure the EUI values
       into the soft phones.

   2.  The organization supplying the soft phone software could allocate
       and attach an EUI value to the software license for each soft
       phone instrument.  The administrator would enter the EUI values
       into the PBX.

   3.  The PBX could generate a "locally administered" EUI value for
       each soft phone, which the administrator would enter into the
       soft phone.  EUI values whose first byte's lowest two bits are
       "10" are reserved for local administration, and provide 2**46
       possible instrument identifiers.  (Note that instrument
       identifiers need to be unique only within a single PBX system.)
       The EUIs could be generated sequentially or randomly.  The
       administrator would enter the EUI values into the soft phone.

   4.  The soft phone could generate a random locally administered EUI
       value and display it to the administrator, who could enter it



Worley                   Expires August 2, 2010                [Page 15]

Internet-Draft        SIP Instrument Identification         January 2010


       into the PBX.

8.4.  Example

   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           |
       |------------------------------>|            |



Worley                   Expires August 2, 2010                [Page 16]

Internet-Draft        SIP Instrument Identification         January 2010


       |                |              |            |
       |  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]

   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]

   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].  This



Worley                   Expires August 2, 2010                [Page 17]

Internet-Draft        SIP Instrument Identification         January 2010


   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.



































Worley                   Expires August 2, 2010                [Page 18]

Internet-Draft        SIP Instrument Identification         January 2010


9.  Security Considerations

   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] 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.























Worley                   Expires August 2, 2010                [Page 19]

Internet-Draft        SIP Instrument Identification         January 2010


10.  Acknowledgments

   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.














































Worley                   Expires August 2, 2010                [Page 20]

Internet-Draft        SIP Instrument Identification         January 2010


11.  Revision History

11.1.  Changes from draft-worley-sipcore-instrument-identification-00 to
       draft-worley-sipcore-instrument-identification-01

   Reorganized sections.

   Added the "Second Method" section, describing use of MAC addresses as
   instrument identifiers.  Updated the Abstract accordingly.

11.2.  draft-worley-sipcore-instrument-identification-00

   Initial version.






































Worley                   Expires August 2, 2010                [Page 21]

Internet-Draft        SIP Instrument Identification         January 2010


12.  References

12.1.  Normative References

   [capabilities]
              Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [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.

   [uuid]     Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [802]      IEEE Computer Society, "802 IEEE Standard for Local and
              Metropolitan Area Networks: Overview and Architecture",
              IEEE Std 802-2001, February 2002.

12.2.  Informative References

   [dialog]   Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
              Initiated Dialog Event Package for the Session Initiation
              Protocol (SIP)", RFC 4235, November 2005.

   [digest]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [EUI]      Wikipedia, "MAC address".

   [gruu]     Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

   [gruu-implement]
              Worley, D., "Guidelines for Implementing the GRUU Support
              in User Agents", draft-worley-sip-gruu-implement-02 (work
              in progress), February 2007.

   [outbound]
              Jennings, C., Mahy, R., and F. Audet, "Managing Client
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.



Worley                   Expires August 2, 2010                [Page 22]

Internet-Draft        SIP Instrument Identification         January 2010


   [sipit]    "https://www.sipit.net/SIPit25_Summary".

   [sipXecs]  "http://sipxecs.sipfoundry.org".

   [ua-config]
              Lawrence, S., "User Agent Configuration Recommendation",
              December 2009.












































Worley                   Expires August 2, 2010                [Page 23]

Internet-Draft        SIP Instrument Identification         January 2010


Author's Address

   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








































Worley                   Expires August 2, 2010                [Page 24]