\section{Reaching the Emergency Call Center}
\label{sec:reaching}

\subsection{PSTN-only ECC}

\subsection{SIP-enabled ECC}

The architecture described here envisions Internet PSAPs (iPSAPs) that
operate in a fashion roughly similar to today's telephone-only PSAPs. 
These iPSAPs triage incoming communication and then contact the
appropriate public safety agency.  Callers reach the iPSAP in two
stages, by indicating a common, location-independent address
(Section~\ref{sec:user}), with a network entity then routing the call to
the appropriate iPSAP (Section~\ref{sec:finding}).

\subsection{Finding the Appropriate iPSAP}
\label{sec:finding}

Either the end system or a network entity, i.e., a SIP proxy server, can
determine the appropriate iPSAP.  Here, end systems include PSTN-to-VoIP
gateways.  As noted earlier, the appropriate iPSAP may not be the one
geographically closest to the user.  Except for corporate campuses with
their own emergency response infrastructure, boundaries of areas served
by an iPSAP (the ESZ) are very unlikely to bear any ressemblance to
network topology or network administrative regions.

In either case, there are a number of alternatives, including DNS, SLP
or a central directory server.  We discuss these options below.

For SIP-bases systems, note that end system and proxy-based routing can
be combined in a network, similar to how request routing works for
regular SIP requests.  If an end system or proxy does not know how to
find the appropriate iPSAP, it routes it to another proxy that may know. 
If the request does not contain location information, the proxy inserts
it, as described in Section~\ref{sec:locating}, possibly indicating how
certain it is about the accuracy of the location information.

\begin{changebar}
PSTN-to-VoIP gateways need to take the location of the caller into
account and thus will likely have to access existing ALI databases.
\end{changebar}

In an emergency response system, reliability is particularly important. 
Thus, it is desirable to minimize the number of servers and resolution
steps necessary to reach the PSAP.  As much as possible, the system has
to work even if wide-area communications is unavailable and should
minimize the delay even if the network is congested.

\begin{changebar}
\subsubsection{Finding the iPSAP via multicast or anycast}
\label{sec:multicast}

As discussed in Section~\ref{sec:user}, a multicast or anycast address
can be defined which allows any system to locate the nearest iPSAP. 
Unfortunately, network scoping and topology are not likely to conform to
the civic boundaries served by an iPSAP, but they may well be congruent
within a corporate campus network. 

The SIP {\INVITE} or {\MESSAGE} requests can be multicast.  Other
protocols may have to add multicast capabilities or need to use a
separate multicast protocol to locate the server, which is then
contacted via unicast.  In that case, SLP \ref{sec:slp} may well be
appropriate.

\end{changebar}

\subsubsection{Finding the iPSAP via Internet-accessible MSAG}

IP address -> location -> MSAG -> ENS

\subsubsection{Finding the iPSAP via a new DNS hierarchy}
\label{sec:finding_dns}

User locations are mapped into a DNS hierarchy, with each entry
referring to the appropriate iPSAP.  The DNS hierarchy can be either
geographically based or be based on civil designations such as postal
codes or town names, or both.  A DNS hierarchy based on geo location
(longitude and latitude) is not likely to work well since the
appropriate resolution of the entries is difficult to determine in
general.  For example, geographically close locations may be part of
different jurisdictions or separated by a river or mountain ridge. 
Also, PSAPs cover areas of very different size, depending on population
density.  Town names or postal codes (``civil location'') can be readily
encoded into DNS, as in {\tt 07605.us.emergency.arpa}, {\tt
5.0.6.7.0.us.emergency.arpa} or {\tt leonia.nj.us.emergency.arpa}.  It
remains to be determined whether there is sufficient overlap between
PSAPs and postal zones to make this approach viable.  This approach
works only if the proxy or end system has accurate civil location
information, as discussed below. Also, all valid postal codes or names
need to be populated.

The DNS entry can point to an SRV or NAPTR record, making it easy for
different protocols (SIP, H.323, chat, IRC, etc.) to reuse the same
directory infrastructure and allowing services for different
communications media to be handled by different iPSAPs.  (For example,
if a particular communications mechanism is not widely used or requires
special equipment, one location may handle it for several iPSAPs.)

\begin{changebar}
A DNS-based approach has the advantage that it scales well and entries
can easily be delegated. However, end systems or proxies have to be
configured with their civil location. Thus, either the end system or
proxy has to be able to determine the correct location of the end
system. This is likely to be easy for DSL, cable modem and leased-line
installation, but more difficult for dial and wireless users, as
discussed in Section~\ref{sec:determine}. 

A direct mapping of emergency phone numbers via the approach pursued in
the enum working group \cite{draft-ietf-enum-e164-dns} does not seem to
be possible, since it would map every such query to the same iPSAP
location.  An indirect mapping to a location service, however, is
necessary in any event.
\end{changebar}

\subsubsection{Finding the iPSAP via SLP}
\label{sec:slp}

Finding an iPSAP can be considered a service location problem.  However,
the SLP scope mechanism is not a good fit for service location, since it
usually corresponds to a local network administrative zone.  However, in
most cases, a single SLP zone falls within a single PSAP jurisdiction,
so that the mapping is likely to be valid.  On the other hand, SLP does
not really offer anything in that case that a simple query protocol
could not do just as well. Unless entities can discover the local
service directory via multicast, adding SLP would require yet another
configuration mechanism.

The SLP entry would likely contain the DNS entry discussed above or,
directly, the address of the iPSAP.  (The latter avoids reliance on DNS,
but is less flexible.)

A resolution mechanims based on SLP is not likely to be viable until
almost all local networks support the service.  It adds little
functionality if the proxy locates the appropriate iPSAP, as it can
perform the same look-up logic as the SLP server, saving an additional
step.

Also, if SLP were to be deployed primarily for emergency call use, it
would be less likely to be tested regularly and thus be less reliable. 
Reliability extensions to SLP \cite{draft-zhao-slp-da-interaction} may
be advisable to remove single points of failure.

Thus, the use of SLP is not likely to be viable alternative.

\subsubsection{Finding the iPSAP via DHCP}

As long as the address of the iPSAP is constant for all devices served
by a DHCP \cite{rfc2131} server, it is easy to configure it into DHCP. 
Unfortunately, it appears to be difficult for applications on standard
operating systems to access DHCP configuration information; embedded
devices have no such difficulty.

\subsubsection{Finding the iPSAP via LDAP}

\begin{changebar}
An LDAP server could, given information about a caller's civil or
geographical location, return the appropriate iPSAP address.  Unlike the
mapping from user identifier to location (see Section~\ref{sec:esid}),
this information is less privacy-sensitive, but updates to the data base
have to be carefully controlled. 
\end{changebar}

This approach requires configuring end systems or proxies with the
address of the appropriate LDAP server, thus making the approach not
viable for robust end system use. 

