[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-petrie-sipping-config-framework) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 6080

                                                       D. Petrie
   Internet Draft                                      Pingtel Corp.
   draft-ietf-sipping-config-framework-00.txt
   Expires: Aug 2003                                   Feb 2003


               A Framework for SIP User Agent Configuration


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 the application of a set of protocols for
   configuring a SIP user agent.  The SIP user agent must discover how
   and from where to retrieve its initial configuration and be notified
   of changes and updates which impact its configuration.  The
   objective is to define a means for automatically configuring a user
   agent such that it can be functional without user or administrative
   intervention.  The framework for discovery, delivery, notification
   and updates of user agent configuration is defined here.  This
   framework is also intended to ease ongoing administration,
   configuration and upgrading of large scale deployments of SIP user
   agents.  The contents and format of the configuration data to be
   defined is outside the scope of this document.


   Petrie          Informational - Expires Aug 2003                  1
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1  Overview.......................................................3
   2  Conventions used in this document..............................4
   3  Changes from Previous Draft....................................4
   3.1  Changes from draft-petrie-sipping-config-framework-00.txt....4
   3.2  Changes from draft-petrie-sip-config-framework-01.txt........4
   3.3  Changes from draft-petrie-sip-config-framework-00.txt........4
   4  Discovery......................................................5
   4.1  DHCP Option..................................................6
   4.2  DNS..........................................................6
   4.3  Multicast....................................................7
   4.4  Manually Provisioned.........................................7
   5  Enrollment and Change Notification.............................7
   5.1  SUBSCRIBE....................................................8
   5.1.1 Additional User Agent Field Parameters......................9
   5.2  NOTIFY......................................................10
   5.2.1 NOTIFY Body Content Format.................................11
   6  Configuration Retrieval.......................................11
   7  Configuration Upload..........................................11
   8  Examples......................................................12
   8.1  Example Message Flows.......................................12
   8.2  Example Messages............................................14
   9  Security Considerations.......................................17
   10 Open Issues...................................................18
   11 References....................................................19
   12 Author's Address..............................................20


   Petrie         Informational - Expires Aug. 2003                 2
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

1  Overview

   Today all SIP UA vendors use proprietary means of delivering
   configuration to the UA.  This configuration framework is intended
   to enable a first phase migration to a standard means of configuring
   SIP user agents.  It is expected that UA vendors should be able to
   use this configuration framework as a means of delivering their
   existing proprietary configuration data profiles (i.e. using their
   existing proprietary binary or text formats).  This in itself is a
   tremendous advantage in that a SIP environment can use a single
   configuration server to deliver configuration data to UAs from
   multiple vendors.  Follow-on standardization activities can: 1)
   define a standard format (e.g. XML or name-value pairs [8]) and 2)
   specify the content (i.e. name the configuration parameters) of the
   configuration data profiles.

   This document defines a framework which allows SIP user agents (UA)
   to automatically:
        - discover a configuration server (Discovery)
        - enroll with the configuration server (Enrollment)
        - retrieve configuration data (Configuration Retrieval)
        - receive notification of configuration changes (Change
          Notification)
        - upload configuration data changes back to the server
          (Configuration Upload)

   The content and format of the data is not defined in this document.
   It will be defined in configuration data profile(s) in other
   document(s). The goal of this framework is to satisfy the
   requirements for configuration delivery defined in [10], [11] and
   [16] explicitly excluding the requirements which pertain to
   configuration data profile content and format.

   Discovery is the process by which a UA SHOULD find the address and
   port at which it SHOULD enroll with the configuration server.  As
   there is no single discovery mechanism which will work in all
   network environments, a number of discovery mechanisms are defined
   with a prescribed order in which the UA SHOULD try them until one
   succeeds.

   Enrollment is the process by which a UA SHOULD make itself known to
   the configuration server. In enrolling the UA MUST provide identity
   information, name requested configuration data profile and supported
   protocols for configuration retrieval.  It SHOULD also SUBSCRIBE to
   a mechanism for notification of configuration changes.  As a result
   of enrollment, the UA receives a URL for each of the configuration
   data profiles that the configuration server is able to provide.
   Each profile requires a separate enrollment or SUBSCRIBE session.

   Configuration Retrieval is the process of retrieving the content for
   each of the configuration data profiles the UA requested.


   Petrie         Informational - Expires Aug. 2003                 3
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   Change Notification is the process by which the configuration server
   notifies the UA that the content of one or more of the configuration
   data profiles has changed. Subsequently the UA SHOULD retrieve the
   data profile from the specified URL upon receipt of the change
   notification.

   Configuration Upload is the process by which a UA or other entity
   pushes a change to a configuration data profile back up to the
   configuration server.

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

   The syntax and semantics used here extend those defined in SIP (RFC
   2543) [6]. SIP is described in an augmented Backus-Naur form (ABNF).
   See [6, section C] for an overview of ABNF.

3  Changes from Previous Draft

3.1 Changes from draft-petrie-sipping-config-framework-00.txt

   Changed name to reflect SIPPING work group item

   Updated with changes to SIP DHCP [3], SIP [6], SIP Events [7] and
   content indirection [15].

   Moved the device identity parameters from the From field parameters
   to User-Agent header parameters.

   Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and
   Adam Roach of Dyamicsoft for the great comments and input.

3.2 Changes from draft-petrie-sip-config-framework-01.txt

   Changed the name as this belongs in the SIPPING work group.

   Minor edits

3.3 Changes from draft-petrie-sip-config-framework-00.txt

   Many thanks to those who contributed and commented on the previous
   draft.  Detailed comments were provided by Henning Schulzrinne from
   Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco, Rich
   Schaaf from Pingtel.

   Split the enrollment into a single SUBSCRIBE dialog for each
   profile.  The 00 draft sent a single SUBSCRIBE listing all of the
   desired.  These have been split so that each enrollment can be
   routed differently.  As there is a concept of device specific and

   Petrie         Informational - Expires Aug. 2003                 4
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   user specific profiles, these may also be managed on separate
   servers.  For instance in a roaming situation the device might get
   itÆs configuration from a local server which knows the LAN specific
   configuration.  At the same time the user specific profiles might
   come from the userÆs home environment configuration server.'

   Removed the Config-Expires header as it is largely superfluous with
   the SUBSCRIBE Expires header.

   Eliminated some of the complexity in the discovery mechanism.

   Suggest caching information discovered about a configuration server
   to avoid an avalanche problem when a whole building full of devices
   powers up.

   Added the User-Profile From header field parameter so that the
   device can a request a user specific profile for a user that is
   different from the deviceÆs default user.

4  Discovery

   The purpose of discovery is to figure out how to address the
   configuration server so that the device can enroll.  The enrollment
   process involves sending a SIP SUBSCRIBE.  Prior to this the
   discovery process must find the address to use in the URL for the
   URI and To header field.  The URL SHOULD use the user id:
   sipuaconfig.  From a SIP perspective the configuration server is
   simply a user agent. By using the well known user id, this makes it
   easy for proxy servers to be provisioned to route the enrollment
   requests from devices to the appropriate configuration server for
   the domain.

   The first time a UA is plugged in it does not know the address or
   port at which to enroll with the local configuration server.  It
   must discover this address and port.  A UA SHOULD support all of the
   listed discovery mechanisms.  It MUST support at least one of them.
   Once the UA has discovered the address and port and has successfully
   enrolled with the configuration server, the UA SHOULD cache the
   address and port to avoid the need to re-discover the configuration
   server.  However if enrollment, configuration retrieval or
   configuration upload fails at any time, the UA SHOULD apply the
   discovery and enrollment process again.  This provides a means for
   configuration server fail over and load balancing.
   The UA SHOULD use the following mechanisms to discover the host
   address and port at which it SHOULD enroll with the configuration
   server.  Each mechanism should be tried in the following order until
   an address and port is provided which results in successful
   enrollment (i.e. the server responds with a successful 2xx class
   response):
        - DHCP option for SIP [3]
        - DNS A record
        - Multicast
        - Manual provisioning

   Petrie         Informational - Expires Aug. 2003                 5
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration


   The rationale for this order follows.  Assuming that most UAs are
   going to use DHCP for IP configuration anyway, using a DHCP option
   is the least costly in terms of lookup time (i.e. no additional
   messages are required).  Hence DHCP is first.  Multicast is used
   last of the automated discovery mechanisms as it is the most
   restricted in terms of network environments that support it.
   Multicast is included, even though the applicable environments are
   restricted, as it is the only mechanism that can be used without the
   support of the local network administrator.

        The phone administrator and the network administrator are often
        different people and perhaps in different departments.

   The UA implementer MAY provide the user or administrator with the
   means to change the order in which these mechanisms are tried.  This
   includes the ability to manually override the discovery process.
   However by default without user interaction the UA SHOULD use the
   order listed above.

   Once discovery is successful the device SHOULD persistently cache
   the address to avoid avalanche problems when a whole building full
   of devices powers up at once.  The characteristic of the profile may
   dictate this behavior.  For example device specific profiles may
   need to change when the device is moved to a different location.
   User specific profiles may be independent of the LAN, network or
   device location.

4.1 DHCP Option

It is likely that most UAs in an deployment of any significant size
will use DHCP for IP configuration.  DHCP becomes a convenient means to
discover the configuration server address.  In the same DHCP request
for basic IP configuration, the UA can add the option for SIP[3] [1] to
the options field.  This indicates a request for the default SIP proxy
server address and port.  For example if the DHCP option for SIP
returns an address of sip.acme.com and a port of 5080, the following
URL is constructed: sip:sipuaconfig@sip.acme.com:5080.  If the proxy
server address and port is not returned in the DHCP response or the
server does not respond to the enrollment request with a successful 2xx
class response, the next discovery mechanism is attempted.

4.2 DNS

   The UA SHOULD construct a fully qualified host name using
   ôsipuaconfigö as the host and the local domain if defined.  It
   SHOULD try a DNS A record lookup on the fully qualified host name.
   If the name resolves in DNS it should then attempt enrollment.  For
   example the URL constructed in the local domain of acme.com would
   look like: sip:sipuaconfig@sipuaconfig.acme.com.  If the server does
   not respond to enrollment with a successful 2xx class response, the
   next discovery mechanism is attempted.


   Petrie         Informational - Expires Aug. 2003                 6
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

4.3 Multicast

   The enrollment request is sent to the multicast address for SIP
   registration [6] "sip.mcast.net" (224.0.1.75).  If a server does not
   respond with a successful 2xx class response to the enrollment
   request, the next discovery mechanism is attempted.

4.4 Manually Provisioned

   The UA MAY indicate to the user (or administrator) that automatic
   discovery has failed. The UA SHOULD allow the user or administrator
   to manually (perhaps using some out of band method e.g. beam, smart
   card, etc.) enter the configuration server address and port to be
   used for enrollment.

5  Enrollment and Change Notification

   The enrollment and configuration change notification are paired
   together and provided via the SIP SUBSCRIBE/NOTIFY framework [7].
   This document defines the profile on top of the SUBSCRIBE/NOTIFY
   framework [7] for this purpose.

   UA enrollment with the configuration server is accomplished via the
   SUBSCRIBE request.  A UA MUST enroll with the configuration server
   prior to retrieving configuration data profiles.  As part of the
   enrollment the UA MUST identify itself, its configuration retrieval
   protocol capabilities and configuration data profile requirements.

   The configuration server may use this information to decide how to
   allocate resources (e.g. load balancing) to support the UA for its
   specific configuration retrieval needs.  The configuration server
   may also use the UA enrollment event as the trigger to generate a
   new set of configuration data for the specific UA (e.g. based upon
   provisioned defaults and configuration profile context knowledge for
   the environment).  This allows the configuration server to provide
   configuration data for a new UA without previously provisioning the
   specific UA on the server.

   Each profile that the device requires is obtained via a separate
   enrollment or SUBSCRIBE request and SIP dialog.  That is for each
   different profile a device enrolls for, a different Call-Id is used.
   The device names the profile MIME type in the SUBSCRIBE Accept
   header field.  The configuration server then delivers a URL (through
   content indirection [15]) at which the device can retrieve the
   profile in a subsequent NOTIFY request.  Changes to the profile are
   indicated in additional NOTIFY requests sent from the configuration
   server.

   The SUBSCRIBE request for enrollment is sent to the address(es)
   identified in the discovery process until the first successful 2xx
   class response is received.  As part of the binding of the
   SUBSCRIBE/NOTIFY framework a new MIME type must be named for each

   Petrie         Informational - Expires Aug. 2003                 7
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   type of profile.  The profile(s) MIME type(s) MUST be included in
   the SUBSCRIBE Accept header field.

   [Is it ok to allow a single SUBSCRIBE to request multiple profile
   types in (e.g. for each MIME subtype application/sip-ua-user-profile
   and application/sip-ua-device-profile)?]

   If enrollment fails (i.e. no 2xx response to SUBSCRIBE), the UA
   SHOULD re-discover the configuration server address and port as
   described in section 3.



5.1 SUBSCRIBE

   The SUBSCRIBE request is used by the UA to enroll in the
   configuration domain of the configuration server.  It uniquely
   identifies the UA with vendor, model and serial number information.
   The UA also MUST specify its capabilities for configuration
   retrieval. The UA MUST indicate support for content indirection by
   including the MIME type message/external-body in the SUBSCRIBE
   Accept header field per [15].

   The configuration server SHOULD not send an error if it is
   temporarily not able to provide the configuration data profile
   listed in the SUBSCRIBE request Event header field.  In the first
   time out of the box case, the SUBSCRIBE dialog may be the only means
   of communicating with the device as it does not yet have
   configuration.  The configuration server SHOULD send a 403 response
   to the SUBSCRIBE if is not willing to provide the requested
   configuration profile to the device.  The configuration server
   SHOULD provide the configuration data profile to the UA via content
   indirection.  If the configuration server sends a 301 Moved
   Permanently response to the enrollment SUBSCRIBE, the UA SHOULD
   cache the URL contained in the response Contact header field in
   place of the address and port found during discovery for future
   enrollment.

        The device may request many configuration data profiles by
        sending multiple SUBSCRIBE requests each in a different SIP
        dialog.  This may be useful if the device requires user
        specific profiles for multiple users.  In this case the
        UserProfile parameter would vary for each SUBSCRIBE.
        Alternately the device may require multiple types of profiles
        where each SUBSCRIBE would have a different MIME type in the
        Accept header field.

   The configuration server MAY use the enrollment (SUBSCRIBE request)
   as the stimulus to generate a new instance of a configuration data
   profile unique to the UA.  Alternately the configuration server MAY
   be provisioned ahead of time to know about new UAs and their
   specific configuration data content (for example based upon serial
   number, MAC address).

   Petrie         Informational - Expires Aug. 2003                 8
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration


   The user agent forms the From field in the SUBSCRIBE in one of two
   ways depending upon the type of profile that it is enrolling to.  If
   the user agent is enrolling to a device specific profile, the from
   addr-spec is formed as: sip:<MAC-address>@<local-domain>.  If the
   user agent is enrolling to a user specific profile the addr-spec is
   formed as the users address of record.  In this way the identity for
   which the profile is desired is always specified in the From field.

5.1.1   Additional User Agent Field Parameters



   When the device first starts up out of the box, it has no user or
   local configuration.  The device MUST provide a unique identity such
   that it is possible for the configuration server to generate
   configuration profile for the device.  The user agent MUST include
   the User-Agent header in the SUBSCRIBE request.  The following
   additional User-Agent field parameters are defined for the purpose
   of identifying the UA device:

   Vendor û a token used to identify the UA vendor name

   Model û a token used to identify the UA hardware/software model

   Version û a token used to identify the firmware/software version
   currently installed on the UA

   Serial û the token used to identify the serial number for the UA

        Note: on some hardware such as PCs and servers, there may be
        multiple instances of a user agent installed.  In these
        scenarios only the serial number can be used to uniquely
        distinguish instances.

   Mac û the token used to identify the MAC address in hex for the UA

   From RFC 3261 [6] the User-Agent header field syntax is extended to:
   User-Agent  =  "User-Agent" HCOLON product *( SEMI config-params )

   config-params = serial-param / mac-param / generic-param
   product          =  vendor-model [SLASH product-version]
   product-version  =  token
   vendor-param  =  ôVendorö ô=ö token
   serial-param  =  ôSerialö ô=ö token
   mac-param  =  ôMacö ô=ö token


   Example:
   User-Agent: model-a/1.5.0.1;vendor=acme

   The Vendor, Model, Version, Serial and Mac parameters MUST be
   provided in the User-Agent header field for the enrollment SUBSCRIBE

   Petrie         Informational - Expires Aug. 2003                 9
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   request.  Most profiles will either be device or user specific.  All
   config-params MUST be specified even when enrolling for user
   profiles as the device characteristics may impact the content that
   the profile server provides.

5.2 NOTIFY

   The NOTIFY message is sent by the configuration server to convey the
   URL at which the UA can retrieve the requested configuration data
   profile.  This occurs in two contexts:

     Immediately following the enrollment SUBSCRIBE the configuration
     server MUST send a NOTIFY providing the URL for the configuration
     data profile requested by the UA in the Event header field of the
     SUBSCRIBE request.  If the configuration server is not able to
     provide the specific configuration data profile or it does not
     want the UA to retrieve the specific configuration profile at that
     time, it MAY defer sending NOTIFY.  Later when the configuration
     server is able to provide the data profile or it wishes the UA to
     retrieve the data profile, the configuration server MAY send a
     NOTIFY request containing the URL for the configuration data
     profile which the UA SHOULD retrieve and make effective as soon as
     it is safe to do so (e.g. when there are no active INVITE
     dialogs).

     If the configuration server becomes aware of a configuration
     change that it wishes to be effective immediately on the UA, the
     configuration server SHOULD send a NOTIFY message containing the
     URL for the configuration data profile that the UA requested when
     it enrolled.  The configuration data profile with changed content
     SHOULD have a different Content-ID entity header than that of the
     last NOTIFY request.  The UA SHOULD retrieve and make effective
     the changed configuration URL immediately upon receipt of the
     NOTIFY request.  The UA MAY choose to wait to make the changes
     effective (e.g. to prevent the change from disrupting active calls
     on the UA).

     [Do we need an option for the configuration server to tell the UA
     that it MUST make the change immediately regardless of state?
     Should this be the default?]

   The UA SHOULD send a 200 response to the NOTIFY immediately upon
   receipt and validation of the solicited request.  The configuration
   server MUST include, in the change notification NOTIFY request,  the
   configuration data profile URL.  The Content-ID entity header
   associated with the configuration data profile with changed content
   should be different than that of the previous NOTIFY.
     This mechanism may be used by the configuration server to provide
     firmware updates.  For example on a UA that caches or has a
     persistent firmware image: if the server realizes (e.g. from the
     enrollment information) the UA is running the most currently
     available firmware version, it could defer sending the NOTIFY with
     the URL for the firmware.  However at a later time when a new

   Petrie         Informational - Expires Aug. 2003                10
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

     firmware version is available the configuration server could send
     a NOTIFY with the URL for the new firmware version, indicating the
     UA SHOULD upgrade as soon as it is safe to do so.

5.2.1   NOTIFY Body Content Format

The NOTIFY request MUST contain a single part body with content
indirection [15].  The request MUST have a Content-Type header field
with the MIME type of message/external-body.  The Content-Type MUST
also have a URL parameter specifying the URL at which to retrieve the
profile.  The body MUST contain a Content-Type entity header with the
MIME type of the profile as the value.  The body MUST also contain a
Content-ID entity header which SHOULD change to a new unique value each
time the content of the URL changes.    The Content-ID entity header
associated with the URL is intended to allow the UA to decide if it has
the latest content of the configuration data profile without having to
download and compare the contents.

   Example:

   NOTIFY sip:00df1e004cd0@acme.com SIP/2.0
   From: sip:sipuaconfig@sipuaconfig.acme.com;tag=1234
   To: sip:00df1e004cd0@acme.com;tag=abcd
   Call-ID: 3573853342923422@10.1.1.123
   CSeq: 2131 INVITE
   Content-Type: message/external-body;
                 ACCESS-TYPE=URL;
                 URL="https://acme.com/profiles/vendor-x/00df1e004cd0"
   Content-Length: ...
   Content-Type: application/foo-profile
   Content-Disposition: session
   Content-ID: <1000957853@acme.com>

6  Configuration Retrieval

   The UA MUST retrieve its configuration data profile using the URL
   specified by the configuration server in the NOTIFY request.  If the
   retrieval fails, the UA SHOULD not re-enroll until the SUBSCRIBE
   session expires to avoid a cascade effect if the server goes down
   temporarily.  The device MAY re-try the profile retrieve of the
   profile from the URL before the SUBSCRIBE expires. Should the re-
   enrollment fail, the UA SHOULD re-discover the configuration server
   as described in section 4.

7  Configuration Upload

   If the UA or another entity wishes to modify a configuration data
   profile it MAY make the change persistent on the configuration
   server if it is authorized to do so.  The configuration server
   SHOULD support the ability to accept uploads via the same URL the UA
   used to retrieve the configuration data profile.  For HTTP and HTTPS
   the UA does a POST with a multipart MIME attachment containing any
   URL parameters in one part and the changed configuration data

   Petrie         Informational - Expires Aug. 2003                11
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   profile [whole or changes only ?? define in profiles ??] in another
   part as defined in [?].  If the UA or user is not permitted to make
   the changes on the configuration server the configuration server
   returns an HTTP error response code of 403 Forbidden.  If the
   configuration server returns a 403 the UA SHOULD disallow the
   changes from being effective on the UA.   The UA SHOULD not make the
   changes effective until it receives a successful response (e.g. for
   HTTP 2xx).

   If the URL is for HTTP/HTTPS the server MUST return the changed
   configuration data profile in the response (assuming it was
   allowed). The UA SHOULD use the configuration data profile contents
   from the HTTP response as opposed to the data that was pushed in the
   request as changes may occur from other sources.  The server SHOULD
   include a Content-ID header in the HTTP/HTTPS response.  The
   configuration server SHOULD send out a NOTIFY for this change, using
   the same Content-ID entity header value as in the HTTP/HTTPS
   response. This allows the UA to know that it already has the current
   contents of the configuration data profile and SHOULD not download
   that configuration data profile (i.e. it is safe to ignore the
   NOTIFY as the Content-ID is the same).

   [Alteratively the Content-ID could be put in the content as opposed
   to the HTTP/HTTPS response]

   [TBD û in 403 case restrict and provide feedback as to what
   specifically is not allowed to be modified by the UA or user]

8  Examples

   Below is an example high level message flow for a new UA discovering
   and using configuration data from a configuration server.  Following
   the high level message flows are some specific SIP messages
   illustrating SUBSCRIBE and NOTIFY messages from enrollment and
   configuration change notification.

8.1 Example Message Flows

   The following high level message flows illustrate the configuration
   process of discovery, enrollment, configuration retrieval and change
   notification with associated configuration retrieval.  The UA uses
   DHCP with the SIP [3] option requesting the configuration server
   address and port.  The DHCP server does not provide the
   configuration server address or port.  The UA then does a DNS lookup
   for the configuration service within the local domain.  It gets a
   response from the DNS server for the configuration serverÆs fully
   qualified host name.  The UA then enrolls with the configuration
   server by sending a SUBSCRIBE request for the profile type indicated
   in the Event header.  The configuration server sends back a
   successful response.  The configuration server then sends a NOTIFY
   request with the URL for the configuration data profile that the UA
   named in the enrollment SUBSCRIBE request.  The UA sends a 200
   response to the NOTIFY.  The UA then downloads the configuration

   Petrie         Informational - Expires Aug. 2003                12
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   data profile via the URL from the NOTIFY request.  This process may
   be repeated in parallel for each of the required profiles.  The UA
   is now configured as prescribed.

   Later ... an administrator makes a change to the configuration for
   the UA on the configuration server.  The configuration server on
   behalf of the administrator, sends a NOTIFY (change notification)
   request to the UA with Content-ID entity header for the profile.  As
   the Content-ID value has changed, the UA downloads the configuration
   data profile from the given URL.

   UA           DHCP Server     DNS Server      Config. Server

   Discovery

   IP config. req.
   ==============>
   IP config. wo/ local option
   <==============
   DNS A record req. for sipuaconfig host in local domain
   =============================>
   A record IP address returned for Host
   <=============================

   Enrollment

   SIP SUBSCRIBE Event: sip-config
   ==================================================>
   200 OK
   <==================================================
   SIP NOTIFY Event: sip-config w/ requested profile URL
   <==================================================
   200 OK
   ==================================================>

   Configuration retrieval

   HTTP GET
   ==================================================>
   200 OK (specific profile data in body)
   <==================================================
   .
   .
   .

   Administrative change on configuration server via user interface
   .
   .
   .


   Petrie         Informational - Expires Aug. 2003                13
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   Change Notification

   SIP NOTIFY Event: sip-config w/ changed profile URL
   <==================================================
   200 OK
   ==================================================>
   HTTP GET
   ==================================================>
   200 OK (profile data in body)
   <==================================================
   .
   .
   .

   User changes data in a profile on the user agent
   .
   .
   .

   Configuration Upload

   HTTP POST (changed profile attached as multipart MIME)
   ==================================================>
   200 OK (profile data in body, as change confirmation)
   <==================================================
   .
   .
   .

8.2 Example Messages


   Petrie         Informational - Expires Aug. 2003                14
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   The following SUBSCRIBE request example is from a UA enrolling with
   a configuration server.  As this SUBSCRIBE request is for
   configuration enrollment the Event header field contains the token
   sip-config.  The UA tells the configuration server that it would
   like the configuration data profile of type: sip-ua-device-config in
   the Accept header field.  The UA tells the configuration server that
   it is enrolling for 86400 seconds via the Expires header field.
   During this period of time the configuration server MUST send a
   change notification  with the URL for the configuration data profile
   which changed.  The UA has identified the specifics about itself in
   the From field addr-spec and User-Agent parameters: Vendor/Model,
   Version, Serial, Mac.  In this example the UserProfile parameter is
   not included in the From field as the sip-config profile is device
   specific not user specific.


   UA => Config. Server

   SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0
   To: sip:sipuaconfig@sipuaconfig.localdomain.com
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   User-Agent: acme-model-a/1.5.0.1;Serial=1234567890;Mac=000aaa1234cd
   Call-Id: 987654321@10.1.1.123
   Cseq: 1 SUBSCRIBE
Event: sip-config
   Expires: 86400
   Content-Length: 0
   Accept: message/external-body application/sip-ua-device-config

   The following is an example response to the above enrollment
   request.

   Config. Server => UA

   SIP/2.0 202 Accepted
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   Call-Id: 987654321@10.1.1.123
   Cseq: 1 SUBSCRIBE
   Content-Length: 0


   Petrie         Informational - Expires Aug. 2003                15
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration


   In the following example the device is requesting a user specific
   profile Sip-User.  The device specifies that it want the profile for
   the user: sip:fredsmith@localdomain.com.

   UA => Config. Server

   SUBSCRIBE sip: sipuaconfig@sipuaconfig.localdomain.com SIP/2.0
   To: sip:sipuaconfig@sipuaconfig.localdomain.com
   From: sip:fredsmith@localdomain.com;tag=klhfkjncd
   User-Agent: acme-model-a/1.5.0.1;Serial=1234567890;Mac=000aaa1234cd
   Call-Id: 11111111@10.1.1.123
   Cseq: 1 SUBSCRIBE
   Event: sip-config
   Expires: 86400
   Content-Length: 0
   Accept: message/external-body application/sip-ua-user-config

   The following is an example response to the above enrollment
   request.

   Config. Server => UA

   SIP/2.0 202 Accepted
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=oqieu983
   From: sip:fredsmith@localdomain.com;tag=klhfkjncd
   Call-Id: 11111111@10.1.1.123
   Cseq: 1 SUBSCRIBE
   Content-Length: 0


   The following example is the immediate NOTITY request the
   configuration server sent to the UA above enrollment.  The URL in
   the request body is for the configuration data profile the UA named
   in the Event header field in the above SUBSCRIBE request from the
   UA.

   Config. Server => UA

   NOTIFY sip:10.1.1.123 SIP/2.0
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   Call-Id: 987654321@10.1.1.123
   Cseq: 22 NOTIFY
   Event: sip-config
   Content-Type: message/external-body;ACCESS-TYPE=URL;
     URL="http://config.localdomain.com/device/000aaa1234cd/dev-prof
   Content-Length: ...

   Content-Type: application/sip-ua-device-config
   Content-ID: 000aaa1234cd-3254@localdomain.com


   Petrie         Informational - Expires Aug. 2003                16
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   The following is an example response from the UA for the above
   request.

   UA => Config. Server

   SIP/2.0 200 Ok
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   Call-Id: 987654321@10.1.1.123
   Cseq: 22 NOTIFY
   Content-Length: 0


   Assume at some later time, an administrator makes a change to the
   content of the sip-config configuration data profile for the UA.
   The configuration server sends a NOTIFY request to the UA for the
   configuration change notification.  This example request below
   indicates the changed URL or content in the request body with a
   higher sequence number.

   Config. Server => UA

   NOTIFY sip:10.1.1.123 SIP/2.0
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   Call-Id: 987654321@10.1.1.123
   Event: sip-config
   Cseq: 23 NOTIFY
   Content-Type: message/external-body;ACCESS-TYPE=URL;
     URL="http://config.localdomain.com/device/000aaa1234cd/dev-prof
   Content-Length: ...

   Content-Type: application/sip-ua-device-config
   Content-ID: 000aaa1234cd-3255@localdomain.com

   The following is an example response to the above request.

   UA => Config. Server

   SIP/2.0 200 Ok
   To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234
   From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd
   Call-Id: 987654321@10.1.1.123
   Cseq: 23 NOTIFY
   Content-Length: 0

9  Security Considerations

   [This section needs to be greatly expanded and elaborated]

   SIP basic and digest authentication [6] MAY be used for
   SUBSCRIBE/NOTIFY messages used for enrollment and configuration
   change notification.  There is a chicken and egg problem.  Since the

   Petrie         Informational - Expires Aug. 2003                17
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

   content of SUBSCRIBE/NOTIFY messages are transported in the clear,
   the credentials that the UA uses in the SUBSCRIBE 401 challenge, or
   that the configuration server uses in the NOTIFY 401 challenge must
   be provisioned out of band (i.e. user or administrator manual input,
   beamed via PDA, smart card, etc.) via a secure means.

   Configuration data profile URLs are communicated in the clear in the
   NOTIFY requests from the configuration server.  The security risk of
   unauthorized access of the URL content can be mitigated if the
   configuration server and UA both support basic authentication and
   HTTP or HTTPS.  There is a chicken and egg problem here as well
   since the content of SUBSCRIBE/NOTIFY messages are transported in
   the clear.  Accordingly,the credentials that the UA uses for the
   HTTP/HTTPS GET/POST 401 challenge must be provisioned out of band
   (i.e. user or administrator manual input, beamed via PDA, smart
   card, etc.) via a secure means.

   Using HTTPS over TLS[13] the configuration server MAY request the
   certificate of the UA [14].  If this level of authentication is
   desired, the UA vendor SHOULD ship the UA with a digital certificate
   or provide a means by which this can be installed out of band.  The
   configuration server MUST be provisioned with the certificates of
   authority allowed for each model of UA to be supported.

   Using HTTPS the UA MAY request the certificate of the configuration
   server.  If this level of authentication is desired the UA must be
   provisioned with the allowed certificate(s) of authority and
   identities for the configuration server out of band (i.e. user or
   administrator manual input, beamed via PDA, smart card, etc.) via a
   secure means.


10 Open Issues


   [Do we need an option for the configuration server to tell the UA
   that it MUST make the change immediately regardless of state?
   Should this be the default?]

   [Upload to configuration server configuration data profiles whole or
   changes only ?? define in profiles ??]

   [Security considerations section needs much elaboration]

   Petrie         Informational - Expires Aug. 2003                18
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration


11 References

      [1] R. Droms, "Dynamic host configuration protocol," Request for
      Comments (Draft Standard) 2131, Internet Engineering Task Force,
      Mar. 1997.

      [2] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
      extensions," Request for Comments (Draft Standard) 2132, Internet
      Engineering Task Force, Mar. 1997.

      [3] H.Schulzrinne , ôDynamic Host Configuration Protocol (DHCP-
      for-IPv4)ö, Request for Comments (Draft Standard) 3361, Internet
      Engineering Task Force, Aug. 2002.

      [4] S. Bradner, "Key words for use in RFCs to indicate
      requirement levels," Request for Comments (Best Current Practice)
      2119, Internet Engineering Task Force, Mar. 1997.

      [5] A. Gulbrandsen, P. Vixie, and L. Esibov, ôA DNS RR for
      specifying the location of services (DNS SRV),ö Request for
      Comments 2782, Internet Engineering Task Force, Feb. 2000.

      [6] Rosenberg, et. al., ôSIP: session initiation protocol,ö
      Request for Comments 3261, Internet Engineering Task Force, June
      2002

      [7] A. Roach, ôEvent Notification in SIPö, Request for Comments
      3265, Internet Engineering Task Force, June 2002

      [8] D. Crocker, ôSTANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
      MESSAGESö, Request for Comments 822, Internet Engineering Task
      Force, Aug. 1982

      [9] K. Sollins, ôTHE TFTP PROTOCOL (REVISION 2)ö, Request for
      Comments 1350, Internet Engineering Task Force, Jul. 1992

      [10] H Schulzrinne, ôConfiguring IP Telephony End Systemsö,
      <schulzrinne-sip-config-00.txt>, IETF; Dec. 2000,  Work in
      progress

      [11] D. Petrie, ôRequirements for a SIP User Agent Configuration
      Frameworkö, <draft-ietf-sip-config-framewk-reqs-00.txt>, IETF;
      Feb. 2003, Work in progress

      [12] T. Berners-Lee et al, ôUniform Resource Locators (URL)ö,
      Request for Comments 1738, Internet Engineering Task Force, Dec.
      1994

      [13] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818,
      Internet Engineering Task Force, May 2000


   Petrie         Informational - Expires Aug. 2003                19
                         A Framework for SIP                Feb. 2003
                       User Agent Configuration

      [14] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request
      for Comments 2246, Internet Engineering Task Force, Jan. 1999

      [15] S. Olson ôA Mechanism for Content Indirection in Session
      Initiation Protocol (SIP) Messagesö, <draft-ietf-sip-content-
      indirect-mech-01>, IETF; Nov. 2002, Work in progress

      [16] H. Sinnreich, ôSIP Telephony Device Requirements,
      Configuration and Dataö, <draft-sinnreich-sipdev-req-00.txt>,
      IETF; Nov. 2002, Work in progress


      [10] H Schulzrinne, ôConfiguring IP Telephony End Systemsö,
      <schulzrinne-sip-config-00.txt>, IETF; Dec. 2000,  Work in
      progress

      [11] D. Petrie, ôRequirements for a SIP User Agent Configuration
      Frameworkö, <draft-petrie-sip-config-framewk-reqs-00.txt>, IETF;
      Feb. 2001, Work in progress

      [12] T. Berners-Lee et al, ôUniform Resource Locators (URL)ö,
      Request for Comments 1738, Internet Engineering Task Force, Dec.
      1994

      [13] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818,
      Internet Engineering Task Force, May 2000

      [14] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request
      for Comments 2246, Internet Engineering Task Force, Jan. 1999

      [15] S. Olson ôA Mechanism for Content Indirection in Session
      Initiation Protocol (SIP) Messagesö, <draft-ietf-sip-content-
      indirect-mech-01>, IETF; Nov. 2002, Work in progress




12 Author's Address

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




   Petrie         Informational - Expires Aug. 2003                20


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/