Re: [dispatch] New Version Notification for draft-worley-instrument-identification-00
"Dale Worley" <dworley@nortel.com> Mon, 09 November 2009 05:11 UTC
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0BF28C0CF for <dispatch@core3.amsl.com>; Sun, 8 Nov 2009 21:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level:
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siGUYNnHYcjk for <dispatch@core3.amsl.com>; Sun, 8 Nov 2009 21:11:40 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 988B728C0D6 for <dispatch@ietf.org>; Sun, 8 Nov 2009 21:11:40 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nA95C1N15437 for <dispatch@ietf.org>; Mon, 9 Nov 2009 05:12:01 GMT
Received: from [47.141.31.138] ([47.141.31.138]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 00:12:00 -0500
From: Dale Worley <dworley@nortel.com>
To: DISPATCH <dispatch@ietf.org>
In-Reply-To: <20091018165027.4C8643A68B9@core3.amsl.com>
References: <20091018165027.4C8643A68B9@core3.amsl.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Mon, 09 Nov 2009 00:11:58 -0500
Message-Id: <1257743518.4458.11.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Nov 2009 05:12:00.0500 (UTC) FILETIME=[2AD2DB40:01CA60FB]
Subject: Re: [dispatch] New Version Notification for draft-worley-instrument-identification-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 05:11:42 -0000
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~0000DEADBEEF@example.net" 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.