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

\title{Emergency Call Services for SIP-based Internet Telephony}
\author{Schulzrinne}
\shorttitle{Emergency Calling}
\filename{draft-ietf-sip-emergency-00}
\wg{}
\expires{December 2001}
\address{Columbia U.}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\begin{abstract}
This document describes how SIP-based Internet telephony systems can
provide emergency calling services.
\end{abstract}

\section{Introduction}
\label{sec:intro}

A companion document \cite{draft-schulzrinne-sip-911} outlines some of the
issues in providing emergency calling service.  This document suggests a
set of protocols and operational mechanisms to provide such services. 
The design is motivated by the desire to keep the overall system as
simple as possible and to minimize dependencies on external services,
particularly those that are used only or mainly for emergency services.

We abstractly refer to emergency answering services (EAS) as locations where
public safety officials answer emergency calls. In the United States and
Canada, these are commonly known as Public Safety Answering Points
(PSAPs). In Europe, \ldots

In this document, we do not distinguish whether the EAS is connected to
the legacy PSTN or uses SIP-enabled end systems. For simplicity, we
assume that calls are routed to the PSTN gateway that can reach
emergency services that correspond to the caller's location. (Note that
this has implications for the density of PSTN gateways.) In the future,
it may be feasible for gateways to provide guidance to PSTN switches as
to which exchange the call originated from, even if the calling Internet
terminal does not have an assigned E.164 number that corresponds to a
geographic location. (With number portability, E.164 numbers may not be
good indicators of geographic origin and thus may not be helpful in
selecting an EAS.)

\section{Emergency Address}
\label{sec:address}

See {sos}

\section{Locating the Emergency Answering Service}
\label{sec:locating}

DHCP outbound proxy \cite{rfc3361}

\cite{rfc3397} search domain list

try both local domains and home domain via OPTIONS

\item pre-configured for all emergency calls
   e.g., state

\item database of 
  only if update mechanism
  event subscription

Supported mechanism to indicate that this is an emergency number

sos.test for testing
Require: test-only   - allows RTP and RTCP testing


For reliability and robustness, any SIP proxy, including outbound
proxies and those operating in emergency answering services (EAS),
{\SHOULD} attempt to route the call to the best available EAS, based on
location information contained in the request.  For example, a basic
proxy might always route the call to a single EAS, even though the
caller's physical location may require routing to another EAS.

\motivation{With VPNs, a proxy may not be able to tell whether a call
originated within the local campus, for example.}

UAs {\SHOULD} include geographic and/or civil location information in
their emergency requests.  Proxies {\MAY} add additional information to
calls they recognize as emergency calls, either to augment the
information or to indicate that the proxy has doubts about the location
information already included in the request.  (This mechanism raises
number of security considerations detailed in
Section~\ref{sec:security}.)

Similar to the use of ENUM \cite{rfc2916}, we propose to use DNS to map
location identifiers to SIP or other URLs.  (Note:  If a particular
domain does not want to use this mechanism, they can refer the emergency
call to a hard-configured EAS, which can then use any local mechanism to
perform further call routing lookups.) For example, postal codes and
country identifiers may be used for mappings, so that the United States
postal code 07605-1234 gets mapped to a DNS lookup {\tt
4.3.2.1.5.0.6.7.0.us.emergency.arpa}.  If a locality has multiple
address code formats, such as shorter and longer postal codes, the short
codes should also have entries, in case the UA or proxy does not have
precise location information. The management of this DNS address space
is beyond the scope of this document.

\motivation{Postal codes are usually assigned geographically, so that
resolution is more likely to be geographically close to the querier,
increasing reliability.  DNS is proposed since it does not require
installing and maintaining additional servers and infrastructure, is
usually fast and minimizes the additional complexity in proxies. It does
have the disadvantage that geographic information has to be entered
completely. Does this work for Canadian and UK postal codes that combine
letters and numbers?}

[THIS REQUIRES DISCUSSION. IS THERE A BETTER SCHEME?]

\section{User Location}

The UA or proxy handling the emergency call adds information about
caller location (civil and/or geographic) to the SIP request, using the
\header{Remote-Party-ID} header \cite{draft-ietf-sip-privacy}. 

[THIS IS OBVIOUSLY HAND-WAVING.]

The ability of EAS to request location information from third parties is
beyond the scope of this document, as it does not affect SIP signaling.

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

Emergency call services raise numerous security and privacy issues.
Callers need to be authenticated to discourage crank calls that could
interfere with true emergency requests. This requires authenticated
caller information, but this also raises privacy issues. Generally,
expectation of privacy appears to be less than making emergency calls,
as location information is considered extremely helpful in providing
emergency assistance. It may be desirable, however, to allow end systems
to explicitly decline being identified by location or caller, with the
answering emergency operator being made aware of this fact.

Address information needs to be protected against spoofing, either
within the end system or en route, as such spoofing can be used to deny
emergency services.

RFC 1984 \cite{rfc1984}

\section{Acknowledgements}

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

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

\input{copyright}
\end{document}
