\documentclass[11pt]{article}
\usepackage{times}
\usepackage{lettersize}
\usepackage[dvips]{changebar}
\pagestyle{myheadings}
\markboth{E*phone -- Proprietary and Confidential}{E*phone -- Proprietary and Confidential}

\newcommand{\INVITE}{\textsf{INVITE}}
\newcommand{\BYE}{\textsf{BYE}}
\newcommand{\ACK}{\textsf{ACK}}
\newcommand{\INFO}{\textsf{INFO}}
\newcommand{\CANCEL}{\textsf{CANCEL}}
\newcommand{\OPTIONS}{\textsf{OPTIONS}}
\newcommand{\REGISTER}{\textsf{REGISTER}}
\newcommand{\header}[1]{\textsf{#1}}

\title{E*phone Functional Specification and Feature Roadmap}
\author{Henning Schulzrinne}
\begin{document}
\maketitle

\section{Introduction}

This document describes the feature set for versions 2.1 and later of
the e*phone. The feature list is tentative and subject to availability
of programming and circuit design resources.

\section{Hardware}

The current 2.1 hardware consists of separate DSP, memory, Ethernet
interface, keyboard encoder, AD/DA and glue logic.  This affords
flexibility, but also increases cost and size.  The following future
versions are suggested.

The SIP hardware versions are listed below:

\begin{flushleft}
\begin{tabular}{llr}
1.0 & original ``blue phone''               &  1\\
2.0 & original Sprint phone                 & 12\\
2.1 & different voltage regulator           & (*)\\
2.2 & different PCB for modified components & 100?\\
3.0 & new chip set, custom case             & millions\\
\end{tabular}
\end{flushleft}

(*): Version 2.1 was modified in-place on existing 2.0 devices.

\subsection{E*phone Hardware Version 3.0}

The next hardware revision should utilize a single integrated chip for
the network, keyboard encoder and DSP components, possibly also the
AD/DA, LCD driver and parts of memory.  Integrating the AD/DA may make
it more difficult to provide high-quality audio input/output.  Mitel,
Netergy and Lucent may offer VoIP chips now or in the near future.  (The
Mitel chip is apparently sampling.) Another possibility is the Crystal
Semiconductor EP 7212 or CL-PS 7500E chip set.  (Apparently, there will
also be a successor to the EP 7212, the EP 7213.) 

\begin{flushleft}
\begin{footnotesize}
\begin{tabular}{l|l|*{8}{l}}
Company & chip        & RAM    & DSP & A/D & Ethernet & keyb. & LCD & PCMCIA & USB\\
\hline
Mitel   & MT92101     &  11 kB & yes & MT92303 & 2 MII & 8x8  & no & no  & yes\\
Netergy & T2          & 256 kB &     &         & 2 MII & GPIO & no & no? & no\\
Crystal & EP 7212     &        &     &         & no    &      & yes & CL-PS6700 & no\\
Crystal & CL-PS 7500E &        &     & \\
Crystal & CL9312      &        & no  & no      & 2 MII & 8x8  & yes & yes & yes\\
TI      & C5472       & 144 kB & yes &         & 2 MII & GPIO & no & no & no\\
\end{tabular}
\end{footnotesize}
\end{flushleft}

\begin{description}
\item[Crystal EP 7212:] Low power; DRAM controller; use CL-PS6700 for
PCMCIA; 74 MHz ARM clock.

\item[Crystal CL-PS 7500E:] Set-top box with CRT interface.

\item[Crystal EP9312:] Built-in Ethernet.

\item[Mitel:] 25 MHz ARM and 60 MIPS DSP;  includes codecs and echo
suppression;  8x8 keypad; no cache? \$21

\item[Netergy:] Only GPIO for keyboard, so only small keypad possible;
SRAM interface; has a flash cache allowing direct use of flash memory;
150 DSP MIPS.

\item[TI/Telogy:] 50 MHz ARM, 100 MHz DSP; $I^2C$ interface 

\end{description}

All devices use the ARM CPU core.

The following hardware features should be integrated:
\begin{itemize}
\item USB interface for video camera and other peripherals such as
keyboards;

\item PCMCIA or similar interface for IEEE 802.11 wireless LAN
interface for home or business wireless networks;

\item i-button or other identification interface, such as fingerprint
recognition, to personalize phone;

\item large, graphical LCD for web interface (Avantgo?).
\end{itemize}

This hardware could then be integrated in wireless residential or
business handsets (similar to the Siemens Gigaset), wireless phone sets
(non-portable), Ethernet ``business'' phone sets (possibly with special
versions for vertical markets such as hotel, dormitory or ATMs) and as
boards in external devices such as kiosks and ATMs. 

\begin{changebar}
As an alternative, the PCB could be integrated into a walkman-style
enclosure, worn on a belt or in a pocket, with a microphone/ear-bud
combination (e.g., Jabra).  One could even combine an Internet (MP3)
radio into the same device with minimal cost.  Depending on how much
flash memory the device contains, the device can then automatically
``recharge'' itself when within radio range and serve as a standard MP3
player when not.

With about 30x30 mm PCB real-estate, it is possible to integrate a GPS
receiver for location-based services. (The module from u-blox costs
about \$151. However, GPS only works outside.

For the wireless versions, a first version would simply use the Apple
AirPort or Lucent access point, connected via Ethernet to a DSL or cable
modem.  Later, it would be useful to cooperate with a DSL or cable modem
vendor to integrate SIP proxy server functionality, 802.11 capability as
well as a NAT ALG to deal with single-address residential networks into
DSL and cable modems.
\end{changebar}

Design of this hardware should, in my opinion, proceed as quickly as
possible. In particular, the chip set needs to be selected based on
anticipated feature sets, availability and costs. Also, case design
alternatives need to investigated.

\section{E*phone Software}

\subsection{Preliminary Schedule}

\begin{flushleft}
\begin{tabular}{ll}
2.1  & July 25, 2000\\
2.2  & September 1, 2000\\
2.3  & November  1, 2000\\
\end{tabular}
\end{flushleft}

For each release, a user manual needs to be written and/or updated.

In the tables below, the date indicates when the feature was completed
and tested. Features not yet finished are marked with the person
responsible: 
\begin{flushleft}
\begin{tabular}{ll}
ka & Knarig Arabshian\\
lw & Li Wang\\
gn & Gautam Nair\\
pn & Pallavi Nayak\\
\end{tabular}
\end{flushleft}

\newpage
\subsection{Network Module}

\begin{flushleft}
\begin{tabular}{lll}
IPv4 support                      & 2.1 & 07/13/00\\
ARP, with cache                   & 2.1 & 07/13/00\\
ICMP router advertisements        & 2.1 & 07/13/00\\
ICMP echo reply (for ping)        & 2.1 & 07/13/00\\
ICMP echo request (outgoing ping) & 2.1 & 07/13/00\\
ICMP port unreachable             & 2.1 & 07/13/00\\
IGMP (multicast) support          & 2.1 & 07/13/00\\
DHCP for IP address               & 2.1 & 07/13/00\\
DHCP for net mask                 & 2.1 & 07/13/00\\
DHCP for tftp server              & 2.1 & 07/13/00\\
DHCP for DNS host name            & 2.1 & 07/13/00\\
DHCP for DNS resolver             & 2.1 & 07/13/00\\
DHCP for default gateway          & 2.1 & 07/13/00\\
DHCP for default SIP proxy        & 2.1 & 07/13/00\\
DHCP for time server              & 2.1 & 07/13/00\\
DHCP for user name                & 2.1 & gn\\
Time protocol support for clock   & 2.1 & 07/13/00\\
{\tt syslog} logging              & 2.1 & 07/13/00\\
{\tt tftp} upgrade                & 2.1 & 07/13/00\\
Handle fragmented packets         & 2.1 & 07/13/00\\
UDP                               & 2.1 & 07/13/00\\
DNS A resource records            & 2.1 & 07/13/00\\
DNS CNAME resource records        & 2.1 & 07/13/00\\
DNS SRV resource records          & 2.1 & 07/13/00\\
IPv4 router alert option          & 2.2 &\\
TOS byte setting (for diffserv)   & 2.2 &\\
\end{tabular}
\end{flushleft}

Network functionality can be tested with a DHCP, DNS and tftp server and
via {\tt ping}.

\newpage
\subsection{Audio/RTP Module}

The audio module handles incoming audio packets, packetizes and encodes
audio, generates RTP and parses RTP.  Other audio codecs, such as G.726,
G.729 or G.723.1, can be added depending on licensing restrictions and
system application.

\begin{flushleft}
\begin{tabular}{lll}
Call progress tones (busy, fast busy, ring back)  & 2.1 & 07/13/00\\
Audio loop back mode for hardware testing         & 2.1 & 07/13/00\\
G.711 ($\mu$-law) codec                           & 2.1 & 07/13/00\\
RTP (timestamp, seq. no, PT)                      & 2.1 & 07/13/00\\
Robust against timestamp reset                    & 2.1 & pn/lw\\
Audio playout delay tested with trace             & 2.1 & pn/lw\\
RTCP SR/RR sending                                & 2.1 & pn/lw\\
Speaker phone mode                                & 2.2 &\\
Audio mixing                                      & 2.2 &\\
DTMF generation in RTP (RFC 2833)                 & 2.2 &\\
GSM audio codec                                   & 2.2 &\\
DVI audio codec                                   & 2.2 &\\
MPEG 2 L3 audio decoder                           & 2.2 &\\
Outgoing DTMF tone generation                     & 2.2 &\\
RTCP receiver support for diagnostics             & 2.2 &\\ 
Mid-call codec changes                            & 2.2 &\\
Bandwidth-adaptive audio codec                    & 2.3 &\\
Loss compensation (FEC, RFC 2733)                 & 2.3 &\\
YESSIR resource reservation                       & 2.3 &\\
Play back RTP DTMF tones                          & 2.3 &\\
Acoustic echo cancellation for speaker-phone mode & 2.x &\\
MIDI support for ring tones                       & 2.x &\\
\end{tabular}
\end{flushleft}

Speaker-phone mode is automatically enabled when one of the speed-dial
or line buttons is pressed if the handset is in the cradle.

RTP functionality can be tested with the {\tt rtpsend} and {\tt rtpplay}
tools, using recorded packet traces.

\newpage
\subsection{SIP/RTSP/SAP Module}

The SIP module provides call state.  In version 2.1, only a single
logical line is supported, while later versions support multiple (up to
four) lines.

The Session Announcement Protocol (SAP) \cite{draft-ietf-mmusic-sap-v2}
allows to advertise ``radio'' multicast sessions.  Radio sessions are
automatically muted when a call arrives.

RTSP support enables voice mail retrieval and audio-on-demand, assuming
suitable codecs.

\begin{flushleft}
\begin{tabular}{lll}
{\INVITE}, {\ACK}, {\BYE} support                  & 2.1 & 07/13/00\\
{\REGISTER} support, with refresh                  & 2.1 & gn\\
SIP \header{From}, \header{To}, \header{Call-Id}   & 2.1 & 07/13/00\\
SIP \header{CSeq}                                  & 2.1 & 07/13/00\\
SDP, without dynamic payload types                 & 2.1 & 07/13/00\\
Generation and processing of \header{Via} headers  & 2.1 & 07/13/00\\
Generation of SIP \header{To} tags                 & 2.1 & 07/13/00\\
Change media types in mid-session                  & 2.2 &\\
{\REGISTER} several identities                     & 2.2 &\\
Accept 30x redirect                                & 2.2 &\\
{\CANCEL} generation                               & 2.2 &\\
{\CANCEL} handling                                 & 2.2 &\\
SDP, with dynamic payload types                    & 2.2 &\\
SAP for multicast sessions                         & 2.2 &\\
Call forwarding on no answer                       & 2.2 &\\
Call forwarding busy                               & 2.2 &\\
Call forwarding do-not-disturb with \header{Retry-After} & 2.3 &\\
Intercom mode (auto-answer)                        & 2.3 &\\
Basic authentication for incoming calls (password) & 2.2 &\\
Digest authentication for incoming calls           & 2.2 &\\
Digest authentication for {\REGISTER}              & 2.2 &\\
Basic authentication for outgoing calls            & 2.3 &\\
Digest authentication for outgoing calls           & 2.3 &\\
Distinctive ringing based on caller id             & 2.3 &\\
Distinctive ringing based on \header{Priority}     & 2.3 &\\
Forwarding when noone present (sensor)             & 2.3 &\\
Multiple logical ``lines'' (``call presences'')    & 2.3 &\\
Call transfer                                      & 2.3 &\\
Conferencing between lines                         & 2.3 &\\
Allow camp-on and queueing                         & 2.3 &\\
Log-in via i-Button or keypad                      & 2.4 &\\
Interface to passive IR sensor                     & 2.4 &\\
\end{tabular}
\end{flushleft}

For multiple lines, all participants are shown in the four LCD display
lines:
\begin{verbatim}
 L1 John Doe
>L2 Jane Doe
 L3 Alice 
 L4 Bob
\end{verbatim}

The {\REGISTER} request is first sent to the SIP multicast address. If
there is no response or if the domain in the user's SIP URL differs from
the local domain, the request is also sent to the SIP server derived
from the DNS SRV record of the user's SIP domain. For example, if a
phone belonging to the user {\tt bob@example.com} is moved to {\tt
cs.columbia.edu}, it would register at the server belonging to {\tt
example.com} (in addition to the local server in the {\tt
cs.columbia.edu} domain).

SIP functionality can be tested with {\tt siptc}.

\newpage
\subsection{User Interface Module}

Configuration information is used only if DHCP is not available or
disabled.

\begin{flushleft}
\begin{tabular}{lll}
Display time of day                               & 2.1 & ka\\
Display call duration                             & 2.1 & ka\\
Display name/SIP URL of calling party             & 2.1 & ka\\
Display name/SIP URL of called party              & 2.1 & ka\\
Display subject of call                           & 2.1 & ka\\
Display priority of call                          & 2.1 & ka\\
Display call progress (1xx messages)              & 2.1 & ka\\
Configuration: SIP name                           & 2.1 & ka\\
Configuration: net mask                           & 2.1 & ka\\
Configuration: own IP address                     & 2.1 & ka\\
Configuration: gateway address                    & 2.1 & ka\\
Configuration: DNS resolver address               & 2.1 & ka\\
Configuration: domain                             & 2.1 & ka\\
Configuration: host name                          & 2.1 & ka\\
Configuration: logging server                     & 2.1 & ka\\
Configuration: time server                        & 2.1 & ka\\
Configuration: SIP outbound proxy                 & 2.1 & ka\\
Configuration: voice mail address (b/na/dnd)      & 2.2 & \\
Configuration: no-answer delay                    & 2.2 & \\
Distinctive ringing by priority                   & 2.2 &\\
Address book (downloadable)                       & 2.2 &\\
Speed-dial buttons (downloadable)                 & 2.2 &\\
Configuration: busy behavior (queue, reject)      & 2.3 &\\
Display packet statistics                         & 2.3 &\\
Call log (time, subject, caller)                  & 2.3 &\\
Radio interface                                   & 2.3 &\\
RTSP-based distinctive ringing                    & 2.4 &\\
RTSP voicemail interface (play, ff, rw, etc.)     & 2.4 &\\
Calculator module                                 & 2.x &\\
Alarm module                                      & 2.x &\\
\end{tabular}
\end{flushleft}

Each phone can have several identities, e.g., both a user name and a
telephone number. By default, identities are prepended to the local
domain name.

The configuration menu has the following structure:
\begin{verbatim}
1 Network
  1 Enable (Disable) auto-configuration
  2 IP address
  3 Network mask
  4 Gateway
  5 DNS server
  6 Domain name
  7 Log server
  8 Time server
  9 Outbound SIP server
2 Phone
  1 Identities
    Id 1 - name
    Id 1 - address
    Id 2 - name
    Id 2 - address
    Id 3 - name
    Id 3 - address
    Id 4 - name
    Id 4 - address
  2 Voicemail
    Voicemail busy
    VM no answer
    VM do-not-disturb
    Wait for answer
3 Software
  1 Update server
\end{verbatim}

Items 1/2-10 are only enabled if auto-configuration is {\em dis}abled.
Otherwise, item '2' is replaced by the ability to list the current
configuration.

Software is updated after changing or confirming the tftp server under
the ``Software'' option. While this is sometimes configured for a local
server, it should be possible to override the DHCP choice to allow
upgrading from a remote server.

Under some circumstances, it is desirable to be able to configure the
user name centrally, e.g., when installing a large number of phones at
the same time.  This also provides some modest measure of protection
against people spoofing their identity.  An administrator simply creates
a list of hard-coded e*phone identifiers, such as their MAC address or
serial number, printed on the case when phones are assigned to their
owners.  The user name is configured based on the client identifier
(DHCP option 61).  There currently does not appear to be a generic DHCP
option for this, so this is probably best encoded in a vendor-specific
option (43).  The e*phone should identify itself as such via the vendor
class identifier option (60) in the DHCP request.

There should be a button that goes up one layer in the configuration
menu.

The speed dial buttons are configured either by adding a person called
or calling to a speed dial button or by obtaining the information in the
{\REGISTER} response. Modified speed-dial buttons are uploaded via the
{\REGISTER} request. Speed dial buttons are configured by a simple text
file containing \header{Contact} information, such as
\begin{verbatim}
1 John Doe <sip:j.doe@example.com>
2 Alice <sip:alice@wonderland.com>
\end{verbatim}

If the e*phone is idle:
\begin{verbatim}
ephone 2.1
Th, Jun 9  6:33
7042
\end{verbatim}

The following display appears when the handset is picked up or the
speaker phone button is pressed:
\begin{verbatim}
Dial and hit Go
>_______________
 Jane
 Alice
 Carol
 Bob
\end{verbatim}

The cursor can scroll through the call list, sorted either
alphabetically or in order of last call.

If the phone is busy, the name of the caller is displayed and added to
the call log.

\begin{verbatim}
6:34   1.12
John Doe
 j.doe@columbia.edu
To Alice Smith
\end{verbatim}

The \header{To} information is displayed only if it differs from the
user registered for the phone. Whenever \header{name-addr} information
is displayed, name and SIP URL are split across two lines if they do not
fit into a single display line. (The average email address is about 20
charactes long, while the average first and last names add up to about
14 characters.)

Distinctive ringing can be implemented by having the inbound proxy
include a special ringing header, configured, for example, based on
priority or caller identity. The ringing header includes an RTSP
URL, which points to the audio source for ring tone. This avoids having
to store ring music on the end system. Alternatively, the configuration
can be done at the end system, but that's likely going to be more
cumbersome and does not move from phone to phone.

\subsection{WAP Functionality}

\begin{changebar}
It may be possible to integrate WAP access into a small-screen device
(version 2.1).  To limit ephone complexity, it is advisable to have a
server translate WAP WDML into SIP {\INFO} messages.  Similarly, key
clicks in ``browser'' mode are directly forwarded to the WAP gateway
server.

One problem that remains to be addressed is the ability to ``dial'' a
URL directly from the device. SIP third-party mechanisms may make this
possible.
\end{changebar}

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

\end{document}
