\documentclass[11pt]{article}
\usepackage{times,i-d,txtpsfig,tight,grammar,html}
\usepackage[dvips]{changebar}
\usepackage{multibib}
\newcites{norm,inform}{Normative References,Informative References}

\author{H. Schulzrinne}
\shorttitle{The tel URI}
\filename{draft-ietf-iptel-rfc2806bis-03}
\title{The tel URI for Telephone Numbers}
\wg{}
\expires{December 2003}
\address{Columbia U.}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\tableofcontents

\begin{abstract}
This document specifies the URI (Uniform Resource Identifier) scheme
``tel''.  The ``tel'' URI describes resources identified by telephone
numbers.
\end{abstract}

\section{Terminology}
\label{sec:terminology}

In this document, the key words ``{\MUST}'', ``{\MUSTNOT}'',  
``{\REQUIRED}'', ``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'',
``{\SHOULDNOT}'', ``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}''
are to be interpreted as described in RFC 2119 \citenorm{rfc2119} and
indicate requirement levels for compliant implementations.

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

This document defines the URI scheme ``tel''.  The ``tel'' URI describes
resources identified by telephone numbers.  A telephone number is a
string of decimal digits that uniquely indicates the network termination
point.  The number contains the information necessary to route the call
to this termination point.  (This definition is derived from
\citeinform{E.164}, but encompasses both public and private numbers.)

The ``tel'' URI telephone number is not restricted in the type of
termination point it refers to.  The termination point can be in the
public telephone network, a private telephone network or the Internet. 
The termination point can be a mobile or a fixed wired terminal.  The
terminal addressed can support voice, data or fax.  The URI can refer to
resources identified by a telephone number, including but not limited to
originators or targets of a telephone call.

The ``tel'' URI is a globally unique identifier (``name'') only; it does
not describe the steps necessary to reach a particular number and does
not imply dialing semantics. Furthermore, it does not refer to a
specific physical device, only to a telephone number.

Telephone numbers as commonly understood actually comprise two related,
but distinct concepts: as a canonical address-of-record and as a
dial-string. We define the concepts below:

\begin{description}
\item[Address-of-record or identifier:] The telephone number is
understood here as the canonical address-of-record or identifier for a
termination point within a specific network.  For the public network,
these numbers follow the rules in E.164 \citeinform{E.164}, while
private numbers follow the rules of the owner of the private numbering
plan.  Subscribers publish such identifiers phone number as a universal
means of being reached, independent of the location of the caller. 
(Naturally, not all numbers are reachable from everywhere, for a variety
of technical and local policy reasons.  Also, a single termination point
may be reachable from different networks and may multiple such
identifiers.)

\item[Dial string:] ``Dial strings'' are the actual numbers, symbols and
pauses entered by a user to place a phone call.  A dial-string is
consumed by one or more network entities, and understood in the context
of the configuration of these entities.  It is used to generate a
telephone number so that a call can be routed.  Dial-strings may require
pre-pended digits to handle local PBXs, and they may include post-dial
DTMF signaling that could control an IVR or reach an extension.  Dial
strings are beyond the scope of this document.

\end{description}

To reach a telephone number from a phone on a PBX, for example, the user
of that phone has to know how to convert the telephone number identifier
into a dial string appropriate for that phone.  The telephone number
itself does not convey what needs to be done for a particular terminal. 
Instructions may include dialing ``9'' before placing a call or
prepending a ``00'' to reach a number in a foreign country.  The phone
may also need to strip area and country codes. 

The notation for phone numbers in this document is similar to that in
RFC 3191 \citeinform{rfc3191} and RFC 3192 \citeinform{rfc3192}. 
However, the syntax differs since this document describes URIs whereas
RFC 3191 and RFC 3192 specify electronic mail addresses.  RFC 3191 and
RFC 3192 use ``/'' to indicate parameters (qualifiers).  Since URI use
the forward slash to describe path hierarchy, the URI scheme described
here uses the semicolon, in keeping with Session Initiation Protocol
(SIP) URI conventions \cite{rfc3261}.

There are at least two ways one can envision making a telephone
connection.  In the first approach, a URI contains the dial string,
which is then passed to an entity that can reproduce the actions
specified in the dial string.  For example, in an analog phone system, a
dialer translates the dial string into a sequence of actions such as
waiting for dial tone, sending DTMF digits, pausing and generating
post-dial DTMF digits after the callee picks up.  In an ISDN or ISUP
environment, the recipient of the dial string performs the appropriate
protocol actions.

Another approach has the URI specify the telephone number, which can be
either globally unique or only be valid within a local context.  The
dialing application is aware of the local context, knowing, for example,
whether special digits need to be dialed to seize an outside line,
whether network, pulse or tone dialing is needed and what tones indicate
call progress.  The dialing application then converts the telephone
number into a dial sequence and performs the necessary signaling
actions.  The document below assumes the second model.  The dialer does
not have to be a user application as found in traditional desktop
operating systems, but could well be part of an IP-to-PSTN gateway.

The approach pursued here has the disadvantage that certain services,
such as electronic banking or voicemail, cannot be specified in a URI. 

The URI can be used as a request URI in SIP \citeinform{rfc3261}
requests.  The SIP specification also inherits the \header{subscriber}
part of the syntax as part of the \header{user} element in the SIP URI. 
Other protocols may use this URI for both query-based and prefix-based
applications.

The ``tel'' URI does not specify the call type such as voice, fax, or
data call and does not provide the connection parameters for a data
call.  The type and parameters are assumed to be negotiated either
in-band by the telephone device or through a signaling protocol such as
SIP.

\section{URI Syntax}

The URI is defined using the ABNF (augmented Backus-Naur form) described
in RFC 2234 \citenorm{rfc2234} and uses elements from the core
definitions (Appendix A of RFC 2234). 

The syntax definition follows RFC 2396 \citenorm{rfc2396}, indicating
the actual characters contained in the URI.  Note that the reserved
characters ``+'', ``;'', ``='', and ``?'' {\MUSTNOT} be escaped if shown
in the grammar definitions below as they are delimiters for the ``tel''
URI scheme.  These reserved characters {\MUST} be escaped if they appear
in parameter values.

Characters other than those in the ``reserved'' and ``unsafe'' sets (see
RFC 2396 \citenorm{rfc2396}) are equivalent to their ``\% HEX HEX''
encoding.

The ``tel'' URI has the following syntax:

\begin{syntax}
telephone-uri        & = & "tel:" telephone-subscriber\\
telephone-subscriber & = & global-number / local-number\\
global-number        & = & global-number-digits *par\\
local-number         & = & local-number-digits *par context *par\\
par                  & = & parameter / extension / isdn-subaddress\\
isdn-subaddress      & = & ";isub=" 1*uric\\
extension            & = & ";ext=" 1*phonedigit\\
context              & = & ";phone-context=" descriptor\\
descriptor           & = & domainname / global-number-digits\\
global-number-digits & = & "+" 1*phonedigit\\
local-number-digits  & = & 1*phonedigit-hex\\ 
domainname           & = & *( domainlabel "." ) toplabel [ "." ]\\
domainlabel          & = & alphanum\\
                     &   & / alphanum *( alphanum / "-" ) alphanum\\
toplabel             & = & ALPHA / ALPHA *( alphanum / "-" ) alphanum\\
parameter            & = & ";" pname ["=" pvalue ]\\
pname                & = & 1*( alphanum / "-" )\\
pvalue               & = & 1*paramchar\\
paramchar            & = & param-unreserved / unreserved / escaped\\
unreserved           & = & alphanum / mark\\
escaped              & = & "\%" HEXDIG HEXDIG\\
param-unreserved     & = & "[" / "]" / "/" / ":" / "\&" / "+" / "\$"\\
phonedigit           & = & DIGIT / [ visual-separator ]\\
phonedigit-hex       & = & HEXDIG / "*" / "\#" / [ visual-separator ]\\
visual-separator     & = & "-" / "." / "(" / ")"\\
alphanum             & = & ALPHA / DIGIT\\
\end{syntax}

Each parameter name (``pname''), the ISDN subaddress, the extension and
the context {\MUSTNOT} appear more than once.  The order of the URL
parameters is immaterial.  The ISDN subaddress or extension {\SHOULD}
appear first, if present, followed by the context parameter, if present,
followed by any other parameters in lexicographical order. 
\motivation{This simplifies comparison when the ``tel'' URI is compared
character-by-character, such as in SIP URIs \citeinform{rfc3261}.}

\section{URI Comparisons}
\label{sec:comparisons}

Two ``tel'' URIs are equivalent according to the following rules:

\begin{itemize}
\item URI are not equal if one is a \grammar{local-number} and the other
a \grammar{global-number}.

\item For mandatory additional parameters (Section~\ref{sec:parameter})
and the \grammar{phone-context} and \grammar{extension} parameters
defined in this document, \grammar{phone-number} parameter values are
compared digit-by-digit after removing all \grammar{visual-separator}s
from consideration.

\item Parameters are compared according to \grammar{pname}, regardless
of the order they appeared in the URI. If one URI has a parameter name
not found in the other, the two URIs are not equal.

\item URI comparisons are case-insensitive. 

\end{itemize}

All parameter names and values {\SHOULD} use lower-case characters since
tel URIs may be used within contexts where comparisons are
case-sensitive.  \motivation{Section 19.1.4 in the SIP specification
\citeinform{rfc3261} discusses one such case.}

\section{Phone Numbers and Their Context}
\label{sec:numbers_scope}

\subsection{Phone Numbers}
\label{sec:numbers}

The \grammar{subscriber} part of the URI indicates the number.  The
phone number can be represented in either global (E.164) or local
notation.  All phone numbers {\MUST} use the global form unless they
cannot be represented as such.  Numbers from private numbering plans,
emergency (``911'', ``112'') and some directory assistance numbers
(e.g., ``411'') and other ``service codes'' (numbers of the form N11 in
the United States) cannot be represented in global (E.164) form, and
need to be represented as a local number with a context.  Local numbers
{\MUST} be tagged with a \header{phone-context}
(Section~\ref{sec:local}).

Implementations {\MUSTNOT} assume that telephone numbers have a maximum,
minimum or fixed length, or that they always begin with a certain
number.

\motivation{E.164 limits numbers to 15 digits.  For geographic numbers,
one to three digits are the country code, with the remainder divided
into area or city code (national destination code) and subscriber
number.  Alternatively, there is a global three-digit service code,
followed by a global subscriber number of up to 12 digits.  Finally, a
``international public telecommunication number for networks is composed
of decimal digits arranged in three code fields.  The code fields are
the 3-digit shared Country Code (CC) field, the IC field, which varies
in length between 1 to 4 digits, and the Subscriber Number (SN) which
can be up to 15 minus the number of digits in the CC and IC fields.''
\citenorm{E.164}}

\subsubsection{Separators in Phone Numbers}
\label{sec:separators}

Phone numbers {\MAY} contain visual separators.  Visual separators
(\grammar{visual-separator}) merely aid readability and are not used for
URI comparison or placing a call.

\motivation{Despite complicating comparisons, this specification retains
the visual separators to follow the spirit of RFC 2396
\citenorm{rfc2396}, which remarks that ``A URI often needs to be
remembered by people, and it is easier for people to remember a URI when
it consists of meaningful components.'' Also, ISBN URNs documented in
RFC 3187 \citeinform{rfc3187} use visual separators in a manner similar
to this specification.}

\motivation{Even though ITU-T E.123 \citeinform{E.123} recommends the use of
space characters as visual separators in printed telephone numbers,
``tel'' URIs cannot use spaces to avoid excessive escaping.}

\subsubsection{Alphabetic Characters Corresponding to Digits}
\label{sec:vanity}

In some countries, it is popular to write phone numbers using alphabetic
characters which correspond to certain numbers on the telephone keypad. 
The URI format does not support this notation since the mapping from
alphabetic characters to digits is not completely uniform
internationally, although there are standards \citeinform{E.161,T1.703}
addressing this issue.

\subsubsection{Alphabetic, * and \# Characters as Identifiers}
\label{sec:alphabetic}

Since called and calling terminal numbers (TNs) are encoded in BCD in
ISUP, six additional values per digit can be encoded, sometimes
represented as the hexadecimal characters A through F.  Similarly, DTMF
allows for the encoding of the symbols *, \# and A through D.  However,
in accordance with E.164, they may not be included in global numbers. 
Their use in local numbers is not defined, but is not prohibited.

\subsubsection{Global Numbers}
\label{sec:global}

Globally unique numbers are identified by the leading ``+'' character. 
Global numbers {\MUST} be composed with the country (CC) and national
(NSN) numbers as specified in E.123 and E.164 \citeinform{E.123,E.164}. 
Globally unique numbers have the property of being unambiguous
everywhere in the world and are {\RECOMMENDED}.

\subsubsection{Local Numbers}
\label{sec:local}

Local numbers are unique only within a certain geographical area or a
certain part of the telephone network, e.g., a private branch exchange
(PBX), a state or province, a particular local exchange carrier or a
particular country.  URIs with local phone numbers should only appear
in environments where all local entities can successfully set up the
call by passing the number to the dialing software.  Digits needed for
accessing an outside line, for example, are not included in local
numbers.  Local numbers {\SHOULDNOT} be used unless there is no way to
represent the number as a global number.

\motivation{Local numbers require that the originator and recipient are
configured appropriately, so that they can insert and recognize the
correct descriptors.  Since there is no algorithm to independently pick
the same descriptor, labeling numbers with their context increases the
chances of mis-configuration, so that valid identifiers are rejected by
mistake.  The algorithm to select descriptors was chosen that accidental
collisions should be rare, but they cannot be ruled out.}

Local numbers {\MUST} have a \header{phone-context} parameter that
identifies the scope of their validity.  The parameter {\MUST} be chosen
to unambiguously identify the local context within which the number is
unique.  Thus, the combination of the descriptor in the
\header{phone-context} parameter and local number is again globally
unique.  The parameter value is defined by the assignee of the local
number.  It does NOT indicate a prefix that turns the local number into
a global (E.164) number. 

There are two ways to label the context:  via a global number or any
number of its leading digits (e.g., ``+33'') and via a domain name,
e.g., ``houston.example.com''.  The choice between the two is left to
the ``owner'' of the local number and is governed by whether there is a
global number or domain name that is a valid identifier for a particular
local number. 

The domain name does not have to resolve to any actual host, but {\MUST}
be under the administrative control of the entity managing the local
phone context. 

A global number context consists of the initial digits of a valid global
number.  All global numbers matching these initial digits must be
assigned to the same organization that is describing the context and no
such matching number can be used by any other organization.  If such an
initial string of digits does not exist, the organization should use the
lowest number of the global number range assigned to it.  (This can
occur if two organizations share the same decimal block of numbers.  For
example, assume an organization owns the number range +1-212-939-7000
through +1-212-939-7199.  +1-212-939-7 would not be a valid global
number context, but +1-212-939-7000 would work.) It is not required that
local numbers within the context actually begin with the chosen set of
initial numbers.

For a local number defined within a PBX, the organization can choose any
number under its control to identify the context.  For example, a
context consisting of any of the organization's global numbers may be
suitable, or a substring that is completely occupied by the
organization.  For example, +49-6151-16 would be a suitable context for
the TU Darmstadt, as it uses all numbers starting with those digits.

A context consisting of the initial digits of a global number does not
imply that adding these to the local number will generate a valid E.164
number.  It might do so by coincidence, but this cannot be relied upon. 
(For example, ``911'' should be labeled with the context ``+1'', but
``+1-911'' is not a valid E.164 number.)

National freephone numbers do not need a context, even though they are
not necessarily reachable from outside a particular country code or
numbering plan.  Recall that ``tel'' URIs are identifiers; it is
sufficient that a global number is unique, but it is not required that
it be reachable from everywhere. 

\motivation{Even non-freephone numbers may be out of date or not be
reachable from a particular location. For example, premium services
such as ``900'' numbers in the North American numbering plan are often
not dialable from outside the particular country code.}

\motivation{The two label types were chosen so that, in almost all
cases, a local administrator can pick an identifier that is reasonably
descriptive and does not require a new IANA-managed assigned number.  It
is up to the administrator to assign an appropriate identifier and to
use it consistently.  Often, an organization can choose among several
different identifiers.}

If the recipient of a ``tel'' URI uses the URI simply for
identification, the receiver does not need to know anything about the
context descriptor.  It simply treats it as one part of a globally
unique identifier, with the other being the local number.  If a
recipient of the URI intends to place a call to the local number, it
{\MUST} verify that it is within the same context as one of the
descriptors.  If it is not within the same context, it {\MUSTNOT}
initiate the call and treat the URI like an invalid destination.

\subsection{ISDN Subaddresses}

A phone number {\MAY} also contain an \grammar{isdn-subaddress}
parameter which indicates an ISDN subaddress.  

ISDN subaddresses typically contain IA5 characters, but may contain any
octet value.

\subsection{Extensions}

Extensions identify stations behind a PBX and are roughly equivalent to
ISDN subaddresses.  They are identified with the \grammar{extension}
parameter.  At most one of the \grammar{isdn-subaddress} and
\grammar{extension} parameters can appear in a tel URI, i.e., they
cannot appear both at the same time.

\subsection{Other Parameters}
\label{sec:parameter}

Future extensions to this URI scheme may add other parameters
(\grammar{parameter} in the ABNF).  Such parameters can be either
mandatory or optional.  Mandatory parameters start with ``m-''.  An
implementation {\MAY} ignore optional parameters.  An implementation
{\MUSTNOT} use the URI if it contains unknown mandatory parameters.  The
``m-'' prefix cannot be added to parameters that were already registered
(except to create a new, logically distinct parameter).  The
``phone-context'' parameter in this document is mandatory.

For example, \grammar{parameter} parameters can be used to store
application-specific additional data about the phone number, its
intended use, or any conversions that have been applied to the number. 

All new parameters {\MUST} be registered with IANA.

\section{Examples}
\label{sec:examples}

\begin{description}
\item[tel:+358-555-1234567]

This URI points to a phone number in Finland.  The hyphens are included
to make the number more human-readable; they separate country, area
codes and subscriber number.

\item[tel:7042;phone-context=cs.columbia.edu]

The URI describes a local phone number valid within the context
``cs.columbia.edu''.

\item[tel:863-1234;phone-context=+1-914-784]

The URI describes a local phone number that is valid within a particular
phone prefix. 

\end{description}

\section{Rationale}

\subsection{Why Not Just Put Telephone Numbers in SIP URIs?}

The ``tel'' URI describes a service, reaching a telephone number, that
is independent of the means of doing so, be it via a SIP-to-PSTN
gateway, a direct SIP call via ENUM translation, some other signaling
protocols such as H.323 or a traditional circuit-switched call initiated
on the client side via, say, TAPI.  It is thus, in spirit, closer to the
URN schemes that also leave the resolution to an external mechanism. The
same ``tel'' URI may get translated to any number of other URIs in the
process of setting up the call.

\subsection{Why Not Distinguish Between Call Types?}

Signaling protocols such as SIP allow to negotiate the call type and
parameters, making the very basic indication within the URL scheme moot.
Also, since the call type can change frequently, any such indication in
a URI is likely to be out of date. If such designation is desired for a
device that directly places calls without a signaling protocol such as
SIP, mechanisms such as the ``type'' attribute for the ``A'' element in
HTML may be more appropriate.

\subsection{Why ``tel''?}

``Tel'' was chosen since it is widely recognized none of the other
suggestions appeared appropriate.  ``Callto'' was discarded since URI
schemes locate a resource and do not specify an action to be taken. 
``Telephone'' and ``phone'' were considered too long and not as
internationally recognized.

\subsection{Do Not Confuse Numbers with How They Are Dialed}

As an example, the E.164 number ``+1-212-555-3141'' will be dialed in
many countries as 00-1-212-555-3141, where the leading ``00'' is a
prefix for international calls.  (In general, ``+'' in E.164 indicates
that an international prefix is required.) Tel URIs {\MUSTNOT} contain
the local dialing prefixes in numbers such as +1-212-555-3141, as the
transformation back to an international number is not guaranteed to be
correct or unique. 

If a network entity receives a ``tel'' URI containing a local number, it
{\MUST} make sure that it knows the context in which the local phone
number is to be processed, or else the number {\MUSTNOT} be used. 
Equally, the originator of a ``tel'' URI must take into consideration
that the recipient may have insufficient information about the phone
number's context.

\section{Usage of Telephone URIs in HTML}

Links using the ``tel'' URL {\SHOULD} enclose the telephone number, so
that users can easily predict the action taken when following the link.

\begin{verbatim}
  Dial <a href="tel:+3585551234567">+358-555-1234567</a> for assistance.
\end{verbatim}
instead of
\begin{verbatim}
  Dial <a href="tel:+3585551234567">this number</a> for assistance.
\end{verbatim}

On a public HTML page, the telephone number in the URI {\SHOULD}
always be in the global form, even if the text of the link
uses some local format.

\begin{verbatim}
  Telephone (if dialing in Finland): 
    <a href="tel:+3585551234567">(0555) 1234567</a>
\end{verbatim}

or even

\begin{verbatim}
  For having RFCs read aloud, call
  <a href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.
\end{verbatim}

\section{IANA Considerations}
\label{sec:iana}

``Tel'' URI parameters (\grammar{parameter}) {\MUST} be registered with
IANA.  Mandatory parameters must be described in a standards-track RFC,
while an informational RFC is sufficient for other parameters.

The registration must indicate:

\begin{itemize}
\item the parameter name;

\item a description of its applicability;

\item whether the parameter is mandatory or not ( Only the names of
mandatory parameters must start with ``m-'' as described in
Section~\ref{sec:parameter}.);

\item restrictions on the syntax of the parameter value in ABNF form;

\item a reference to the specification that defines it.
\end{itemize}

\section{Security Considerations}

The security considerations parallel those for the mailto URL
\citeinform{rfc2368}.

A recipient of a ``tel'' URI {\SHOULDNOT} place calls without the
consent of its owner.  Placing calls automatically without appropriate
user confirmation may incur a number of risks, such as those described
below.

\begin{itemize}
\item Calls may incur costs.

\item The URI may be used to place malicious or annoying calls.

\item A call will take the user's phone line off-hook, thus preventing
its use.

\item A call may reveal the user's, possibly unlisted, phone number to
the remote host in the caller identification data, and may allow the
attacker to correlate the user's phone number with other information
such as the e-mail or IP address.

\end{itemize}

\appendix

\section{Use of ``tel'' URIs with SIP (Informative)}

SIP can use the ``tel'' URI as a Request-URI, along with ``sip'' and
``sips'' URIs.  For brevity, we will imply ``sips'' URIs when talking
about SIP URIs.  Both ``tel'' and SIP URIs can contain telephone
numbers.  In SIP URIs, they appear as the user part, i.e., before
the @ symbol (Section 19.1.6 in \citeinform{rfc3261}).

Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
proxy servers has to translate the tel URI to a SIP URI, with the host
part of that URI pointing to a gateway.  Typically, the outbound proxy
server, as the first proxy server visited by a call request, performs
this translation.  A proxy server can translate all tel URIs to the same
SIP host name or select a different gateway for different tel prefixes,
based, for example, on information learned from TRIP.  However, a proxy
server could also delegate this translation task to any other proxy
server since proxy servers are free to apply whatever routing logic they
desire.

As noted earlier, all phone numbers {\MUST} use the global form unless
they cannot be represented as such.  If the local-number format is used,
it {\MUST} be qualified by the \header{phone-context} parameter. 
Effectively, the combination of local number and phone context makes the
tel URI globally unique.

TBD: Conversion of tel parameters to SIP

While web pages, vCard business cards, address books and directories can
easily contain global tel URIs, users on twelve-button (IP) phones
cannot dial such numbers directly and are typically accustomed to
dialing shorter strings, e.g., for PBX extensions or local numbers.
These so-called dial-strings (Section~\ref{sec:intro}) are not directly
represented by tel URIs, as noted. We refer to the translation of dial
strings into SIP and tel URIs, global or local, as the \emph{dial plan}.
There are at least two appropriate ways to deal with dial strings in SIP
terminals:

\begin{description}
\item[Local translation:] A SIP UA can use a dial plan to translate dial
strings into SIP or ``tel'' URIs.  The dial plan can be manually
configured or, preferably, be downloaded as part of a device
configuration mechanism.  (At this time, there is no standardized
mechanism for this.)

A mobile user can use at least two dial plans, namely the dial plan for
the network that he is currently visiting and the dial plan for the
user's home network. Generally, dialed numbers that are meant to
represent global numbers will look the same after the translation
regardless of the dial plan, even if, say, the visited network uses '0'
for dialing an 'outside' number and the user's home network uses '9', as
long as the user is aware of the current dial plan. However, local
extensions that do not have a direct global equivalent may well behave
differently. To avoid any ambiguity, the dial plan {\MUST} insert a
suitable \header{phone-context} string when performing the translation.
If the \header{phone-context} is a domain name, there are three cases:

\begin{enumerate}
\item The outbound proxy recognizes the domain name in the SIP URI as
its local context and can route the request to a gateway that
understands the local number.

\item The outbound proxy does not use the same phone context, but can
route to a proxy that handles this phone context. This routing can be
done via a lookup table or the domain name of the phone context might be
set up to reflect the SIP domain name of a suitable proxy. For example,
a proxy may always route calls with tel URIs like
\begin{verbatim}
tel:1234;phone-context=munich.example.com
\end{verbatim}
to the SIP proxy located at \texttt{munich.example.com}.

(Proxies that receive a tel URI with a context they do not understand
are obligated to return a 404 (Not Found) status resonse, so that an
outbound proxy may decide to attempt such a heuristic.)

\item The outbound proxy does not recognize the phone context and cannot
find the appropriate proxy cognizant of that phone context. In that
case, the translation fails and the outbound proxy returns a 404 (Not
Found) error response.

\end{enumerate}

\item[Proxy translation:] In proxy translation mode, the SIP UA simply
turns the dialed digits into the user part of the SIP URI and appends a
\texttt{;user=phone} parameter and provides an appropriate phone context
reflecting the local dialing plan.  The host name or IP address of the
outbound proxy is made the host part of the SIP request URI.  The
outbound proxy can then apply the dial plan indicated by the phone
context in the URI to translate the SIP URI into a ``tel'' URI or other
SIP URI.  Translation into a ``tel'' URI makes sense only if the proxy
wants to delegate finding the PSTN gateway to another proxy.

For example, after the user with a location-specified dial plan located
in domain ``munich.example.com'' dials the digits ``1234'', the device
converts this into a SIP URI:

\begin{verbatim}
sip:1234;phone-context=munich.example.com@example.com
\end{verbatim}

Alternatively, the SIP UA can issue a call with a ``tel'' URI. For this
example, it might be:

\begin{verbatim}
tel:1234;phone-context=munich.example.com
\end{verbatim}

Using a SIP URI is more robust and is thus the preferred approach.

\motivation{Since a single proxy may receive calls from many different
locations with different local dial plans, devices that rely on the
proxy for number translation {\SHOULD} always be configured with a
context.  Otherwise, a provider or enterprise would have to provision a
separate proxy for each branch office or geographic area with its own
dial plan, for example.}

\end{description}

\section{Change History}
\subsection{Changes from ietf-00 to ietf-01}

\begin{itemize}
\item Editorial changes suggested by Francois Audet.

\item Added * and \# as characters to local numbers.
\end{itemize}

\subsection{Changes from -08 to draft-ietf-iptel-rfc2806bis-00}

\begin{itemize}
\item Editorial clarifications.
\item Remove multiple context descriptions.
\end{itemize}

\subsection{Changes Since -07}
\begin{itemize}
\item Added section on using tel URIs in SIP.
\end{itemize}

\subsection{Changes Since -06}
\begin{itemize}
\item Clarified semantics.
\item Removed context from freephone numbers.
\item Added phone extensions.
\end{itemize}

\subsection{Changes Since -05}
\begin{itemize}
\item URI comparisons are case-insensitive. 

\item Specified recommended order of parameters to simplify use within
SIP URIs.
\end{itemize}

\subsection{Changes Since -04}

\begin{itemize}
\item ISDN subaddresses can contain any IA5 character or even binary
data; represented now as ``uric''.
\end{itemize}

\subsection{Changes Since -03}

\begin{itemize}
\item Clarified use of multiple contexts and how to express this, as a
comma-separated list.

\end{itemize}

\subsection{Changes Since -02}

\begin{itemize}
\item Clarifications and editorial fixes.

\item Now, mandatory parameters are labeled, to avoid making
\citeinform{draft-yu-tel-url} obsolete.

\end{itemize}

\subsection{Changes Since -01}

The draft has been greatly simplified to reflect parts that have
actually been implemented.

\begin{itemize}
\item Removed references to carrier selection.

\item Removed dial context.

\item Removed fax and modem URIs.

\item Removed post-dial strings.

\item Removed pause characters. 
\end{itemize}

\subsection{Changes Since RFC 2806}

The specification is backwards-compatible with RFC 2806.

\begin{itemize}
\item Editorial changes and clarifications.  The document has been
shortened and reorganized.  Most paragraphs have been rewritten to be
more concise.

\item Syntax now conforms to RFC 2396 \citenorm{rfc2396}, in particular
related to escaping.

\end{itemize}

\section{Acknowledgments}

This document is derived from RFC 2806 \citeinform{rfc2806}, written by
Antti V�h�-Sipil�.  Flemming Andreasen, Francois Audet, Lawrence Conroy,
Andrew Main, Michael Hammer, Jon Peterson, Mike Pierce, Jonathan
Rosenberg and James Yu provided extensive comments.

\section{References}

\bibliographystylenorm{ieeetr_url}
\bibliographynorm{string,rfc,i-d,itu}
\bibliographystyleinform{ieeetr_url}
\bibliographyinform{string,rfc,i-d,itu,ansi}

\section{Authors' Addresses}

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

\section{Full Copyright Notice}
\copyrightnotice

\end{document}
