Re: [dispatch] New Version Notification for draft-worley-instrument-identification-00

["Dale Worley" <[e-mail]>]

I've written up an internet-draft describing how the sipXecs open-source
PBX identifies which telephone makes each registration, which allows us
to obtain information about specific telephones rather than about AORs.
For example, "SUBSCRIBE sip:~~in~[e-mail]" will get the
complete dialog status for the telephone with MAC address 0000DEADBEEF,
even if the AORs that appear on it appear on other telephones.

The mechanism works well in practice, but it's a hack, since it involves
inserting the phone's MAC address into the authorization user-name
field.  What we want to do is use the phone's "SIP instance" URI to
identify itself, but there are a number of problems involved in doing
that.  It doesn't look like they are particularly difficult, but they
would require consensus and getting the phone vendors to bring their
devices into line.  See section 5 of the draft, which I have copied into
the bottom of this message.

The announcement of the I-D follows, and then section 5, which I want
comments on.

Dale


On Sun, 2009-10-18 at 09:50 -0700, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-worley-instrument-identification-00.txt has been successfuly submitted by Dale Worley and posted to the IETF repository.
> 
> Filename:	 draft-worley-instrument-identification
> Revision:	 00
> Title:		 Identifying Individual Telephone Instruments in SIP
> Creation_date:	 2009-10-18
> WG ID:		 Independent Submission
> Number_of_pages: 18
> 
> http://www.ietf.org/id/draft-worley-instrument-identification-00.txt
>
> 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 a method 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.
> 
> Unfortunately, although the method works well in practice, it
> violates separation of concerns by carrying instrument identification
> information in an authentication-related field.  This draft includes
> a preliminary discussion of better ways to identify instruments.


5.  Future Improvements

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