\documentclass[11pt]{article}
\usepackage{times,graphics,ifthen,i-d,html,txtpsfig,tight}
\usepackage[dvips]{changebar}

\title{Configuring IP Telephony End Systems}
\author{Schulzrinne/Petrie}
\shorttitle{SIP-config}
\filename{schulzrinne-sip-config-01}
\wg{SIP WG}
\expires{June 2001}
\address{Columbia U./Pingtel}
\pubdate{\today}
%\input{rfc}
\input{../defs}

\begin{document}
\maketitle
\begin{abstract}
IP telephony devices are likely to be simple systems that are going to
be deployed in large numbers.  This document discusses alternatives for
configuring SIP-based IP telephony devices that is independent of the
vendor. The discussion includes both data structures and transport
mechanisms.
\end{abstract}

\section{Introduction}

SIP \cite{rfc2543} user agents need to be configured with a variety of
SIP- and application-related parameters.  In many environments,
thousands of such devices are likely to be deployed, thus making
automated configuration management a necessity.  Automating
configuration is particularly important for these devices since many are
likely to have only a limited user interface, such as a twelve-key
keypad and a two-line text display, making manual configuration tedious,
error-prone and time consuming.  These devices may also be severely
limited in their computational capabilities and protocol support.  Also,
devices are likely to have a limited amount of non-volatile memory. 
Thus, these devices are in many ways similar to the diskless
workstations that motivated the development of protocols like BOOTP and
DHCP.  However, unlike the environments envisioned in the
zero-configuration scenarios \cite{draft-ietf-zeroconf-reqts}, large
Internet telephony deployments generally have an existing infrastructure
of DHCP and other servers.

This draft does not discuss the configuration of SIP-based IP telephony
gateways or SIP proxy servers. Their number within an organization is
likely to be much smaller, so that manual configuration is less likely
to be an issue.

Here, we are not concerned with configuring basic IP information, such as 

\begin{itemize}
\item network address \item network mask, 
\item host name, 
\item DNS servers, 
\item time zone (DHCP 88)
\item time servers, or 
\item default routers. 
\end{itemize}
All of these are readily configured via DHCP \cite{rfc2131}.

Since these devices are similar to diskless workstations in the past, they
can also make use of the same mechanism (BOOTP and DHCP) to determine
the current boot image and then upload it via tftp.

Also, the SIP outbound proxy can be configured via SIP DHCP
\cite{draft-ietf-sip-dhcp}.

Configuration information can be roughly divided into four areas:  SIP
information, user interface, RTP and company-specific information.  Some
of this information is specific to a particular device or a particular
SIP user (labeled as ``ind.''), while other information is the same for
all devices in an organization (``org.'').

The user identity of a device can be permanent or temporary, e.g.,
established via some kind of token or keypad login.  For example, an IP
phone in a conference room may always have the SIP identity
\texttt{room453@acme.com}, but it may temporarily also assume the
identity \texttt{alice@acme.com} if Alice is using the conference room.

SIP information includes
\begin{tabular}{ll}
Value                                       & for\\
\hline
default \header{Route} destinations         & org.\\
values for \header{Organization} header     & org.\\
values for display name                     & ind.\\
request timeout parameters                  & org.\\
request initial retransmit interval         & org.\\
registration authentication secrets         & ind.\\
request authentication secrets              & ind.\\
voicemail forwarding SIP URLs for busy      & ind./org.\\
voicemail forwarding SIP URLs for no answer & ind./org.\\
no-answer ring durations before forwarding  & ind./org.\\
non-SIP \header{Contact} information        & ind./org.\\
911 configuration: PSAP                     & org.\\
911 configuration: location                 & ind.\\
ring tones, volume                          & ind.\\
\end{tabular}

Note that not all of this information needs to be configured in the end
system.  A script providing call handling information may subsume busy
and no-answer handling instructions.  An outgoing proxy may add
\header{Organization} headers.  Non-SIP URLs may be configured through a
non-SIP interface, such as a web page or database, accessible to the
registrar.

User information includes 
\begin{itemize}
\item the definition of speed-dial buttons;
\item call log (for callbacks);
\item user interface language.
\end{itemize}

RTP information includes 
\begin{itemize}
\item the default media to advertise,
\item the default audio or video codec,
\item the default packetization interval,
\item the use of silence suppression,
\item the use of audio sidetone,
\item the transmission of touch tones as either encoded waveforms or as
RFC 2833 \cite{rfc2833} payloads.
\end{itemize}

In addition, end systems may want to retrieve address books, either in
full or as updates to information available locally.  LDIF \cite{rfc2849}
appears to be sufficient for that purpose, although the transport
mechanism remains to be determined, with tftp and SIP (using TCP),
described below, as feasible options.

\section{Components}

\subsection{Discovery of Configuration Source}

Depending on the mechanism for retrieving configuration information,
there are different means of discovering the source of that information.
These include:

\begin{itemize}
\item[tftp:] DHCP, DNS SRV.

\item[SIP server:] multicast query, DNS SRV.

\end{itemize}

For DNS SRV, a new service type can be configured.  In conjunction with
the local domain name retrieved via DHCP, the client can thus form an
SRV query for, say, \_sip-config.\_udp.example.com or
\_tftp.\_udp.example.com.  This assumes, however, that the configuration
server has been entered into the local DNS database or, for the second
SRV entry, that all tftp-using clients make use of the same server.

\subsection{Update Notification}

It may be desirable that the device is notified when parts of the
configuration information have changed, so that the configuration can be
updated before the next boot cycle. (Cycling building power on and off
is probably not a scalable solution.) 

The SIP {\SUBSCRIBE}/{\NOTIFY} approach can be drafted here, where the
notification contains either the actual configuration data or one of
more alternative URLs indicating the location from which data can be
retrieved.

\subsection{Design Choices for Transport of Configuration Information}

There are a number of existing alternatives for conveying configuration
information to end systems.  However, unlike for routers and
workstations, some SIP user agents are likely to be severely constrained
in their ability to run a multitude of protocols, due to very limited
memory space.  Some devices may not support TCP, for example, as it is
not needed for other services on such devices.

Mechanisms need to be initiated by the end system, since configuration
information needs to be restored immediately after a reboot.

\subsection{SNMP}

SNMP \cite{rfc2578} has the advantage of being able to use UDP. The UA
could send traps to the address configured via the SNMP-TARGET-MIB
\cite{rfc2573} to the network management station, which would in turn
configure the device.

Complexity of a minimal SNMPv3 implementation is probably of the order
100 KB, and thus may be at or beyond the limit for embedded systems.

\subsection{DHCP}

The Dynamic Host Configuration Protocol \cite{rfc2131,rfc2132} is a
natural choice since end systems already need to support it to obtain
IP-level configuration information.  DHCP also requires only UDP and has
modest implementation complexity.  The main disadvantages are practical. 
In some systems, it is difficult for an application to gain access to
DHCP information.  This, however, is not likely to be a major issue for
embedded systems.  Also, all DHCP information generally resides on a
single server, so it requires the ability of those administering SIP end
systems to gain access to the DHCP server database.  Information in DHCP
databases can be tailored to a particular MAC address or user
identification string.  The latter allows, for example, to retrieve
information associated with a particular user rather than a particular
device.

DHCP options are numbered.  The space of available DHCP options, only
255 entries, is nearly exhausted, so that any use of DHCP for the dozen
or more configuration options likely to be needed will have to be
sub-options.  However, care must be taken to avoid complicated data
structures, as typical DHCP servers only support very simple data
structures, such as strings, integers and network addresses.

If users ``log in'' to a device, the DHCP query would have to be re-done
once the user identify is known.  Generally, DHCP appears designed for
device-level configuration, not user-level configuration. 

DHCP provides limited security, but lower-layer security mechanisms such
as IPsec can be employed for confidentiality and authentication.

DHCP options are limited to 255 bytes.  Since DHCP packets are
transmitted via UDP prior to MTU discovery, the overall length is
limited to 576 characters, although clients may negotiate the use of
larger DHCP messages \cite{rfc2131}.

\subsection{ACAP}

The Application Configuration Access Protocol \cite{rfc2244} is a
line-oriented protocol, similar in flavor to POP or IMAP, that allows to
retrieve configuration variables.  For example,
\begin{verbatim}
   C: A046 SEARCH "/addressbook/" DEPTH 3 RETURN ("addressbook.Alias"
           "addressbook.Email" "addressbook.List") OR NOT EQUAL
           "addressbook.Email" "i;octet" NIL NOT EQUAL
           "addressbook.List" "i;octet" NIL
   S: A046 ENTRY "/addressbook/user/joe/A0345" "fred"
           "fred@stone.org" NIL
   S: A046 ENTRY "/addressbook/user/fred/A0537" "joe" "joe@stone.org"
           NIL
   S: A046 ENTRY "/addressbook/group/Dinosaur Operators/A423"
           "saurians" NIL "1"
   S: A046 MODTIME "19970728105252"
   S: A046 OK "SEARCH completed"
\end{verbatim}

The protocol requires a reliable stream transport such as TCP.  It's
main use appears to be in the configuration of email clients. 
Parameters are named and allow textual and binary values of nearly
unlimited length.

ACAP can use TLS \cite{rfc2595} to secure its communication channel
against eavesdropping, modification and unauthorized use.  SASL is used
for authentication.

\subsection{tftp}

The Trivial File Transfer Protocol (tftp) \cite{rfc2348} is a simple
UDP-based file retrieval protocol which has been commonly used to load
boot code into memory.  Thus, it is likely to be needed by many
implementations.  Tftp provides weak security, as it is designed to
serve public information.

Configuration information could be returned as a text or binary file,
e.g., as lines of parameter-value text or XML.

The address of the tftp server can be configured via DHCP (Option 66).

\subsection{HTTP and HTTP-over-TLS}

Devices could be equipped with a web server that allows user
configuration. However, to facilitate configuration on reboot, the IP
device should probably initiate the configuration, e.g., via an HTTP
GET request, rather than having a client push configuration information
to the web server.

Like ACAP, HTTP requires TCP.

It remains to be specified where the device would find the web server
and how it would construct the appropriate device-specific URL.

\subsection{SIP}

SIP {\REGISTER} responses can contain message bodies, using similar
configuration parameter formats as the options described for tftp.  This
approach has the advantage that the information is readily available to
the application and that the correspondence between identifying the
configuration set and the SIP user name is readily apparent.

This approach does require registrar software modifications so that the
registrar can return the right information in the {\REGISTER} response.

To avoid additional configuration, the SIP UA can use multicast
registrations to locate the appropriate registrar or it could attempt to
use the outbound proxy.

\subsection{Others}

Other solutions, such as LDAP or SQL, are theoretically feasible but
likely to be excessively complex or insufficiently standardized as
protocols.

\section{Suggested Approach}

Among the solutions suggested above, DHCP and SIP-REGISTER appear to be
the easiest to implement.  In DHCP, a means for packing sub-options
needs to be found to circumvent the code-space constraints.  A simple,
but somewhat kludgey, mechanism packs XML or lines of parameter-value
pairs into the information element.

\section{Information Elements}

As a strawman, we propose a simple hierarchical data streams with text
values.  This can either be encoded into XML, as in

\begin{verbatim}
<par name="sip.busy.timeout">10</>
<par name="acme.par17" encoding=base64>84kz8Z37...</>
\end{verbatim}
or in an LDIF-like format, where base64-encoded parameters are marked with a double colon:

\begin{verbatim}
sip.busy.timeout: 10
sip.busy.url: sip:foo.com
acme.par17:: base-64 encoded string
\end{verbatim}

The LDIF-like format appears simpler to parse, but a specialized XML
parser for a small number of elements seems feasible even for
low-functionality end systems.

\section{Security Considerations}

Some configuration information, such as speed-dial configuration,
registration passwords or voice-mail URLs, may be considered sensitive
information and thus should not be disclosed to unauthorized users even
within the same organization.

On many tftp servers, all files have to be world-readable, making
protection of such information difficult.

DHCP does not provide data integrity, server or client authentication,
beyond address-based authentication based on MAC addresses.

Depending on local security policies, devices may require servers to
authenticate themselves and servers may require clients to do so. This
is likely to require some manual configuration of server public keys or
shared secrets.

\section{Authors' Addresses}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\bibliographystyle{ieeetr}
\bibliography{string,i-d,rfc}

\input{../copyright}
\end{document}