Internet Engineering Task Force
Internet Draft Schulzrinne/Vaha-Sipila
Columbia U./Nokia
draft-antti-rfc2806bis-02.txt
February 17, 2002
Expires: July 2002
URIs 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.
Schulzrinne/Vaha-Sipila [Page 1]
Internet Draft RFC2806bis February 17, 2002
Abstract
This document is a revision of RFC 2806.
This document specifies the URI (Uniform Resource Identifier) schemes
"tel" for specifying the address of a terminal in the phone network.
This document covers 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.
The telephone number is understood 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. This differs from "dial strings", the actual numbers, symbols
and pauses entered by a user to place a phone call. Dial strings are
beyond the scope of this document.
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 DTMF tones to handle local PBXs,
and they may include post-dial DTMF signaling that could control an
IVR.
Telephone numbers, however, are addresses-of-record. Subscribers
publish a phone number as a universal means of being reached. To
reach a telephone number from a particular terminal, the user of that
terminal or terminal has to know how to convert my telephone number
into a dial string appropriate for that terminal. The telephone
number itself does not convey what needs to be done in a local
network, such as dialing '9' before placing a call, in order to reach
the number. Telephone numbers are also the normalized way that
Schulzrinne/Vaha-Sipila [Page 2]
Internet Draft RFC2806bis February 17, 2002
addresses are signaled in the PSTN.
The notation for phone numbers is the same as in RFC 2303 [4] and RFC
2304 [5]. 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
schemes described here use the semicolon, in keeping with SIP URI
conventions [6].
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. A dialer application is aware of 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 or electronic banking, cannot be
specified in a URI.
The URI is used as a request URI in SIP [6] 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
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 [7] and uses elements from the core definitions
(Appendix A of RFC 2234).
Schulzrinne/Vaha-Sipila [Page 3]
Internet Draft RFC2806bis February 17, 2002
The syntax definition follows RFC 2396, 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 schemes.
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) are equivalent to their "% HEX HEX" encoding.
The "tel" URI has the following syntax:
telephone-uri = "tel:" subscriber
subscriber = global-number / local-number
global-number = "+" 1*phonedigit [isdn-subaddress]
*other
local-number = 1*(phonedigit / HEXDIGIT )
[isdn-subaddress]
context *other
isdn-subaddress = ";isub=" 1*phonedigit
context = ";context-tag=" 1*uric
other = ";" oname "=" ovalue
oname = 1*uric
ovalue = *uric
phonedigit = DIGIT / visual-separator
visual-separator = "-" / "." / "(" / ")"
5 Phone Numbers and Their Scope
5.1 Phone Numbers
The <subscriber> part of the URI indicates the number. The phone
number can be written in either global (E.164) or local notation.
All phone numbers SHOULD be written in the international form unless
they cannot be written. Private dialing 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 written in international form.
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
Schulzrinne/Vaha-Sipila [Page 4]
Internet Draft RFC2806bis February 17, 2002
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 [2] 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 since the
mapping from alphabetic characters to digit is not standardized.
Since terminal numbers (TNs) are encoded in BCD in ISUP, the
characters "A" through "F" ("F" is currently not used) are also
allowed. These do not designate the fourth column of the DTMF tone
matrix.
5.1.3 Global and Local Numbers
Global (international) numbers are identified by the "+" character
prefix. International numbers MUST be written with the country (CC)
and national (NSN) numbers as specified in E.123 and E.164 [2,9].
International numbers have the property of being unambiguous
everywhere in the world if the client is properly configured and are
RECOMMENDED.
Local numbers only work within a certain geographical area or a
certain part of the telephone network, e.g., a private branch
exchange (PBX). Some numbers may work from several networks but not
from the whole world; these SHOULD be written in international form.
URIs with local phone numbers should only appear environments where
all local entities can successfully set up the call by passing the
number to the dialing software as written.
The phone-context parameter can be used to label the dialing context.
The parameter value is implementation-defined; care must be taken
that the URL does not "escape" the administrative domain that
administers the namespace. [TBD: This is hardly satisfying.]
Alternatively, a domain-name identifier can be used, e.g.,
"houston.example.com".
5.2 ISDN Subaddresses
A phone number MAY also contain an <isdn-subaddress> parameter which
indicates an ISDN subaddress. The client SHOULD support ISDN
Schulzrinne/Vaha-Sipila [Page 5]
Internet Draft RFC2806bis February 17, 2002
subaddresses if it supports ISDN call setup. If ISDN subaddressing is
not supported by the caller, <isdn-subaddress> MUST be ignored and
the user SHOULD be notified. The user or the client MAY opt not to
place a call if this feature is not supported.
5.3 Other Parameters
Future extensions to these URI schemes may add other parameters
(<other> in the BNF). Such parameters can be either mandatory or
optional. Optional parameters start with "o-". An implementation MAY
ignore such parameters. Other parameters are mandatory; an
implementation MUST NOT use the URI if it contains unknown mandatory
parameters.
For example, <other> 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.
7 Rationale
7.1 Why Not Distinguish Between Call Types?
TBD.
Signaling protocols such as SIP allow to negotiate the call type and
parameters, making the very basic indication within the URL scheme
moot.
7.2 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.3 Why Use E.164-style Numbering?
Schulzrinne/Vaha-Sipila [Page 6]
Internet Draft RFC2806bis February 17, 2002
E.164 refers to international telephone numbers, and the string of
digits after the country code is usually a national matter. Phone
numbers are usually written as a simple string of numbers everywhere.
Because of this, the syntax in this specification is intuitively
clear to most people. This is the usual way to write phone numbers in
business cards, advertisements, telephone books and so on.
Not all phone numbers can be expressed this way. Some numbers, such
as emergency numbers, must always be dialled as written, without
prepending area or country codes.
Also, when writing the phone number in the form described in this
specification, the writer does not need to know which part of the
number is the country code and which part is the area code. If a
hierarchical URI would be used (with a "/" character separating the
parts of the phone numbers), the writer of the URI would have to know
which parts are which.
Finally, when phone numbers are written in the international form as
specified here, they are unambiguous and can always be converted to
the local dialing convention, given that the user agent has the
knowledge of the local country and area codes.
7.4 Equipment Diversity
There are several ways for the subscriber to dial a phone number:
Pulse dialing: Usually pulse dialing method has only to be used
to set up the call; after connecting to the remote entity,
<post-dial> can be sent to the callee using DTMF, because
it will typically be processed by the callee, not the
telephone network.
DTMF: Two-tone combinations are sent in-band to the telephone
switching equipment.
Direct network signalling: ISDN subscribers and mobile phones
usually signal via a separate packet (signaling) channel.
There is no dial tone (or if there is, it is generated
locally by the equipment).
7.5 Do Not Confuse Numbers with How They Are Dialled
As an example, +123456789 will be dialled in many countries as
00123456789, where the leading "00" is a prefix for international
calls. Tel URIs should, in general, not contain local phone numbers
such as 00123456789, as the transformation back to an international
number is not guaranteed to be correct or unique. If a client
Schulzrinne/Vaha-Sipila [Page 7]
Internet Draft RFC2806bis February 17, 2002
receives a telephony URI with a local number in it, 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 telephony 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
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 more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-
OK</a>.
9 IANA Considerations
<Other> parameters MUST be registered with IANA.
10 Security Considerations
The security considerations parallel those for the mailto URL [11].
Schulzrinne/Vaha-Sipila [Page 8]
Internet Draft RFC2806bis February 17, 2002
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.
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.
The client SHOULD NOT rapidly redial busy numbers to avoid the
congestion of the (signaling) network. The client SHOULD detect if
the number is unavailable or if the call is terminated before the
dialing string has been completely processed (for example, the call
is terminated while waiting for user input) and not try to call
again, unless instructed by the user.
11 Changes Since RFC 2806
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, in particular related to
escaping.
12 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.
Schulzrinne/Vaha-Sipila [Page 9]
Internet Draft RFC2806bis February 17, 2002
o Removed post-dial strings.
o Removed pause characters.
13 Acknowledgements
This document inherits a large amount of text from RFC 2806 [12].
Mike Pierce and Jon Peterson provided extensive comments.
14 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
15 Bibliography
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[2] International Telecommunication Union, "Notation for national and
international phone numbers," Recommendation E.123, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1998.
[3] National Communications System, "Glosssary of telecommunications
terms," Federal Standard FED-STD-1037C, National Communications
System Technology and Standards Division, 1996.
[4] C. Allocchio, "Minimal PSTN address format in internet mail,"
Request for Comments 2303, Internet Engineering Task Force, Mar.
1998.
[5] C. Allocchio, "Minimal FAX address format in internet mail,"
Request for Comments 2304, Internet Engineering Task Force, Mar.
1998.
Schulzrinne/Vaha-Sipila [Page 10]
Internet Draft RFC2806bis February 17, 2002
[6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
[7] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
specifications: ABNF," Request for Comments 2234, Internet
Engineering Task Force, Nov. 1997.
[8] International Telecommunication Union, "Facsimile routing
utilizing the subaddress," Recommendation T.33, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, July 1996.
[9] International Telecommunication Union, "The international public
telecommunication numbering plan," Recommendation E.164,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
May 1997.
[10] N. Freed, J. Klensin, and J. Postel, "Multipurpose internet mail
extensions (MIME) part four: Registration procedures," Request for
Comments 2048, Internet Engineering Task Force, Nov. 1996.
[11] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL
scheme," Request for Comments 2368, Internet Engineering Task Force,
July 1998.
[12] A. Vaha-Sipila, "URLs for telephone calls," Request for Comments
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
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
Schulzrinne/Vaha-Sipila [Page 11]
Internet Draft RFC2806bis February 17, 2002
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.
Schulzrinne/Vaha-Sipila [Page 12]
Table of Contents
1 Terminology ......................................... 2
2 Introduction ........................................ 2
3 URI Comparisons ..................................... 3
4 URI Syntax .......................................... 3
5 Phone Numbers and Their Scope ....................... 4
5.1 Phone Numbers ....................................... 4
5.1.1 Separators in Phone Numbers ......................... 4
5.1.2 Alphabetic Characters ............................... 5
5.1.3 Global and Local Numbers ............................ 5
5.2 ISDN Subaddresses ................................... 5
5.3 Other Parameters .................................... 6
6 Examples ............................................ 6
7 Rationale ........................................... 6
7.1 Why Not Distinguish Between Call Types? ............ 6
7.2 Why "tel"? ......................................... 6
7.3 Why Use E.164-style Numbering? ..................... 6
7.4 Equipment Diversity ................................. 7
7.5 Do Not Confuse Numbers with How They Are Dialled .... 7
8 Usage of Telephone URIs in HTML ..................... 8
9 IANA Considerations ................................. 8
10 Security Considerations ............................. 8
11 Changes Since RFC 2806 .............................. 9
12 Changes Since -01 ................................... 9
13 Acknowledgements .................................... 10
14 Authors' Addresses .................................. 10
15 Bibliography ........................................ 10
Schulzrinne/Vaha-Sipila [Page 1]
