WDIFF

draft-ietf-iptel-rfc2806bis-02.txt --> draft-ietf-iptel-rfc2806bis-04.txt

Internet Engineering Task Force
Internet Draft

Network Working Group H. Schulzrinne/A. Vaha-Sipila Schulzrinne
Internet-Draft Columbia U./Nokia
draft-ietf-iptel-rfc2806bis-02.txt
June 29, 2003 U.
Expires: December 2003 August 15, 2004 February 15, 2004

The tel URI for Telephone Numbers

STATUS OF THIS MEMO

This document is an Internet-Draft
draft-ietf-iptel-rfc2806bis-04

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
RFC 3667.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts. Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories, see Directories can be accessed at
http://www.ietf.org/shadow.html.

H. Schulzrinne/A. Vaha-Sipila [Page 1]

Internet Draft

This Internet-Draft will expire on August 15, 2004.

Abstract

This document specifies the URI (Uniform Resource Identifier) scheme
"tel". The "tel" ``tel'' URI describes resources identified by telephone
numbers.

Schulzrinne Expires August 15, 2004 [Page 1]

Internet-Draft The tel URI February 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", . . . . . . . . . . . . . . . . . . . . . . . . 5
3. URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and "OPTIONAL" are Their Context . . . . . . . . . . . . . . 7
5.1 Phone Numbers . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1 Separators in Phone Numbers . . . . . . . . . . . . . . . . 7
5.1.2 Alphabetic Characters Corresponding to be interpreted Digits . . . . . . . 8
5.1.3 Alphabetic, * and \\# Characters as described Identifiers . . . . . . 8
5.1.4 Global Numbers . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.5 Local Numbers . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 ISDN Subaddresses . . . . . . . . . . . . . . . . . . . . . 10
5.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4 Other Parameters . . . . . . . . . . . . . . . . . . . . . . 11
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Why Not Just Put Telephone Numbers in SIP URIs? . . . . . . 11
7.2 Why Not Distinguish Between Call Types? . . . . . . . . . . 12
7.3 Why tel? . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4 Do Not Confuse Numbers with How They Are Dialed . . . . . . 12
8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . 12
9. Use of tel URIs with SIP (Informative) . . . . . . . . . . . 13
9.1 Local Translation . . . . . . . . . . . . . . . . . . . . . 14
9.2 Proxy Translation . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . 16
13. Changes Since RFC 2119 [1] 2806 . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and
indicate requirement levels for compliant implementations.

2 Copyright Statements . . . . . . . 19

Schulzrinne Expires August 15, 2004 [Page 2]

Internet-Draft The tel URI February 2004

1. Introduction

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 [4], [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 fixed or wireless and address
a fixed wired wired, mobile or nomadic terminal. The terminal addressed
can support any electronic communication service (ECS) including
voice, data or and 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:

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 [4], [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

H. Schulzrinne/A. Vaha-Sipila [Page 2]

Internet Draft The tel URI June 29, 2003 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 have multiple such identifiers.)
Dial string: "Dial strings" are the actual numbers, symbols and
pauses entered by a user to place a phone call. A dial-
string 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

Schulzrinne Expires August 15, 2004 [Page 3]

Internet-Draft The tel URI February 2004

of this document.

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 [5] [RFC3191] and RFC 3192 [6]. [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 [7]. [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

H. Schulzrinne/A. Vaha-Sipila [Page 3]

Internet Draft The tel URI June 29, 2003
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 [7] [RFC3261] requests. The
SIP specification also inherits the subscriber 'subscriber' part of the syntax
as part of the user element 'user element' in the SIP URI. Other protocols may

Schulzrinne Expires August 15, 2004 [Page 4]

Internet-Draft The tel URI February 2004

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.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.

3. URI Syntax

The URI is defined using the ABNF (augmented Backus-Naur form)
described in RFC 2234 [2] [RFC2234] and uses elements from the core
definitions (Appendix A of RFC 2234).

The syntax definition follows RFC 2396 [3], [RFC2396], indicating the
actual characters contained in the URI. Note that the reserved
characters "+", ";", "=", and "?" MUST NOT 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 [3]) [RFC2396]) are equivalent to their "% HEX HEX" encoding.

The "tel" URI has the following syntax:

Schulzrinne Expires August 15, 2004 [Page 5]

Internet-Draft The tel URI February 2004

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

H. Schulzrinne/A. Vaha-Sipila [Page 4]

Internet Draft The tel URI June 29, 2003
extension = ";ext=" 1*phonedigit
context = ";phone-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
mark = "-" | "_" | "." | "!" | "~" | "*" |
"'" | "(" | ")"
escaped = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT

Each parameter name ("pname"), the ISDN subaddress, the extension and
the context MUST NOT 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.

This simplifies comparison when the "tel" URI is compared
character-by-character, such as in SIP URIs [7].

4 [RFC3261].

4. URI Comparisons

Two "tel" URIs are equivalent according to the following rules:

o URI are not equal if one is a <local-number> 'local-number and the other a
<global-number>.
'global-number'.
o For mandatory additional parameters (Section 5.4) and the
<phone-context>
'phone-context' and <extension> 'extension' parameters defined in this
document, <phone-number> 'phone-number' parameter values are compared digit-
by-digit
digit-by-digit after removing all <visual-separator>s 'visual-separator's from

Schulzrinne Expires August 15, 2004 [Page 6]

Internet-Draft The tel URI February 2004

consideration.
o Parameters are compared according to <pname>, '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.

H. Schulzrinne/A. Vaha-Sipila [Page 5]

Internet Draft The tel URI June 29, 2003
o URI comparisons are case-insensitive.

All parameter names and values SHOULD use lower-case characters since
tel URIs may be used within contexts where comparisons are case-
sensitive.
case-sensitive.

Section 19.1.4 in the SIP specification [7] [RFC3261] discusses one
such case.

5. Phone Numbers and Their Context

5.1 Phone Numbers

The <subscriber> '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 phone-context 'phone-context' (Section 5.1.5).

Implementations MUST NOT assume that telephone numbers have a
maximum, minimum or fixed length, or that they always begin with a
certain number.

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."
[4] [E.164].

5.1.1 Separators in Phone Numbers

Phone numbers MAY contain visual separators. Visual separators
(<visual-separator>)
('visual-separator') merely aid readability and are not used for URI
comparison or placing a call.

H. Schulzrinne/A. Vaha-Sipila

Schulzrinne Expires August 15, 2004 [Page 6]

Internet Draft 7]

Internet-Draft The tel URI June 29, 2003 February 2004

Despite complicating comparisons, this specification retains the
visual separators to follow the spirit of RFC 2396 [3], [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 [8]
[RFC3187] use visual separators in a manner similar to this
specification.

Even though ITU-T E.123 [9] [E.123] recommends the use of space
characters as visual separators in printed telephone numbers,
"tel" URIs cannot use spaces to avoid excessive escaping.

5.1.2 Alphabetic Characters Corresponding to Digits

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
[10,11]
[E.161][T1.703] addressing this issue.

5.1.3 Alphabetic, * and # \\# Characters as Identifiers

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.

5.1.4 Global Numbers

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 [E.123] and E.164 [9,4]. [E.164].
Globally unique numbers have the property of being unambiguous
everywhere in the world and are RECOMMENDED.

5.1.5 Local Numbers

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

H. Schulzrinne/A. Vaha-Sipila [Page 7]

Internet Draft The tel URI June 29, 2003 set up the call by passing the number to the dialing
software. Digits needed for accessing an outside line, for example,

Schulzrinne Expires August 15, 2004 [Page 8]

Internet-Draft The tel URI February 2004

are not included in local numbers. Local numbers SHOULD NOT be used
unless there is no way to represent the number as a global number.

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 phone-context '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 phone-context
'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.

H. Schulzrinne/A. Vaha-Sipila [Page 8]

Internet Draft The tel URI June 29, 2003

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

Schulzrinne Expires August 15, 2004 [Page 9]

Internet-Draft The tel URI February 2004

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.

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.

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 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 MUST NOT
initiate the call and treat the URI like an invalid destination.

5.2 ISDN Subaddresses

A phone number MAY also contain an <isdn-subaddress> 'isdn-subaddress"> parameter which

H. Schulzrinne/A. Vaha-Sipila [Page 9]

Internet Draft The tel URI June 29, 2003
indicates an ISDN subaddress.

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

Schulzrinne Expires August 15, 2004 [Page 10]

Internet-Draft The tel URI February 2004

5.3 Extensions

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

5.4 Other Parameters

Future extensions to this URI scheme may add other parameters
(<parameter>
('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 MUST NOT 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, <parameter> '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.

Entities that forward protocol requests containing tel URIs with
optional parameters MUST NOT delete or modify parameters they do not
understand.

All new parameters MUST be registered with IANA.

6. Examples

tel:+358-555-1234567

tel:+1-201-555-0123 This URI points to a phone number in Finland. the United
States. The hyphens are included to make the number more
human-readable; they separate country, area codes and subscriber
number.

tel:7042;phone-context=cs.columbia.edu
tel:7042;phone-context=cs.columbia.edu: The URI describes a local
phone number valid within the context "cs.columbia.edu".

tel:863-1234;phone-context=+1-914-784
tel:863-1234;phone-context=+1-914-555: The URI describes a local
phone number that is valid within a particular phone prefix.

H. Schulzrinne/A. Vaha-Sipila [Page 10]

Internet Draft The tel URI June 29, 2003

7. Rationale

7.1 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

Schulzrinne Expires August 15, 2004 [Page 11]

Internet-Draft The tel URI February 2004

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.

7.2 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.

7.3 Why "tel"? 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.

7.4 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 MUST NOT 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 MUST NOT 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.

H. Schulzrinne/A. Vaha-Sipila [Page 11]

Internet Draft The tel URI June 29, 2003

8. 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.

Dial <a href="tel:+3585551234567">+358-555-1234567</a> href="tel:+1-212-555-0101">+1-212-555-0101</a>

Schulzrinne Expires August 15, 2004 [Page 12]

Internet-Draft The tel URI February 2004

for assistance.

instead of

Dial <a href="tel:+3585551234567">this href="tel:+1-212-555-0101">this number</a>
for assistance.

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.

Telephone (if dialing in Finland): the United States):
<a href="tel:+3585551234567">(0555) 1234567</a> href="tel:+1-201-555-0111">(201) 555-0111</a>

or even

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

9 IANA Considerations

"Tel"

9. Use of tel URIs with SIP (Informative)

SIP can use the "tel" URI parameters (<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:

o the parameter name;

o a description of its applicability;

o whether the parameter is mandatory or not ( Only the names of
mandatory parameters must start with "m-" as described in

H. Schulzrinne/A. Vaha-Sipila [Page 12]

Internet Draft The tel URI June 29, 2003

Section 5.4.);

o restrictions on the syntax of the parameter value in ABNF
form;

o a reference to the specification that defines it.

10 Security Considerations

The security considerations parallel those for the mailto URL [12].

A recipient of a "tel" URI SHOULD NOT 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.

o Calls may incur costs.

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

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

o 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.

A Use of "tel" URIs with SIP (Informative)

SIP can use the "tel" URI as a Request-URI, along 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 [7]). [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

H. Schulzrinne/A. Vaha-Sipila [Page 13]

Internet Draft The tel URI June 29, 2003
they cannot be represented as such. If the local-number format is
used, it MUST be qualified by the phone-context 'phone-context' parameter.
Effectively, the combination of local number and phone context makes
the tel URI globally unique.

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

Schulzrinne Expires August 15, 2004 [Page 13]

Internet-Draft The tel URI February 2004

to dialing shorter strings, e.g., for PBX extensions or local
numbers. These so-called dial-strings (Section 2) 1) 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 dial
plan. There are at least two appropriate ways to deal with dial
strings in SIP terminals: terminals, local translation and proxy translation,
described in turn below.

9.1 Local translation: 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 phone-
context 'phone-context' string when performing the
translation. If the
phone-context 'phone-context' is a domain name, there are
three cases:
1. 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.
2. 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

tel:1234;phone-context=munich.example.com

H. Schulzrinne/A. Vaha-Sipila [Page 14]

Internet Draft The tel URI June 29, 2003

to the SIP proxy located at 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.)
3. 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.

Schulzrinne Expires August 15, 2004 [Page 14]

Internet-Draft The tel URI February 2004

9.2 Proxy translation: Translation

In proxy translation mode, the SIP UA simply turns the dialed digits
into the user part of the SIP URI and appends a ;user=phone ';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:

sip:1234;phone-context=munich.example.com@example.com

sip:1234;phone-context=munich.example.com@example.com;user=phone

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

tel:1234;phone-context=munich.example.com

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

Since a single proxy may receive calls from many different
locations with different local dial plans,

H. Schulzrinne/A. Vaha-Sipila [Page 15]

Internet Draft The tel URI June 29, 2003 devices that rely on
the proxy for number translation SHOULD always be configured with
a context. Otherwise, for example, 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.

B Change History

B.1 Changes from ietf-00 to ietf-01

o Editorial changes suggested by Francois Audet.

o Added * and # as characters plan.

10. IANA Considerations

IANA is requested to local numbers.

B.2 Changes from -08 update the reference to draft-ietf-iptel-rfc2806bis-00

o Editorial clarifications.

o Remove multiple context descriptions.

B.3 Changes Since -07

o Added section on using tel URIs RFC 2806 in SIP.

B.4 Changes Since -06

o Clarified semantics.

o Removed context from freephone numbers.

o Added phone extensions.

B.5 Changes Since -05

o the URI
scheme registry for the 'tel' scheme to this document.

"Tel" URI comparisons are case-insensitive.

o Specified recommended order of parameters ('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:

Parameter name: The name used for the parameter, according to simplify use
within SIP URIs.

B.6 Changes Since -04

o ISDN subaddresses can contain any IA5 character the BNF
in Section 3.
Applicability: A brief description of its applicability.

Schulzrinne Expires August 15, 2004 [Page 15]

Internet-Draft The tel URI February 2004

Mandatory? Whether the parameter is mandatory or even binary
data; represented now as "uric".

B.7 Changes Since -03

o Clarified use not; only the names
of multiple contexts and how to express this, mandatory parameters must start with "m-" as described in
Section 5.4.;
Specification: A reference to the specification that defines the
parameter and its syntax.

11. Acknowledgments

This document is derived from RFC 2806 [RFC2806], written by Antti
V�h�-Sipil�. Flemming Andreasen, Francois Audet, Lawrence Conroy,
Cullen Jennings, Michael Hammer, Andrew Main, Xavier Marjou, Jon
Peterson, Mike Pierce, Jonathan Rosenberg and James Yu provided
extensive comments.

12. Security Considerations

The security considerations parallel those for the mailto URL
[RFC2368].

A recipient of a comma-separated list.

H. Schulzrinne/A. Vaha-Sipila [Page 16]

Internet Draft "tel" URI SHOULD NOT 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.

o Calls may incur costs.
o The tel URI June 29, 2003

B.8 Changes Since -02 may be used to place malicious or annoying calls.
o Clarifications and editorial fixes. A call will take the user's phone line off-hook, thus preventing
its use.
o Now, mandatory parameters are labeled, A call may reveal the user's, possibly unlisted, phone number to avoid making [13]
obsolete.

B.9
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.

13. Changes Since -01 RFC 2806

The draft specification is syntactically backwards-compatible with the
"tel" URI defined in RFC 2806 [RFC2806], but has been greatly simplified completely
rewritten. This document more clearly distinguishes telephone
numbers as identifiers of network termination points from dial
strings and removes the latter from the purview of "tel" URIs.
Compared to reflect parts that have
actually been implemented.

o Removed RFC 2806, references to carrier selection.

o Removed selection, dial context.

o Removed context,
fax and modem URIs.

o Removed URIs, post-dial strings.

o Removed pause characters.

B.10 Changes Since RFC 2806

The specification is backwards-compatible with RFC 2806.

o Editorial changes and clarifications. The document has been
shortened strings and reorganized. Most paragraphs pause characters have been rewritten
to be more concise.

o Syntax
removed. The URI syntax now conforms to RFC 2396 [3], [RFC2396].

A section on using tel URIs in particular related to
escaping.

C Acknowledgments

This document inherits a large amount of text from RFC 2806 [14].
Flemming Andreasen, Francois Audet, Lawrence Conroy, Andrew Main,
Michael Hammer, Jon Peterson, Mike Pierce, Jonathan Rosenberg and
James Yu provided extensive comments.

D References

E SIP was added.

Normative References

[1] S.

Schulzrinne Expires August 15, 2004 [Page 16]

Internet-Draft The tel URI February 2004

[E.123] , ITU., "Notation for national and international telephone
numbers, e-mail addresses and web addresses",
Recommendation E.123, February 2001.

[E.161] , ITU., "Arrangement of digits, letters and symbols on
telephones and other devices that can be used for gaining
access to a telephone network", Recommendation E.161, May
1995.

[E.164] , ITU., "The international public telecommunication
numbering plan", Recommendation E.164, May 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement
levels," Indicate
Requirement Levels", BCP 14, RFC 2119, Internet Engineering Task Force, Mar. March 1997.

[2]

[RFC2234] Crocker, D. Crocker and P. Overell, eds., "Augmented BNF for syntax

H. Schulzrinne/A. Vaha-Sipila [Page 17]

Internet Draft The tel URI June 29, 2003

specifications: ABNF," Syntax
Specifications: ABNF", RFC 2234, Internet Engineering Task Force,
Nov. 1997.

[3] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource
identifiers (URI): generic syntax," RFC 2396, Internet Engineering
Task Force, Aug. 1998.

F Informative References

[4] International Telecommunication Union, "The international public
telecommunication numbering plan," Recommendation E.164,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
May November 1997.

[5] C.

[RFC3191] Allocchio, C., "Minimal GSTN address format in internet mail," Internet
Mail", RFC 3191, Internet Engineering Task Force, Oct. October 2001.

[6] C.

[RFC3192] Allocchio, C., "Minimal FAX address format in internet mail," Internet
Mail", RFC 3192, Internet Engineering Task Force, Oct. October 2001.

[7] J.

[RFC3261] Rosenberg, H. J., Schulzrinne, G. H., Camarillo, A. G., Johnston, J.
A., Peterson, R. J., Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.

[8] J. Hakala and H. Walravens, "Using international standard book
numbers as uniform resource names," RFC 3187, Internet Engineering
Task Force, Oct. 2001.

[9] International Telecommunication Union, "Notation for national and
international phone numbers," Recommendation E.123, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1998.

[10] International Telecommunication Union, "Arrangement of digits,
letters and symbols on telephones R., Handley, M. and other devices that can be used
for gaining access to a telephone network," Recommendation E.161,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
May 1995.

[11] ANSI, E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.

[T1.703] , ANSI., "Allocation of letters Letters to the keys Keys of numeric keypads Numeric
Keypads for
telecommunications," Telecommunications", Standard T1.703-1995
(R1999), ANSI, 1999.

[12] P.

Informative References

[I-D.yu-tel-url]
Yu, J., "New Parameters for the 'tel' URL to Support
Number Portability and Freephone Service",
draft-yu-tel-url-08 (work in progress), November 2003.

[RFC2368] Hoffman, L. P., Masinter, L. and J. Zawinski, "The mailto URL
scheme,"
scheme", RFC 2368, Internet Engineering Task Force, July 1998.

[13] J. Yu, "Extensions to the 'tel' URL to support number
portability

[RFC2396] Berners-Lee, T., Fielding, R. and freephone service," Internet Draft, Internet
Engineering Task Force, Aug. 2002. Work in progress.

H. Schulzrinne/A. Vaha-Sipila [Page 18]

Internet Draft The tel URI June 29, 2003

[14] A. L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

[RFC2806] Vaha-Sipila, A., "URLs for telephone calls," Telephone Calls", RFC 2806, Internet
Engineering Task Force, Apr.
April 2000.

G Authors' Addresses

Schulzrinne Expires August 15, 2004 [Page 17]

Internet-Draft The tel URI February 2004

[RFC3187] Hakala, J. and H. Walravens, "Using International Standard
Book Numbers as Uniform Resource Names", RFC 3187, October
2001.

Author's Address

Henning Schulzrinne
Dept.
Columbia University
Department of Computer Science
Columbia University
1214 Amsterdam Avenue
450 Computer Science Building
New York, NY 10027
USA
electronic mail: schulzrinne@cs.columbia.edu

Antti Vaha-Sipila
(ISO 8859-15 quoted-printable: Antti V=E4h=E4-Sipil=E4)
Nokia Mobile Phones
P. O. Box 321
FIN-00045 Nokia Group
Finland
electronic mail: avs@iki.fi, antti.vaha-sipila@nokia.com

H Full Copyright Notice
US

Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu

Schulzrinne Expires August 15, 2004 [Page 18]

Internet-Draft The tel URI February 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in standards-track and
standards-related documentation IETF Documents can
be found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are

H. Schulzrinne/A. Vaha-Sipila [Page 19]

Internet Draft The tel URI June 29, 2003

included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, patent applications, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not proprietary
rights that may cover technology that may be
revoked by required to implement
this standard. Please address the Internet Society or its successors or assigns. information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

H. Schulzrinne/A. Vaha-Sipila [Page 20]

Table of Contents

1 Terminology ......................................... 2
2 Introduction ........................................ 2
3 URI Syntax .......................................... 4
4 URI Comparisons ..................................... 5
5 Phone Numbers

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and Their Context ..................... 6
5.1 Phone Numbers ....................................... 6
5.1.1 Separators restrictions contained in Phone Numbers ......................... 6
5.1.2 Alphabetic Characters Corresponding to Digits ....... 7
5.1.3 Alphabetic, * BCP 78, and # Characters
except as Identifiers ....... 7
5.1.4 Global Numbers ...................................... 7
5.1.5 Local Numbers ....................................... 7
5.2 ISDN Subaddresses ................................... 9
5.3 Extensions .......................................... 10
5.4 Other Parameters .................................... 10
6 Examples ............................................ 10
7 Rationale ........................................... 11
7.1 Why Not Just Put Telephone Numbers in SIP URIs?
................................................................ 11
7.2 Why Not Distinguish Between Call Types? ............ 11
7.3 Why "tel"? ......................................... 11
7.4 Do Not Confuse Numbers with How They Are Dialed ..... 11
8 Usage of Telephone URIs in HTML ..................... 12
9 IANA Considerations ................................. 12
10 Security Considerations ............................. 13
A Use of "tel" URIs with SIP (Informative) ............ 13
B Change History ...................................... 16
B.1 Changes from ietf-00 to ietf-01 ..................... 16
B.2 Changes from -08 to draft-ietf-iptel-rfc2806bis-00
................................................................ 16
B.3 Changes Since -07 ................................... 16
B.4 Changes Since -06 ................................... 16
B.5 Changes Since -05 ................................... 16
B.6 Changes Since -04 ................................... 16
B.7 Changes Since -03 ................................... 16
B.8 Changes Since -02 ................................... 17
B.9 Changes Since -01 ................................... 17
B.10 Changes Since set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC 2806 .............................. 17
C Acknowledgments ..................................... 17
D References .......................................... 17
E Normative References ................................ 17
F Informative References .............................. 18

H. Schulzrinne/A. Vaha-Sipila [Page 1] Editor function is currently provided by the
Internet Draft The tel URI June 29, 2003

G Authors' Addresses .................................. 19
H Full Copyright Notice ............................... 19

H. Schulzrinne/A. Vaha-Sipila Society.

Schulzrinne Expires August 15, 2004 [Page 2] 19]

----