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

Versions: 00                                                            
                                                       C. Stredicke
   Internet Draft                                      snom AG
   Document: draft-stredicke-sipping-ep-config-00.txt  I. Butcher
   Expires: August 2002                               Pingtel Corp.
                                                       February 2002


                  SIP End Point Configuration Data Format


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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   Mass deployment of SIP compliant devices requires a simple mechanism
   for configuring and maintaining them. For the economical success of
   SIP based devices on a large scale, a platform independent mechanism
   for finding and exchanging the required information is vital. The
   goal of this draft is to reduce the amount of effort required for
   administrators to provision devices. This draft focuses on defining
   a common data set to configure SIP end points. The mechanism for
   providing and maintaining the configuration data to the end point is
   defined elsewhere [7].

   This Internet draft is a sub-package to SIP-Specific Event
   Notification [2].








   Stredicke, Butcher Informational - February 2002                  1




Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1  Overview.......................................................4
   2  Conventions used in this document..............................4
   3  Configuration Setting Content Requirements.....................4
   3.1  Device settings..............................................5
   3.1.1 Device ID...................................................5
   3.1.2 Proxy and Registration Settings.............................6
   3.1.2.1 SIP Session Timer.........................................6
   3.1.3 Network Related Settings....................................6
   3.1.3.1 SIP Ports.................................................6
   3.1.3.2 Type of Service...........................................6
   3.1.3.2 Network parameters........................................6
   3.1.3.3............................................................6
   3.1.3.4 RTP Port range............................................7
   3.1.3.5 External Network Address..................................7
   3.1.3.6 HTTP Outbound proxy.......................................7
   3.1.4 Line default settings.......................................7
   3.1.4.1 Registration period.......................................7
   3.1.4.2 Call handling.............................................7
   3.1.4.3 Outbound Proxy............................................8
   3.1.4.4 Default outbound line.....................................8
   3.1.5 Address Completion..........................................8
   3.1.5.1 Dial Plan.................................................8
   3.1.5.2 Default digit map.........................................8
   3.1.5.3 Overlap-Dial..............................................9
   3.1.5 Audio.......................................................9
   3.1.6..............................................................9
   3.1.6.1 Codecs....................................................9
   3.1.6.2 DTMF method...............................................9
   3.1.6.3 Silence suppression.......................................9
   3.1.7 Locale......................................................9
   3.1.7.1 Daylight savings rule and time zone.......................9
   3.1.7.2 Time server..............................................10
   3.1.7.3 Language.................................................10
   3.1.8 Inbound authentication.....................................10
   3.1.8.1 Authentication enabled...................................10
   3.1.8.2 Allowed Users............................................10
   3.2  User settings...............................................11
   3.2.1 User ID....................................................11
   3.2.2 Voice mail settings........................................11
   3.2.2.1 Message Waiting Indicator (MWI) address..................11
   3.2.2.2 Retrieve address.........................................12
   3.2.2.3 Deposit Address..........................................12

   Stredicke, Butcher Informational - February 2002                  2



   3.2.3 Phonebook and Call History.................................12
   3.2.3.1 Servers..................................................12
   3.2.4 Ringer behavior............................................12
   3.2.5 Ringer types...............................................12
   3.3  Line Related Settings.......................................13
   3.3.1 Line Identification........................................13
   3.3.2 Registration period........................................13
   3.3.3 Call handling..............................................13
   3.3.3.1 Maximum connections......................................14
   3.3.3.2 Available Behavior.......................................14
   3.3.3.3 Busy Behavior............................................14
   4  Configuration Detail Representation...........................16
   4.1  Requirements................................................16
   4.2  Proposed format.............................................16
   4.3  Format Definition...........................................17
   4.3.1 Handling Of Unrecognized Element Names.....................18
   4.4  Example XML.................................................18
   4.4.1 Device settings............................................18
   4.4.1.1 Network Settings.........................................18
   4.4.1.2 Address Completion.......................................19
   4.4.1.3 Audio....................................................19
   4.4.1.4 Line default settings....................................19
   4.4.1.5 Line definition (device).................................19
   4.4.2 User settings..............................................20
   4.4.2.1 Voice mail settings......................................20
   4.4.2.2 Line definition (user)...................................20
   4.5  Grammar.....................................................21
   5  IANA Considerations...........................................21
   5.1  SIP Event Package Registration for configuration............21
   5.2  MIME Registration for application/sip-endpoint-configuration 21
   6  Security......................................................22
   7  Open issues...................................................22
   8  References....................................................24
   9  Acknowledgements..............................................25
   10 Author's Addresses............................................25














   Stredicke, Butcher Informational - February 2002                  3



1  Overview

   Popular networks like GSM and CDMA have shown that maintenance and
   installation costs may make up a significant part of the total cost
   of ownership of a network device. For the economical success of SIP
   based devices on a large scale, a platform independent mechanism for
   finding and exchanging the required information is vital. This
   allows operators to offer their services to a large number of
   different devices without caring about the specifics of the actual
   device.

   The goal of this draft is to reduce the amount of effort required
   for administrators to provision devices.   Having a core set of
   configuration settings may allow plug-and-play type installation for
   the basic operations of a device. This would mean that users of
   those devices would not have to perform manual interaction with them
   to use basic services.

   While this draft defines the content of the configuration
   information, the exchange of the information (via http, tftp or
   other) is described in "A Framework for SIP User Agent
   Configuration" [7].   The term end point and device are used
   interchangeably in this draft but mean either a SIP telephone, SIP
   soft phone or SIP adapter (IAD).


2  Conventions used in this document

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]
   and indicate requirement levels for
   compliant SIP guidelines implementations


3  Configuration Setting Content Requirements

   Settings are the information on a client that it needs to be a
   functional SIP end point. It is an implementation choice whether the
   device stores the data across power cycles and hardware restarts or
   it reloads the data every time upon startup. The configuration
   framework [7] supports either approach. The settings defined in this
   document are not intended to be all inclusive. It MUST be possible
   for vendor specific parameters to be added. Parameters which are not
   understood by an end point MUST be ignored.

   Configuration information related to the network identity of
   a device that can be discovered through other network protocols are
   not part of the configuration settings described in this document.
   Typical network identity configuration settings are IP address,
   netmask, IP gateway, DNS servers, host name, and domain. This
   information MAY be discovered through DHCP or defined via manual
   provisioning.

   Stredicke, Butcher Informational - February 2002                  4




   The list of available configuration settings includes settings that
   MUST, SHOULD or MAY be used by all devices (when present) and that
   make up the common denominator that is used and understood by all
   devices. However, the list is open to vendor specific extensions
   that support additional settings, which enable a rich and valuable
   set of features.

   Settings MAY be read-only on the device. This avoids the miss-
   configuration of important settings by inexperienced users producing
   service cost for operators. This draft describes how operator MAY
   protect some settings from end users.

   In order to achieve wide adoption of any configuration settings
   format it is important that it not be excessive in size so as to
   allow modest devices to use it. Any format should be structured
   enough to allow elegant extensions to it by vendors.

   A distinction made in this document is that settings pertain to
   devices, users or occasionally both. This separation of device and
   user is an important concept. A specific user is not always
   associated with a specific device. The separation allows user
   mobility from device to device. Certain network settings such as the
   default SIP port number and list of available codecs inherently
   belong to devices. Settings like registry servers and voice mail
   forwarding configuration belong to users. User mobility across
   devices and the ability to reassign users to different devices is
   provided through a means outside the scope of this document (see
   [7]).

   An end point typically has at least one address-of-record [9] for
   which it accepts SIP requests. In this document the address-of-
   record is said to represent an identity or line. A single user of an
   end point may have multiple lines.

   Line definitions can be associated with either devices or users.
   Devices may maintain their own line definition associated with the
   serial number, MAC address, physical location or an extension
   number. Users may have zero or more lines defined with a variety of
   addresses and identities (user name, extension number, sales
   associate, etc.).

   In order to ease definition of lines a group of settings for default
   line definition settings is provided.  If a device or line
   definition does not provide a particular setting then the device
   SHOULD use the equivalent setting in the device line default
   settings if it exists.


3.1 Device settings

3.1.1   Device ID


   Stredicke, Butcher Informational - February 2002                  5



   A deviceÆs settings MAY include some unique identifier for the
   device it represents.  This may be the MAC address, some
   manufacturer serial number or some other unique piece of data.

3.1.2   Proxy and Registration Settings


3.1.2.1 SIP Session Timer

   The re-invite timer allows user agents to detect broken sessions
   caused by network failures. A value indicating the number of seconds
   for the next re-invite for the re-invite period SHOULD be used by
   the device.

3.1.3   Network Related Settings


3.1.3.1 SIP Ports

   The port that MUST be used for a specific transport protocol MAY be
   indicated with the SIP ports setting.


3.1.3.2 Type of Service

   The Type of Service settings for outbound packets SHOULD be
   configurable for network packets associated with call signalling
   (SIP) and media transport (RTP/RTCP).

   For both categories of network traffic, the device SHOULD permit
   configuration of the type of service settings for both layer 3 (IP
   DiffServ) [16] and layer 2 (IEEE 802.1D/Q) [17, 18] of the
   networking stack.

   [Open issue: Should a device support more than one group of TOS
   settings for media transport?  For example, a device might be
   configured for three different levels of service (e.g., Gold, Silver
   and Bronze).  On a per call basis, the device user interface MAY
   permit the user to request which of the three level of service to
   use for media transport in that call.]

   [Open issue: Should the type of service be configurable based on
   codec type?  For example, G.711 will use one set of TOS settings,
   G.729A will use a different set of TOS settings.]

3.1.3.3 Network parameters

   The parameters for SIP (like timer T1 [9]) and other network related
   settings MAY be indicated.



   Stredicke, Butcher Informational - February 2002                  6



3.1.3.4 RTP Port range

   A range of port numbers MAY be used by a device for the consecutive
   pairs of ports which should be used to receive audio and control
   information (RTP and RCTP) for each concurrent connection.


3.1.3.5 External Network Address

   A network address (such as an IP address) MAY be used by devices
   which make calls through a NAT. The device includes this IP address
   in the SIP messages and SDP it sends to other SIP user agents to
   indicate that this is the address to which SIP, RTP and RTCP packets
   should be send. This supports the case where the NAT is configured
   to statically map specific ports on the external interface to a
   specific end point inside the NAT. The end point in turn is
   configured to spoof other SIP entities into thinking it is the
   external interface on the NAT.

   The address consists of a host name plus an optional port number,
   like sent-by in the Via header [9].


3.1.3.6 HTTP Outbound proxy

   An outbound HTTP proxy server IP address and port number MAY be used
   in cases where the device both supports an HTTP client and requires
   HTTP traffic to use a proxy server.


3.1.4   Line default settings

   Default values which are used in cases where explicit values are not
   set on line definitions MAY be specified.   This provides a
   mechanism for factoring out line definition settings.   Not all line
   definition settings can be defaulted some such as identification are
   inherently bound to an individual line.


3.1.4.1 Registration period

   A line definition MAY contain a period (in seconds) which once
   exceeded will cause the device to re-register its registration
   server(s).

3.1.4.2 Call handling

   All of the call handling settings defined below (section 3.3.2) can
   be defined here as default behaviors.



   Stredicke, Butcher Informational - February 2002                  7



3.1.4.3 Outbound Proxy

   The outbound proxy [9] for a line or for a device MAY be set. The
   address is encoded as SIP URI. The setting MAY contain alternative
   outbound proxies, which MAY be used in case of a server failure.


3.1.4.4 Default outbound line

   The default outbound line SHOULD be a global setting (not related to
   a specific line). This setting MUST not be used as part of a line
   definition.



3.1.5   Address Completion

   As most telephone users are used to dialing digits to indicate the
   address of the destination, there is a need for specifying the rule
   by which digits are transformed into a URL (usually SIP or TEL).


3.1.5.1 Dial Plan

   A dial plan which defines the maximum expected length of a typical
   telephone number SHOULD be used.

   Zero or more digit maps which map a dial plan and a SIP address to
   which phone numbers of that type should be routed SHOULD be
   supported. The digit maps define numeric patterns that when matched
   define: 1) a rule by which the end point can judge that the user has
   completed dialing and 2) a rule to construct a URL from the dialed
   digits and optionally 3) an outbound proxy to used in routing the
   SIP INVITE.

   [Open issue: Is there a standard for describing a dial plan? If yes,
   reference it, if no, describe the syntax.]

   A critical timer MAY be provided which determines how long the
   device should wait before dialing if a dial plan contains a ôTö
   character. It MAY also provide a timer for the maximum elapsed time
   which should be waited before dialing if the digits entered by the
   user match no dial plan.


3.1.5.2 Default digit map

   The end point MUST support the configuration of a default digit map.
   If the end point does not support digit maps it minimally must
   support a default digit map rule to construct a URL from digits. If


   Stredicke, Butcher Informational - February 2002                  8



   the end point does support digit maps, this rule applies if none of
   the digit maps match.


3.1.5.3 Overlap-Dial

   Some operators support overlap dialing [4] and MAY want to indicate
   to the SIP devices that this mode is to be used. This setting is
   Boolean and may be set to ôtrueö or ôfalseö.


3.1.6   Audio

3.1.6.1 Codecs

   In many cases operators want to control which codecs may be used in
   their network. The desired subset of codecs supported by the device
   MUST be configurable along with order of preference.

   The range for parameters of the codecs MUST be adjustable. This
   includes the packet length (msecs of audio), and the sample rate.
   However, the negotiation of the media for a calls is being done on a
   per call basis.


3.1.6.2 DTMF method

   DTMF allows different ways of indicating that a key has been pressed
   [14, 15]. The method for sending these events SHOULD be configurable
   with the order of precedence.


3.1.6.3 Silence suppression

   It SHOULD be possible to disable silence suppression on the end
   point such that RTP audio packets are sent even if silence is
   detected.


3.1.7   Locale

   Certain settings are dependant upon the devices regional location.


3.1.7.1 Daylight savings rule and time zone

   Different rules exist for when daylight saving time (DST) starts and
   ends. For example in North America begins on the first Sunday in
   April whereas in Western Europe is begins on the last Sunday in
   March. A DST rule MAY be used by the device.


   Stredicke, Butcher Informational - February 2002                  9



   An offset from Coordinated Universal Time (UTC) in seconds MAY be
   used.   A timzeone MAY be specified for the user.  Where one is
   specified it SHOULD use the scheme used by the Olson Time Zone
   database [12].   Examples of the database naming scheme are
   ôAsia/Dubaiö or ôAmerica/Los_Angelesö where the first part of the
   name is the continent or ocean and the second part is normally the
   largest city on that timezone.


3.1.7.2 Time server

   The network addresses of SNTP time servers where the device can get
   a centrally defined time MAY be used.


3.1.7.3 Language

   Setting the correct language is important for simple installation
   around the globe. A language MAY be specified for a device.   Where
   it is specified it SHOULD use the codes defined in RFC3066 [11] to
   provide some predictability.

   It is RECOMMENDED that servers set the Language as writable, so that
   the user may change this. This setting SHOULD NOT be line related.


3.1.8   Inbound authentication

   SIP allows a device to limit incoming signaling to those made by a
   predefined set of authorized users with valid passwords.


3.1.8.1 Authentication enabled

   A device SHOULD the setting as to whether authentication (on the
   device) is required and what type of authentication is required :
   NONE or DIGEST


3.1.8.2 Allowed Users

   If inbound authentication is enabled then a list of users and
   credentials which are allowed to call this device SHOULD be used by
   the device. The credentials contain the same data as the credentials
   for a line (i.e. URL, user, password digest and realm).

   This applies to SIP control signaling as well as call initiation.
   For example who is allowed to send a REFER or an INVITE with the
   Join or Replaces header.



   Stredicke, Butcher Informational - February 2002                 10



3.2 User settings

3.2.1   User ID

   A device MAY specify the user which is currently registered on the
   device.   This SHOULD be an address-of-record URL specified in a
   line definition.

   The purpose of specifying which user is currently assigned to this
   device is to provide the device with the identity of the user whose
   settings are defined in the user section.    This is primarily
   interesting with regards to user roaming.   Devices may allow users
   to sign-on to them and then request that their particular settings
   retrieved [7].   Likewise a user may stop using a device
   and want to disable their lines while not present.  For the device
   to understand what to do it must have some way of identifying users
   and knowing which user is currently using it.  By separating the
   user and device properties it becomes clear what the user wishes to
   enable or disable.

   Providing an identifier in the configuration for the user gives an
   explicit handle for the user.   For this to work the device must
   have some way of identifying users and knowing which user is
   currently assigned to it.

   One possible scenario for roaming is an administrator who has
   definitions for several lines (e.g. one or more personal lines and
   one for each executive for whom the administrator takes calls) that
   they are registered for.   If the administrator goes to the copy
   room they would sign-on to a device in that room and their user
   settings (including their lines) would roam with them.   The
   alternative to this is to require the administrator to individually
   configure all of the lines individually (which would be particularly
   irksome using standard telephone button entry).

   The management of user profiles, aggregation of user or device lines
   and profile information from multiple management sources are
   configuration server concerns which are out of the scope of this
   document (see [7]).  However the ability to uniquely identify the
   device and user within the configuration data enables easier server
   based as well as local (i.e. on the device) configuration management
   of the configuration data.


3.2.2   Voice mail settings


3.2.2.1 Message Waiting Indicator (MWI) address

   The MWI address setting controls where the client MAY SUBSCRIBE [8]
   to a voice mail server.


   Stredicke, Butcher Informational - February 2002                 11



3.2.2.2 Retrieve address

   An address MAY be used by the device so it can get any voicemail
   messages it has.


3.2.2.3 Deposit Address

   An address MAY be used to specify where voicemail messages should be
   left if the device is unable or unwilling to take a call.

3.2.3   Phonebook and Call History

   Phonebook directory servers can provide a centralized store of phone
   numbers/addresses and potentially other information. A common
   example being LDAP directory servers.  DeviceÆs call history, a
   record of the last calls made and received may also be stored in a
   centralized location and referenced from devices.

   If the phone maintains only one last dialed number, it should
   compare incoming Last-Calls header against tried and dialed and
   store the newest entry.

   Devices that are not able to differentiate call history entries
   between "tried" and "dialed" SHOULD use "dialed".


3.2.3.1 Servers

   Zero or more servers MAY be used for storing phonebook directories
   or call histories. If a server is defined and address such as a URL
   MUST be used and user name and credentials MAY be used for that
   server.

   A server MAY be used for storing the phonebook and call history. The
   flush timeout MAY be specified for the server.

   Users MAY wish to limit the number of data items that are returned
   to their device if a query is issued against one of the directory
   servers.

3.2.4   Ringer behavior

   The manner in which a user is alerted to an incoming call (visually,
   audibly or possibly both) MAY be used by the device. This includes
   the different volumes and MAY point to a file that contains the
   melody.


3.2.5   Ringer types



   Stredicke, Butcher Informational - February 2002                 12



   Ringer sound files MAY be specified for the following types of
   incoming calls normal, high priority, internal and external.


3.3 Line Related Settings

   Many SIP devices support only one identity. These devices should
   ignore all line related settings that do no affect the default
   outbound line settings they receive.

   Phones SHOULD maintain read access information on a per line basis.
   If this is not possible, phones SHOULD mix the permissions on a
   common denominator basis, that means if one of the settings is read
   only, all settings are read only.


3.3.1   Line Identification

   A line represents an address-of-record [9] identified by a URL.
   There are many properties which may be associated with or should be
   applied to the line or signaling addressed to or from the line.
   Lines may be defined for a device or a user of the device. At least
   one line MUST be defined in the configuration settings, this may
   pertain to either the device itself or the user.

   A line MUST provide a address or record URL which both distinguishes
   the line and provides the URL which optionally will be registered
   for the line. A user friendly display name SHOULD be taken from the
   address-or-record URL for the line.

   A line definition MUST specify whether the line should automatically
   register with a registration server. It MUST be possible to specify
   at least one set of realm, user name and authentication credentials
   for each line. The user name and authentication credentials are used
   upon authentication challenges [9].

   A line definition MUST use call handling settings and the state of
   the phone to determine how to handle inbound calls. Inbound calls
   may be rejected, redirected, or accepted.




3.3.2   Registration period

   A line definition MAY contain a period (in seconds) which once
   exceeded will cause the device to re-register its registration
   server(s).


3.3.3   Call handling



   Stredicke, Butcher Informational - February 2002                 13



   Call Handling settings define how the phone reacts to a new incoming
   call given different situations. In some cases, an end user may want
   to redirect calls to another party, rejected the call, or accepted
   the call and alert the end user. Some settings tend to be change
   irregularly like their voicemail forwarding address while others
   settings such as the do not disturb state may change often.


3.3.3.1 Maximum connections

   A setting defining the maximum number of simultaneous connections
   that a device can support MUST be used by the device. Obviously the
   end point has some maximum limit, however this allows the limit to
   be set to a lower number.


3.3.3.2 Available Behavior

   The Available Behavior defines how a new call is handled when the
   phone is not actively engaged in a call or when Call Waiting is
   enabled. Options include RING (ôringö) and FORWARD_ON_NO_ANSWER
   (ôforwardö). A setting of RING alerts the user (as defined by the
   Ringer Behavior in 3.2.3) for a practical length of time before
   returning an error response to the caller if not answered.
   FORWARD_ON_NO_ANSWER should alert the user for a configured amount
   of time (Forward on No Answer Timeout) and if not answered, forward
   to the Forward on No Answer address. All end points MUST use an
   available behavior setting.

   The Forward on No Answer setting identifies the address forwarded to
   after an alerting call exceeds the Forward On No Answer Timeout
   period. End points MUST use this parameter if the available behavior
   is set to FORWARD ON NO ANSWER and MAY define this parameter
   otherwise.

   The Forward on No Answer Timeout defines the length of time that a
   user should be alerted for before the call is automatically redirect
   to the Forward on no answer SIP URL. This parameter is specified in
   seconds, where approximately 4 seconds is equivalent to a ring. End
   points MUST use this parameter if the available behavior is set to
   FORWARD ON NO ANSWER and MAY define this parameter otherwise.


3.3.3.3 Busy Behavior

   The Busy Behavior defines how a new call is handled when the phone
   is engaged in an active call and call waiting is disabled or when
   the phone has reached the maximum number of connections.   Options
   include BUSY and FORWARD. A BUSY setting instructs the phone to
   respond with a 486/Busy here. A FORWARD setting redirects the caller



   Stredicke, Butcher Informational - February 2002                 14



   to the Forward on Busy Address. All end points MUST use a busy
   behavior setting.

   The Forward on Busy SIP URL setting identifies the address forwarded
   to when the end point is busy. The end point is considered busy if a
   call is active and call waiting is disabled and when the phone has
   reached the maximum number of simultaneous connections. Since this
   parameter is dependant on the busy behavior, end points MUST define
   this setting if the BUSY behavior is set to FORWARD and MAY define
   this setting otherwise.


3.3.3.3.1       Call Waiting Behavior

   Call Waiting controls the behavior of new calls when an existing
   call is already active and the device has not met the maximum number
   of connections. Options include ALERT and BUSY, where ALERT will
   alert the user as defined by the Ringing behavior and Available
   Behavior and BUSY will follow the busy behavior logic. All end
   points MUST use a call waiting behavior setting.


3.3.3.3.2       Unconditional Forwarding

   The Unconditional Forwarding setting allows end users or
   administrators to forward all inbound calls to a designated
   Unconditional Forwarding SIP URL. This is useful if one wants to
   temporarily redirect all calls to another end point and
   administrative access to the directory servers is unavailable.
   Options include ENABLE and DISABLE, where ENABLE indicates that all
   inbound calls will be redirected and DISABLE indicates that all
   inbound calls will be treated as specified by the available, busy,
   and call waiting behaviors. All end points MUST use unconditional
   forwarding.

   The Unconditional Forwarding SIP URL identifies the address that
   inbound calls are redirected to if Unconditional Forwarding is
   enabled. All end points MUST use the unconditional forwarding
   address if unconditional forwarding is enabled, otherwise they MAY
   use it.


3.3.3.3.3       Do Not Disturb

   The Do Not Disturb settings enables end users to quickly and easily
   enable and disable inbound calls for a particular line. Options
   include ENABLE and DISABLE, where ENABLE will handle a call as
   indicated by the Do Not Disturb Method and DISABLE allows normal
   call handling. This setting MUST be used by all end points.




   Stredicke, Butcher Informational - February 2002                 15



   This setting may seem redundant to other the parameters defined
   within call handling, however, it addresses both an end user need
   along with administrative requirements. In some configurations, an
   end point may be configured to return a BUSY response to an inbound
   call so that a user agent within the network can try another party.
   The same results are required for Do Not Disturb.

   Do Not Disturb Method MUST be able to support multiple methods of
   rejecting calls. Options include BUSY, FORWARD_ON_BUSY, and
   FORWARD_ON_NO_ANSWER. A setting of BUSY will return a BUSY response
   so that other network user agents can redirect the call as needed.
   FORWARD_ON_BUSY will redirect the call to the FORWARD_ON_BUSY SIP
   URL and FORWARD_ON_NO_ANSWER will for privacy reasons allow the
   caller to believe the call is alerting before forwarding to the
   Forward on No Answer SIP URL.


4  Configuration Detail Representation

   The section describes the requirements and format for an
   implementation of the settings described in section 3.

4.1 Requirements

   From reading section 3 it is apparent that many of the settings are
   composite and related.   As the number and complexity of the
   settings grows it is useful from and administration point of view to
   be able to easily relate settings.

   This document recognizes that as features increase on devices so
   will the amount of settings. Any format proposed should be readily
   and intuitively extensible.


4.2 Proposed format

   This document proposes using XML as the file format for the
   configuration settings primarily for the reasons stated above.   XML
   naturally maps the settings defined in section 3.   Line-oriented
   formats such as RFC822 were also considered.   XML is considered
   preferable in this instance primarily because line orientated
   formats tend to rely on clever naming to relate related settings.
   For example:

   Line.1.URL = sip:ibutcher@Pingtel.com
   Line.1.Realm.Pingtel.user = ibutcher
   Line.1.Realm.Pingtel.password = foobar
   Line.1.Realm.anyrealm.user = anyuser
   Line.1.Realm.anyrealm.password = anypass


   Line-oriented formats tend not to require any ordering of the lines
   that they contain.   In the example of the line definition above the

   Stredicke, Butcher Informational - February 2002                 16



   individual lines need not be in the logical order shown.   They
   could have all the URLs, passwords, etc. for all the lines together
   or even have the line definitions dispersed throughout the file.

   XML namespaces are a useful tool when processing documents which may
   contain elements from more than one source.   The default namespace
   for any XML document using the definitions described in this
   document MUST define the default namespace in the root node with URL
   [open issue this URL isnÆt that significant do we need to provide an
   IETF specific one http://XXX].   Vendors may add their own content
   within the XML document but MUST provide qualified names with their
   own namespace.

   The general format for the XML is to have device and user elements
   as direct children of the root node.   Those elements will contain
   all of the appropriate settings describe in section 3.

   An example of an extension to the timezone setting is show below.


   <settings xmlnshttp://someurl
   xmlns:acme=öhttp://amce.comö>
        <device>
           <id>00:d0:1e:00:1a:0e</id>
           à
           à

           <locale>
                <dstrule>NORTH AMERICA</dstrule>
                <timezone>America/Los_Angeles</timezone>
                <!-- vendor extension -->
                <acme:timezonedisplay>"PST"</acme:timezonedisplay >

                <timeserver>10.1.1.1</timeserver>
                <language>US:English</language>
           </locale>
           à
           à

        </device>

        <user/>
   </settings>

4.3 Format Definition

   The definitions of the elements and attributes will not be included
   in this version of the draft. Examples follow to illustrate some
   concepts of the format. A future version of this draft will expand
   upon and define the semantics of the elements and tags. Section 3
   defines the requirements from which the XML elements and attributes
   will be derived.


   Stredicke, Butcher Informational - February 2002                 17



4.3.1   Handling Of Unrecognized Element Names

   [Stolen from draft-ietf-impp-cpim-pidf-01.txt, should give
   reference]

   The default rule is that any element with an unrecognized name is
   ignored (i.e. having an unrecognized namespace URI, or an
   unrecognized local name within that namespace). This includes all of
   the element content, even if it appears to use recognized names.



4.4 Example XML

   This section aims to provide some samples of the settings defined in
   section 3.   A complete grammar/schema definition is not provided at
   this point.


4.4.1   Device settings

4.4.1.1 Network Settings

   <network>

        <tcp>
                <port>5060</port>
        </tcp>

        <udp>
                <port>5060</port>
        </udp>

        <rtp>
                <ports>100</ports>
        </rtp>

        <dhcpLease>300</dhcpLease>

        <externalIpAddress>10.1.1.1</externalIpAddress>

        <httpOutboundProxy>
                <ipAddress>10.1.1.1</ipAddress>
                <port>80</port>
        </httpOutboundProxy>

        <ethnetDuplex value="full"/>

   </network>




   Stredicke, Butcher Informational - February 2002                 18



4.4.1.2 Address Completion

   <addressCompletion>
        <dialplan length="10"/>
        <digitmap>
                <pattern>91XXXXXXXX</pattern>
                <targetAddress>sip:{digits}@provider1</targetAddress>
                <outboundProxy>proxy.provider1:port</outboundProxy>
        </digitmap>
        <digitmap>
                <pattern>011X*</pattern>
                <targetAddress>sip:internation</targetAddress>
        </digitmap>
   </addressCompletion>




4.4.1.3 Audio

   <audio>
        <codecs>
                <codec priority="1">G729</codec>
                <codec priority="3">G711</codec>
                <codec priority="2">aLAW</codec>
        </codecs>
   </audio>



4.4.1.4 Line default settings

   <lineDefaults>
        <outboundProxy>10.1.1.1</outboundProxy>
        <callHandling>
                <busy behavior=öbusyö/>
                <callWaiting behavior=öbusyö/>
        </callHandling>
   </lineDefaults>



4.4.1.5 Line definition (device)

   <line aor-url=ö&lt;Extension 123&gt;sip:1234@Pingtel.comö
   register=öprovisionö>
        <credential>
                <realm>Pingtel.com</realm>
                <userId>anon</userId>


   Stredicke, Butcher Informational - February 2002                 19



                <passToken>password</passToken>
        <credential>
        <callHandling>
                <maxConnections>2</maxConnections>
                <available behavior=öforward-no-answerö>
                        <seconds>32<seconds>
                        <url>sip:admin@acme.com</url>
                </available>
        </callHandling>
   </line>


   In this example the outbound proxy and call handling settings
   defined in the line default settings example SHOULD be used in
   addition to the line definition.


4.4.2   User settings


4.4.2.1 Voice mail settings

   <voicemail>
        <mwi>10.1.1.1</mwi>
        <retrieve>10.1.1.2</retrieve>
   </voicemail>


4.4.2.2 Line definition (user)

   <user>
        <id>&lt;Fred Bloggs&gt;sip:fbloggs@Pingtel.com</id>

        <line aor-url=ö&lt;Fred Bloggs&gt;sip:fbloggs@Pingtel.comö
        register=öregisterö>
                <credential>
                        <realm>Pingtel.com</realm>
                        <userId>fredb</userId>
                        <passToken>abdc342RRe</passYoken>
                <credential>
                <credential>
                        <realm>provider1.com</realm>
                        <userId>fredbloggs</userId>
                        <passToken>bdc42jjRe</passToken>
                <credential>

                <callHandling>
                        <available behavior=öbusyö/>
                </callHandling>
        </line>

   </user>

   Stredicke, Butcher Informational - February 2002                 20





   Credentials are supplied for two realms in this example.   In this
   example the outbound proxy and call handling settings defined in the
   line default settings example SHOULD be used in addition to the line
   definition.


4.5 Grammar


   [Open issue: how should define this, DTD, XML Schema, WSDL ?   To be
   filled in for next version of the draft]


5  IANA Considerations

5.1 SIP Event Package Registration for configuration

   Package name: configuration

   Type: package

   Contact: [Stredicke]

   Published Specification: This document


5.2 MIME Registration for application/sip-endpoint-configuration

   MIME media type name: application

   MIME subtype name: sip-endpoint-configuration

   Required parameters: none.

   Optional parameters: none.

   Encoding considerations: See SIP [3] message header definition.

   Security considerations: See the "Security Considerations"
        (Section 6) section in this document.

   Interoperability considerations: none

   Published specification: This document.

   Applications which use this media: SIP configuration server and
        clients subscribing to these servers.

   Additional information:

    1. Magic number(s): N/A

   Stredicke, Butcher Informational - February 2002                 21




    2. File extension(s): N/A

    3. Macintosh file type code: N/A



6  Security

   Configuration MAY contain sensitive information that SHOULD be
   protected. Examples include authentication information, private
   address books and call history entries.   Because of this, it is
   RECOMMENDED to use an encrypted transport mechanism.   Where devices
   use http this could be TLS [6].  For devices which use ftp or tftp
   for content delivery this can be achieve using symmetric key
   encryption.

   Access to retrieving configuration information is also an important
   issue. Both configuration server and clients SHOULD be able to do
   Digest authentication. A configuration server [7] SHOULD challenge a
   subscriber before sending configuration information


7  Open issues

   [Open issue: Should a device support more than one group of TOS
   settings for media transport?  For example, a device might be
   configured for three different levels of service (e.g., Gold, Silver
   and Bronze).  On a per call basis, the device user interface MAY
   permit the user to request which of the three level of service to
   use for media transport in that call.]

   [Open issue: Should the type of service be configurable based on
   codec type?  For example, G.711 will use one set of TOS settings,
   G.729A will use a different set of TOS settings.]

   [open issue this URL isnÆt that significant do we need to provide an
   IETF specific one http://XXX]

   [Open issue: how should define this, DTD, XML Schema, WSDL ?   To be
   filled in for next version of the draft]

   [Open issue: Reference RFC2445 for daylight savings and other time
   related settings?]

   [Open issue: Does using this configuration schema automatically mean
   we use SIP as signaling protocol? If we open the proposal for H.323,
   MGCP and others, we get a better acceptance, but the number of
   settings will significantly increase.]

   [Open issue: Should we use a tag for referencing nested
   configuration resources? That would allow a flexible way of


   Stredicke, Butcher Informational - February 2002                 22



   providing multiple lines, multiple profiles, etc; however would add
   additional complexity. Current concept is more fixed, but simpler.]

   [Open issue: Should we propose a reload time for refreshing the
   configuration? The configuration framework proposes a push
   technology, however, in simple environments polling could make
   sense]

   [Open issue: Should this draft be informational, best current
   practices or standards track?]












































   Stredicke, Butcher Informational - February 2002                 23




8  References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [2] Adam Roach, "SIP-Specific Event Notification," <draft-ietf-sip-
   events-01.txt>, IETF; November 2001. Work in progress.

   [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [4] G. Camarillo, A. Roach, J. Peterson, L. Ong, "Mapping of ISUP
   Overlap Signalling to SIP", <draft-ietf-sip-overlap-01.txt>, IETF;
   August 2001. Work in progress.

   [5] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
   Request for Comments 2327, Internet Engineering Task Force, April
   1998

   [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
   for Comments 2246, Internet Engineering Task Force, Jan. 1999.

   [7] D. Petrie, "A Framework for SIP User Agent Configuration",
   <draft-petrie-sip-config-framework-01.txt>, IETF; November 2001.
   Work in progress.

   [8] R. Mahy, I. Slain, ôSIP Event Package for Message Waiting
   Indicationö, <draft-mahy-sip-message-waiting-02.txt>, IETF; July
   2001. Work in progress

   [9] Various Authors, ôSIP: Session Initiation Protocolö, draft-ietf-
   sip-rfc2543bis-07.txt, IETF; February 2002. Work in progress.

   [10] I. Slain ôConfiguration Parameters for IP Telephony End
   Systemsö, <draft-ietf-slain-sip-config-parameters-01.txt>, IETF,
   2001.

   [11] H. Alvestrand ôTags for the Identification of Languagesö,
   <rfc3066.txt_number=3066>, RFC 3066, Network Working Group, January
   2001.

   [12] P. Eggert, "Sources for time zone and daylight saving time
   data." Available at http://www.twinsun.com/tz/tz-link.htm.

   [13] Arango et al, ôMedia Gateway Control Protocolö, IETF, RFC 2705,
   October 1999.

   [14] S. Donovan, ôThe SIP INFO Methodö, IETF, RFC 2976, October
   2000.


   Stredicke, Butcher Informational - February 2002                 24



   [15] H. Schulzrinne, S. Petrack, äRTP Payload for DTMF Digits,
   Telephony Tones and Telephony Signalsö, IETF, RFC 2833, May 2000.

   [16] Nichols, K., Blake, S., Baker, F. and D. Black,
   "Definition of the Differentiated Services Field (DS Field) in the
   IPv4 and IPv6 Headers", RFC 2474, December 1998.

   [17] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition,
   Information technology - Telecommunications and information
   exchange between systems - Local and metropolitan area
   networks - Common specifications - Part 3: Media Access
   Control (MAC) Bridges

   [18] IEEE Std 802.1Q-1998, IEEE Standards for Local and
   Metropolitan Area Networks: Virtual Bridged Local Area
   Networks


9  Acknowledgements

   We would like to thank Bob Andreasen, Steven Lass, Dan Petrie, Henry
   Sinnreich, Henning Schulzrinne and Rich Schaaf for their input and
   review of this document. We would also like to thank Henry Sinnreich
   for his help in coordination of this effort.

   Illya SlainÆs Internet Draft [10] provided and excellent starting
   point for this work.



10 Author's Addresses

   Christian Stredicke
   snom technology AG
   Pascalstr. 10e               Phone: +49(30)39833-0
   10587 Berlin, Germany        Email:  cs@snom.de

   Ian Butcher
   Pingtel Corp.
   400 W. Cummings Park         Phone: +1 781 938 5306
   Woburn, MA USA               Email: ibutcher@pingtel.com













   Stredicke, Butcher Informational - February 2002                 25