[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                               D. Petrie
Internet Draft                                                  Pingtel
Document: draft-petrie-sip-config-framewk-reqs-00.txt
Expires: July 2001                                     February 1, 2001


         Requirements for a SIP User Agent Configuration Framework


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.


   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.


Abstract

   This document defines a set of high level requirements for an
   extensible framework to configure SIP user agents






















   Petrie         Informational - Expires July 2001                 1
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1  Overview.......................................................3
   2  Conventions used in this document..............................3
   3  Assumptions....................................................3
   3.1  Network configuration........................................3
   3.2  Firewalls....................................................4
   3.3  Terminology..................................................4
   3.4  Simplicity...................................................4
   4  Requirements...................................................4
   4.1  Configuration Service Discovery..............................5
   4.2  Configuration Consumer Registration..........................5
   4.3  Configuration Retrieval......................................6
   4.4  Configuration Change Notification............................6
   4.5  Configuration Modification...................................7
   5  References.....................................................8
   6  Author's Address...............................................8

































   Petrie         Informational - Expires July 2001                 2
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

1  Overview

   There is a general need to standardize methods for adding,
   configuring, and maintaining SIP user agents within a VoIP system.
   When one considers the effort needed to set up systems with hundreds
   or thousands of user agents, the need for reducing set up time is
   obvious. After a system is set up, ongoing maintenance in the form
   of changing the configuration of the user agents, or upgrading the
   software or firmware on a large population of user agents, is likely
   to be necessary and requires a similar administrative effort.

   In addition to these scaling problems, it is likely that the
   population of user agents in any given VoIP system will be
   heterogeneous: the configuration strategy must be flexible enough to
   accommodate different needs for different users. Consequently, for
   VoIP system administration sanity and cost practicality, a multi-
   vendor configuration standard is needed.

   Due to the highly divergent capabilities and purposes of the SIP
   user agent population, it seems impractical to propose a single set
   of data content to configure all possible variations. Common data
   sets, or content profiles, can probably be defined, but special
   purpose user agents or vendor value-added features are always likely
   to need specific configuration data sets beyond any defined norm

   This document proposes a general framework to support the use of
   open data sets for configuring SIP user agents. Discussion of the
   requirements for the content and format of these data profiles is
   left for another document.

2  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

3  Assumptions

3.1 Network configuration

   An assumption is made that basic network configuration can be
   completed for the user agent device, based on the availability of
   either:

    - DHCP
    - a manual, vendor-specific method for providing static network
   settings to the user agent device

   Once basic network configuration is completed through one of these
   methods, the configuration task that remains is to make the device
   functional within its SIP domain.



   Petrie         Informational - Expires July 2001                 3
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

3.2 Firewalls

   There are two basic network topologies that need to be supported by
   a standard SIP UA configuration:

      · Hosted VoIP Services
      · Enterprise Based VoIP systems

   The primary difference between these topologies, from a
   configuration standpoint, is the placement of the server(s) that
   provide the configuration and the devices relative to a firewall.
   This spec does not propose to solve the firewall issue. At least one
   protocol (or set of protocols if more than one are used for
   configuration purposes) must be usable through a firewall, where the
   devices are on the inside and the server is on the outside.

3.3 Terminology

   Because a configuration server must perform a number of logical
   functions, implementers may decide to spread different functions
   across multiple servers. However, this document references this
   potential collection of configuration servers in the singular as
   “the server”.

   A user agent device may actually be software running on a general
   purpose computer, or a specially built hardware appliance. The user
   agent to be configured is referenced as “the device”.

3.4 Simplicity

   There are likely to be a wide range of configuration servers
   implemented (for example, to provide scalability range, feature
   sets, etc.). It is intended that the requirement defined here will
   allow the server to be active and feature rich. However, it should
   also be possible to build a simple server that meets the minimum
   requirement for devices by delivering nearly static configuration
   content.

4  Requirements

   The requirements for the configuration of a SIP user agent can be
   divided into the following high-level functions:

      · Discovery
      · Registration
      · Configuration Retrieval
      · Notification of Configuration Changes
      · Configuration upload/change

   These functional groups are intended only to provide a means to
   think about and organize the requirements. They are not required to
   be discrete steps, and they do not dictate a specific model.


   Petrie         Informational - Expires July 2001                 4
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

4.1 Configuration Service Discovery

   Once the network configuration has been resolved using either DHCP
   or some static method, the first problem for a new SIP user agent to
   solve is where to get its configuration. There are a number of well-
   defined ways to resolve this configuration service discovery
   problem. Most existing solutions are trivial to implement, although
   each has pros and cons.

   It is likely that a number of the existing solutions should be
   supported to perform this function as either the network environment
   or administration may dictate which solutions will work or be
   allowed.

      · A device MUST be able to determine where to retrieve its
      configuration without manual provisioning.

4.2 Configuration Consumer Registration

   The next operation that a new device in the network must perform is
   to register with the configuration server. The server may require
   notification of a device’s presence in order to create a new set of
   configuration data values, allocate resources, etc.

      · A device that is new to the configuration domain MUST make the
      configuration server aware of its presence before it can retrieve
      configuration data for the first time.

      · A server MUST be able to uniquely identify every device in its
      management domain.

      · A device’s identity MUST NOT change through its lifetime in a
      management domain.

      · A device MUST have specific identifying configuration values
      (for example, Vendor, Model number, Software or firmware version,
      serial number, MAC address, etc.).

      · To facilitate hardware swap out, it MUST be possible for
      device-specific configuration values, stored in the server, to be
      reassigned ).

      · The device MUST be able to specify the configuration data
      profiles that it requires (for example, the SIP parameters,
      software or firmware updates, CPL scripts, applications, etc.) so
      that the server can identify which devices are affected by a
      given configuration change.

      · The server MUST be able to specify the configuration data
      profiles that it can provide.




   Petrie         Informational - Expires July 2001                 5
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

      · The configuration server MUST be able to communicate the
      locations(s) (in the form of URL(s) or address(es), for example)
      from which the device may retrieve specific configuration data.

      · It MUST be possible, over time, to change the location(s) from
      which configuration data is retrieved (as the result of failure,
      administration changes, etc.).

      · The server MAY require authentication and authorization of the
      device in order for it to join the configuration server’s
      management domain.
      .
      · The device MAY require authentication of the server.

      · The device MAY support the ability to authenticate the
      configuration server.

4.3 Configuration Retrieval

   Configuration requirements and data are likely to vary widely from
   device to device. As a result, it is proposed that the mechanism for
   retrieval be a framework as opposed to closed and single purpose

   Where common sets of data can be derived across multiple vendors,
   data profiles can be defined to contain that common data in a
   standard format. These profiles should be named so that upon
   registration, a device can specify which profiles it requires

   However, it is unreasonable to expect that a single profile can be
   used to configure all devices, great and small. On the other hand,
   it is reasonable to define a single profile (or set of profiles)
   that will configure a device as a basic SIP user agent. Extended
   features and functions can then be configured through separate
   additional profiles.

      · A device MAY retrieve configuration data for a specified user.

      · The server MUST support the retrieval of device- and user-
      specific configuration data values by a device.

      · The server MAY infer a default user specific to that device, if
      the device does not specify a user for the configuration data
      retrieved.

      · The server and device MAY support secure retrieval of
      configuration data.

      · The server MAY require authorization for data retrieval.

4.4 Configuration Change Notification

   Configuration data is not static. It is likely to be changed over
   time on the server by either this standard, or by some proprietary

   Petrie         Informational - Expires July 2001                 6
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework

   interface. It is up to the implementer to provide the business logic
   as to when devices should be notified after some configuration
   change occurs on the server. As a result, a standard means of
   notifying the device that changes in the configuration data of
   interest have occurred is proposed.

   In some environments it may not be possible for the server to
   initiate configuration change notifications.

      · The server MAY notify the device of configuration data changes.

      · The device SHOULD perform the necessary operations to retrieve
      and make effective the configuration changes indicated by the
      change notification.

      · The server and the device SHOULD support an expiration period
      for configuration data. When this period ends, the device SHOULD
      automatically retrieve refreshed data or confirm that no changes
      have occurred.

      · The server MAY specify in advance that a configuration change
      is to occur (that is, schedule changes).

4.5 Configuration Modification

   In addition to data changes made on the server, the device (or other
   consumers of device configuration) may provide a facility for
   modifying the data. The device therefore requires a means of
   communicating such configuration modifications back to the server.

      · The device MAY upload configuration changes to the server.

      · The server MAY require authentication and authorization for the
      configuration changes.

      · The server MAY enforce authentication and authorization scopes
      at a finer granularity than on a single vs. whole configuration
      profile (that is, some end users may not be permitted to modify
      all parameters).

      · The user requesting the configuration change MAY be different
      than the user to whom the configuration profile applies.












   Petrie         Informational - Expires July 2001                 7
                  Requirements for a SIP User Agent     February 2001
                       Configuration Framework


5  References

   [1] S. Bradner, "The Internet Standards Process -- Revision 3",
   RFC2026 (BCP), IETF, October 1996.

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   Session Initiation Protocol", Request for Comments (Proposed
   Standard) 2543, Internet Engineering Task Force, Mar1999.

   [3] H. Schulzrinne, “Configuring IP Telephony End Systems”, Internet
   Draft, Internet Engineering Task Force, December 28, 2000 Work in
   progress.



   1  RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997


6  Author's Address

   Dan Petrie
   Pingtel Corp.
   400 W. Cummings Park         Phone:  1-781-938-5306
   Suite 2200                   Email:  dpetrie@pingtel.com
   Woburn, MA 01801 USA



























   Petrie         Informational - Expires July 2001                 8