Internet Engineering Task Force
Internet Draft H. Schulzrinne/A. Vaha-Sipila
Columbia U./Nokia
draft-antti-rfc2806bis-05.txt
June 18, 2002
Expires: December 2002
The tel URI for Telephone Calls
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
H. Schulzrinne/A. Vaha-Sipila [Page 1]
Internet Draft RFC2806bis June 18, 2002
Abstract
This document is a revision of RFC 2806.
This document specifies the URI (Uniform Resource Identifier) scheme
"tel" for specifying the address of a terminal in the phone network.
The tel URI is service-independent and describes voice calls (phone
calls, answering machines and voice messaging systems), facsimile
(telefax) calls and data calls, for landline, ISDN and mobile
subscribers.
1 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 RFC 2119 [1] and
indicate requirement levels for compliant implementations.
2 Introduction
This document defines the URI scheme "tel" that contains telephone
numbers. The telephone number can refer to terminals in the telephone
network or the Internet, mobile and landline devices, voice, data and
fax devices. The URI can refer to originators or targets of a
telephone call.
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: The telephone number is understood here as
the canonical address-of-record, as they are handled by the
signaling network. Generally, this means E.164 numbers, or
numbers that can be trivially converted into them.
Subscribers publish a phone number as a universal means of
being reached.
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. Dial strings are
beyond the scope of this document.
H. Schulzrinne/A. Vaha-Sipila [Page 2]
Internet Draft RFC2806bis June 18, 2002
To reach a telephone number from a particular terminal, the user of
the terminal or the terminal itself has to know how to convert that
telephone number into a dial string appropriate for that terminal.
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 prefixing a "00" to reach a number in a foreign
country. Telephone numbers are also the normalized way that addresses
are signaled in the PSTN.
The notation for phone numbers is the same as in RFC 2303 [2] and RFC
2304 [3]. However, the syntax differs since this document describes
URIs whereas RFC 2303 and RFC 2304 specify electronic mail addresses.
RFC 2303 and RFC 2304 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 SIP URI
conventions [4].
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, by sending DTMF digits, waiting for
dial tone, pausing and generating post-dial DTMF digits after the
callee picks up. Another approach has the URI specify the telephone
number, which can be either globally unique or only be valid within a
local context. A dialer 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 dialer then
converts the telephone number into a dial string 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 extensions on a PBX (when direct inward dialing is not used)
or electronic banking, cannot be specified in a URI.
The URI is used as a request URI in SIP [4] requests. The SIP
specification also inherits the subscriber part of the syntax as part
of the user element in the SIP URI. Other protocols may use this URI
for both query-based and prefix-based applications.
A "client" is defined as software that can parse one or more of the
URIs defined in this document and possibly place a call to a remote
entity.
3 URI Comparisons
H. Schulzrinne/A. Vaha-Sipila [Page 3]
Internet Draft RFC2806bis June 18, 2002
URI comparisons are case-sensitive except that the scheme and
parameter names are case-insensitive.
4 URI Syntax
The URI is defined using the ABNF (augmented Backus-Naur form)
described in RFC 2234 [5] and uses elements from the core definitions
(Appendix A of RFC 2234).
The syntax definition follows RFC 2396 [6], 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 [6]) are equivalent to their "% HEX HEX" encoding.
The "tel" URI has the following syntax:
telephone-uri = "tel:" subscriber *param |
subscriber = global-number / local-number |
global-number = global-number-part [isdn-subaddress] |
global-number-part = "+" 1*phonedigit |
local-number = local-number-part [isdn-subaddress] |
[context] |
local-number-part = 1*phonedigit |
isdn-subaddress = ";isub=" 1*uric |
context = ";phone-context=" descriptor *("," descriptor) |
descriptor = domainname / global-number-part |
domainname = *( domainlabel "." ) toplabel [ "." ] |
domainlabel = alphanum |
/ alphanum *( alphanum / "-" ) alphanum |
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum |
param = ";" pname ["=" pvalue ] |
pname = 1*uric |
pvalue = *uric |
phonedigit = HEXDIG / visual-separator |
visual-separator = "-" / "." / "(" / ")" |
alphanum = ALPHA / DIGIT |
5 Phone Numbers and Their Scope
5.1 Phone Numbers
H. Schulzrinne/A. Vaha-Sipila [Page 4]
Internet Draft RFC2806bis June 18, 2002
The <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.
Implementations MUST NOT assume that telephone numbers have a
maximum, minimum or fixed length, or that they always begin with a
certain number.
5.1.1 Separators in Phone Numbers
Phone numbers MAY contain visual separators. Visual separators
(<visual-separator>) merely aid readability and MUST be ignored by
the client.
Even though ITU-T E.123 [7] recommends the use of space characters as
visual separators in printed telephone numbers, tel URIs MUST NOT use
spaces.
5.1.2 Alphabetic Characters
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
[8,9] addressing this issue.
Since called and calling terminal numbers (TNs) are encoded in BCD in
ISUP, this allows for six additional values per digit, sometimes
represented as the hexadecimal characters A through F. However, in
accordance with E.164, they may not be included in global numbers.
Their use in local numbers is not defined, but it not prohibited.
5.1.3 Global and Local Numbers
Global (international) numbers are identified by the "+" character
prefix. Global numbers MUST be composed with the country (CC) and
national (NSN) numbers as specified in E.123 and E.164 [7,10].
International numbers have the property of being unambiguous
everywhere in the world and are RECOMMENDED.
Local numbers only work within a certain geographical area or a
H. Schulzrinne/A. Vaha-Sipila [Page 5]
Internet Draft RFC2806bis June 18, 2002
certain part of the telephone network, e.g., a private branch
exchange (PBX) 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.
The phone-context parameter can be used to unambiguously identify the |
local context where the local number is valid. The parameter value is |
defined by the "owner" of the local number. The parameter can |
contain a list of contexts that enumerate all the contexts where this |
number is valid. It does NOT in any way indicate a prefix that turns |
the local number into a global (E.164) number. The phone-context |
provides a unique identifier that lets a client know whether it can |
interpret the local number or not. It has not other meaning or |
function. |
There are two ways to label the context: via a global number prefix |
(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 a global number prefix or domain name is |
a valid identifier for a particular local number. |
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 assigned |
number. It is up to the administrator to assign an |
appropriate identifier and to use it consistently. In many |
cases, an organization can choose many different |
identifiers. |
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. |
For example, ";phone-context=+1,+49" indicates that the number is |
valid in country codes 1 (North America) and 49 (Germany). For a |
local number valid 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 number may be |
suitable, or a substring that is completely occupied by the |
organization. For example, +49-6151-16 would be a suitable prefix for |
the TU Darmstadt, as it uses all numbers starting with those digits. |
The global number prefix does not imply that adding it to the number |
will generate a valid E.164 number. It might by coincidence, but this |
cannot be relied upon. (For example, "911" should be labeled with the |
H. Schulzrinne/A. Vaha-Sipila [Page 6]
Internet Draft RFC2806bis June 18, 2002
context "+1", but "+1-911" is not a valid E.164 number.) As noted |
earlier, numbers can be represented as valid E.164 numbers SHOULD NOT |
be represented as local numbers plus phone-context.
5.2 ISDN Subaddresses
A phone number MAY also contain an <isdn-subaddress> parameter which |
indicates an ISDN subaddress. This parameter is mandatory, i.e., a |
client MUST reject the URI if it cannot interpret ISDN subaddresses. |
ISDN subaddresses typically contain IA5 characters, but may contain |
any octet value.
5.3 Other Parameters
Future extensions to this URI scheme may add other parameters
(<param> 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, <param> 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.
6 Examples
tel:+358-555-1234567
This URI points to a phone number in Finland capable of
receiving voice calls. 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
The URI describes a local phone number valid within the
context "cs.columbia.edu".
tel:863-1234;phone-context=+1-914-784
The URI describes a local phone number that is valid within
a particular phone prefix. (The example approximates the
H. Schulzrinne/A. Vaha-Sipila [Page 7]
Internet Draft RFC2806bis June 18, 2002
IBM tie line numbering system.)
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 |
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.
7.3 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.
7.4 Do Not Confuse Numbers with How They Are Dialed
As an example, the E.164 number "+123456789" will be dialed in many
countries as 00123456789, 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 00123456789, as the
transformation back to an international number is not guaranteed to
be correct or unique.
If a client 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.
When overlap signaling is used, devices which collect dial strings
H. Schulzrinne/A. Vaha-Sipila [Page 8]
Internet Draft RFC2806bis June 18, 2002
MUST construct a complete phone number before constructing the tel
URI and including the URI in a network request. In other words, such
devices must convert from overlap dialing to en bloc signaling.
8 Usage of Telephone URIs in HTML
The number SHOULD be visible to the end user if it is conceivable
that the user might not have a client which is able to use these
URIs.
Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>
On a public HTML page, the telephone number in the URI SHOULD always
be in the international form, even if the text of the link uses some
local format.
Telephone: <a href="tel:+3585551234567">(0555) 1234567</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" URI parameters (<param>) MUST be registered with IANA. Any
parameter that should be considered as mandatory should be prefixed
by "m-" as described in Section 5.3. Mandatory parameters must be
described in an informational or standards-track RFC.
10 Security Considerations
The security considerations parallel those for the mailto URL [11].
A client 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.
H. Schulzrinne/A. Vaha-Sipila [Page 9]
Internet Draft RFC2806bis June 18, 2002
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 client's phone number with
other information such as the e-mail or IP address.
o A call may use the same local number in different contexts, in
which the number may have a different meaning.
11 Change History
11.1 Changes Since -04
o ISDN subaddresses can contain any IA5 character or even binary
data; represented now as "uric".
11.2 Changes Since -03
o Clarified use of multiple contexts and how to express this, as
a comma-separated list.
11.3 Changes Since -02
o Clarifications and editorial fixes.
o Now, mandatory parameters are labeled, to avoid making [12]
obsolete.
11.4 Changes Since -01
The draft has been greatly simplified to reflect parts that have
actually been implemented.
o Removed references to carrier selection.
o Removed dial context.
o Removed fax and modem URIs.
o Removed post-dial strings.
o Removed pause characters.
11.5 Changes Since RFC 2806
H. Schulzrinne/A. Vaha-Sipila [Page 10]
Internet Draft RFC2806bis June 18, 2002
The specification is backwards-compatible with RFC 2806.
o Editorial changes and clarifications. The document has been
shortened and reorganized. Most paragraphs have been rewritten
to be more concise.
o Syntax now conforms to RFC 2396 [6], in particular related to
escaping.
12 Acknowledgments
This document inherits a large amount of text from RFC 2806 [13].
Flemming Andreasen, Francois Audet, Lawrence Conroy, Jon Peterson,
Mike Pierce and James Yu provided extensive comments.
13 Authors' Addresses
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
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
14 Bibliography
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[2] C. Allocchio, "Minimal PSTN address format in internet mail," RFC
2303, Internet Engineering Task Force, Mar. 1998.
[3] C. Allocchio, "Minimal FAX address format in internet mail," RFC
2304, Internet Engineering Task Force, Mar. 1998.
[4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," RFC 2543, Internet Engineering Task
Force, Mar. 1999.
H. Schulzrinne/A. Vaha-Sipila [Page 11]
Internet Draft RFC2806bis June 18, 2002
[5] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
specifications: ABNF," RFC 2234, Internet Engineering Task Force,
Nov. 1997.
[6] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource
identifiers (URI): generic syntax," RFC 2396, Internet Engineering
Task Force, Aug. 1998.
[7] International Telecommunication Union, "Notation for national and
international phone numbers," Recommendation E.123, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1998.
[8] International Telecommunication Union, "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,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
May 1995.
[9] ANSI, "Allocation of letters to the keys of numeric keypads for
telecommunications," Standard T1.703-1995 (R1999), ANSI, 1999.
[10] International Telecommunication Union, "The international public
telecommunication numbering plan," Recommendation E.164,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
May 1997.
[11] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL
scheme," RFC 2368, Internet Engineering Task Force, July 1998.
[12] J. Yu, "Extensions to the 'tel' and 'fax' URLs to support number
portability and freephone service," Internet Draft, Internet
Engineering Task Force, Mar. 2002. Work in progress.
[13] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet
Engineering Task Force, Apr. 2000.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
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 implementation 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
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
H. Schulzrinne/A. Vaha-Sipila [Page 12]
Internet Draft RFC2806bis June 18, 2002
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, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 13]
Table of Contents
1 Terminology ......................................... 2
2 Introduction ........................................ 2
3 URI Comparisons ..................................... 3
4 URI Syntax .......................................... 4
5 Phone Numbers and Their Scope ....................... 4
5.1 Phone Numbers ....................................... 4
5.1.1 Separators in Phone Numbers ......................... 5
5.1.2 Alphabetic Characters ............................... 5
5.1.3 Global and Local Numbers ............................ 5
5.2 ISDN Subaddresses ................................... 7
5.3 Other Parameters .................................... 7
6 Examples ............................................ 7
7 Rationale ........................................... 8
7.1 Why Not Just Put Telephone Numbers in SIP URIs? .... 8 |
7.2 Why Not Distinguish Between Call Types? ............ 8
7.3 Why "tel"? ......................................... 8
7.4 Do Not Confuse Numbers with How They Are Dialed ..... 8
8 Usage of Telephone URIs in HTML ..................... 9
9 IANA Considerations ................................. 9
10 Security Considerations ............................. 9
11 Change History ...................................... 10
11.1 Changes Since -04 ................................... 10
11.2 Changes Since -03 ................................... 10
11.3 Changes Since -02 ................................... 10
11.4 Changes Since -01 ................................... 10
11.5 Changes Since RFC 2806 .............................. 10
12 Acknowledgments ..................................... 11
13 Authors' Addresses .................................. 11
14 Bibliography ........................................ 11
H. Schulzrinne/A. Vaha-Sipila [Page 1]
