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.
00:d0:1e:00:1a:0e
à
à
NORTH AMERICAAmerica/Los_Angeles"PST"10.1.1.1US:English
à
à
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
5060506010030010.1.1.110.1.1.180
Stredicke, Butcher Informational - February 2002 18
4.4.1.2 Address Completion
91XXXXXXXXsip:{digits}@provider1proxy.provider1:port011X*sip:internation
4.4.1.3 Audio
4.4.1.4 Line default settings
10.1.1.1
4.4.1.5 Line definition (device)
Pingtel.comanon
Stredicke, Butcher Informational - February 2002 19
password232sip:admin@acme.com
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
10.1.1.110.1.1.2
4.4.2.2 Line definition (user)
<Fred Bloggs>sip:fbloggs@Pingtel.comPingtel.comfredbabdc342RRe
provider1.comfredbloggsbdc42jjRe
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," , 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", , 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",
, IETF; November 2001.
Work in progress.
[8] R. Mahy, I. Slain, ôSIP Event Package for Message Waiting
Indicationö, , 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ö, , IETF,
2001.
[11] H. Alvestrand ôTags for the Identification of Languagesö,
, 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