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

\title{The SIP Configuration Event Packages}
\author{Schulzrinne/Petrie}
\shorttitle{SIP-config-event}
\filename{schulzrinne-sip-config-event-00}
\wg{SIP WG}
\expires{August 2001}
\address{Columbia U./Pingtel}
\pubdate{\today}
%\input{rfc}
\input{../defs}

\begin{document}
\maketitle
\begin{abstract}
This document describes the SIP configuration event packages, used for
configuring SIP-based end systems.
\end{abstract}

\section{Introduction}

In large deployments of SIP-based Internet telephony devices (``SIP
phones'', for short), manually configuring SIP and other related
parameters manually is not feasible.  In addition, we want to be able to
support user interface configuration such as speed-dial lists, dial
plans, small dowloadable applications or other services.  Since
configurations can change while the system is operational, we use the
SIP event mechanism to inform end systems of these changes.  Actual
configuration data is typically transferred using a separate retrieval
protocol.  This specification describes a set of SIP events packages
that enable such configuration.  Each type of configuration is assigned
its own event type, allowing end systems to subscribe only to
configuration information of interest to them.

The event packages are named \textit{config-basic} for basic
configuration, \ldots

We allow the SIP configuration server to be a separate entity, but it
can be colocated with other SIP servers.

This specification does not describe the format of configuration
information.

\section{Operation}
\label{sec:operation}

On start-up and after the subscription expiration, end systems subscribe
to the desired configuration events.  A device can subscribe to the same
information under multiple identities, for example, the basic system
identity, the main temporary ``owner'' of the device and visiting
guests.  For example, basic configuration information and dial plans may
be device-specific, speed dial configuration is likely to be tailored to
the owner while guests may run applets.

Each system should subscribe to \textit{mac@local\_domain}, where
\textit{mac} is the MAC address, expressed in hexadecimal with hyphen
separators, e.g., 00-90-27-97-DA-48@example.com.

TBD: Should they be labeled as ``type=device'' or similar?

\motivation{Colons are reserved in the ``user'' component of SIP URLs.}

Note that systems may subscribe to configuration information in other
networks (``home network'').  Such subscriptions are routed like normal
SIP requests.

(NOTE:  It would be helpful if registration allowed indication of event
types handled, so that the proxy can route the request to the right
server and so that the registration server can register with the proxy
for these events.)

The default subscription expiration interval is 12 hours (?). Systems
{\SHOULD} randomize their subscription intervals by half of the nominal
value.

Before powering down, end systems {\SHOULD} unsubscribe from the
configuration information.

To avoid overloading the configuration server when a large number of end
systems all wake up at approximately the same time, e.g., after a power
failure, end systems {\SHOULD} randomly delay their subscription, with
the delay interval chosen uniformly between 0 and 60 seconds.  Systems
{\MAY} multicast notifications containing common system parameters to
speed up initial configuration.  End systems {\MUST} be able to perform
basic SIP calls prior to receiving configuration information.

\motivation{This requirement is motivated by the need to be able to
complete emergency calls even if the configuration server has not yet
responded or is unavailable.}

The body of the SIP {\NOTIFY} message typically contains data of type
\texttt{text/uri-list} \cite{rfc2483} pointing to the configuration
information.  URL schemes http \cite{rfc2068} and tftp
\cite{draft-schulzrinne-tftp-url} are preferred.  If several URIs are
listed, the device may choose any of them.  The order of the URIs listed
has no significance.

\section{Scaling Considerations}
\label{sec:scaling}

Configuration may suffer from scaling problems if large numbers of end
systems request configuration updates simultaneously or subscribe to
these updates.  As pointed out, this may occur after power failures. 
Servers may drop subscription requests, leading to retransmissions and
further traffic amplification.  This specification addresses this by
having SIP phones subscribe after a randomized delay.  Unfortunately,
scaling techniques such as reconsideration \cite{Rose9803:Timer} are not
applicable here.  Additionally, servers distribute basic configuration
information via multicast to avoid unnecessary duplicate retrievals by
each SIP phone.

For very short configuration, it may be preferable to allow
notifications to contain the actual data.

\section{Modifying Configuration Data}
\label{sec:edit}

We use the mechanism described in \cite{draft-lennox-sip-reg-payload} to
allow SIP clients to update their configuration information.  TBD:  The
configuration server may be a separate server, so some mechanism needs
to be found for the configuration server to obtain this information.  It
is possible that the configuration server can register (without a
\header{Contact} header) or the server can use the new configuration
method that has been proposed.

\section{Security Considerations}
\label{sec:security}

While some of the configuration information is public or not
particularly sensitive, configuration information such as speed dial
lists or end-systems call handling scripts are sensitive.  SIP phones
and configuration servers {\MUST} use appropriate authentication, using
the same keys as for registration.

\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}

\begin{flushleft}
Daniel G. Petrie\\
Pingtel\\
\end{flushleft}

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

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