understand.
6. Examples
tel:+1-201-555-0123: This URI points to a phone number in the United
States. The hyphens are included to make the number more human
readable; they separate country, area code and subscriber number.
tel:7042;phone-context=example.com: The URI describes a local phone
number valid within the context "example.com".
tel:863-1234;phone-context=+1-914-555: The URI describes a local
phone number that is valid within a particular phone prefix.
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 E.164 number ("ENUM") translation
[RFC3761], some other signaling protocols such as H.323, or a
traditional circuit-switched call initiated on the client side via,
say, the Telephony Application Programming Interface (TAPI). Thus,
in spirit, it is 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 negotiating the call type and
parameters, making the very basic indication within the URI 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" was chosen because it is widely recognized that none of the
other suggestions appeared appropriate. "Callto" was discarded
because URI schemes locate a resource and do not specify an action to
be taken. "Telephone" and "phone" were considered too long and not
easily recognized internationally.
7.4. Do Not Confuse Numbers with How They Are Dialed
As an example, in many countries the E.164 number "+1-212-555-3141"
will be dialed as 00-1-212-555-3141, where the leading "00" is a
prefix for international calls. (In general, a "+" symbol in E.164
indicates that an international prefix is required.)
8. Usage of Telephone URIs in HTML
Links using the "tel" URI SHOULD enclose the telephone number so that
users can easily predict the action taken when following the link
Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for
assistance.
instead of
Dial <a 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 dialling in the United States):
<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. Use of "tel" URIs with SIP (Informative)
SIP can use the "tel" URI anywhere a URI is allowed, for example 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 [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 [RFC3219]. However, a proxy server could also delegate
this translation task to any other proxy server, as proxy servers are
free to apply whatever routing logic they desire. For local numbers,
the proxy MUST NOT translate "tel" URIs whose contexts it does not
understand.
As noted earlier, all phone numbers MUST use the global form unless
they cannot be represented as such. If the local-number format is
used, it MUST be qualified by the ’phone-context’ parameter.
Effectively, the combination of local number and phone context makes
the "tel" URI globally unique.
Although web pages, vCard business cards, address books, and
directories can easily contain global "tel" URIs, users on twelve-
button (IP) phones cannot dial such numbers directly and are
typically accustomed to dialling shorter strings, e.g., for PBX
extensions or local numbers. These so-called dial strings (section
1) are not directly represented by "tel" URIs, as noted. We refer to
the rules that govern the translation of dial strings into SIP and
"tel" URIs, global or local, as the dial plan. Currently,
translations from dial strings to "tel" URIs have to take place in
end systems. Future efforts may provide means to carry dial strings
in a SIP URI, for example, but no such mechanisms exist as of this
writing.
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,
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
his home network. Generally, dialed numbers 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
dialling 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 without a direct global equivalent may well behave
differently. To avoid any ambiguity, the dial plan MUST insert a
suitable ’phone-context’ string when performing the translation. If
the ’phone-context’ is a domain name, there are three cases:
1. The outbound proxy recognizes the domain name in the "tel" or 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
to the SIP proxy located at munich.example.com. (Proxies
receiving a tel URI with a context they do not understand are
obligated to return a 404 (Not Found) status response 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 for that phone context. In
that case, the translation fails, and the outbound proxy returns
a 404 (Not Found) error response.
10. Acknowledgments
This document is derived from RFC 2806 [RFC2806], written by Antti
Vaehae-Sipilae. Mark Allman, Flemming Andreasen, Francois Audet,
Lawrence Conroy, Cullen Jennings, Michael Hammer, Paul Kyzivat,
Andrew Main, Xavier Marjou, Jon Peterson, Mike Pierce, Jonathan
Rosenberg, and James Yu provided extensive comments.
11. Security Considerations
The security considerations parallel those for the mailto URL
[RFC2368].
Web clients and similar tools MUST NOT use the "tel" URI to place
telephone calls without the explicit consent of the user of that
client. 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 an e-mail or IP address.
This is particularly important for "tel" URIs embedded in HTML links,
as a malicious party may hide the true nature of the URI in the link
text, as in
<a href="tel:+1-900-555-0191">Find free information here</a>
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>
"tel" URIs may reveal private information, similar to including phone
numbers as text. However, the presence of the tel: schema identifier
may make it easier for an adversary using a search engine to discover
these numbers.
12. Changes Since RFC 2806
The specification is syntactically backwards-compatible with the
"tel" URI defined in RFC 2806 [RFC2806] but has been 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 RFC 2806, references to carrier selection, dial context,
fax and modem URIs, post-dial strings, and pause characters have been
removed. The URI syntax now conforms to RFC 2396 [RFC2396].
A section on using "tel" URIs in SIP was added.
13. References
13.1. Normative References
[E.123] International Telecommunications Union, "Notation for
national and international telephone numbers, e-mail
addresses and web addresses", Recommendation E.123,
February 2001.
[E.161] International Telecommunications 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, May 1995.
[E.164] International Telecommunications Union, "The international
public telecommunication numbering plan", Recommendation
E.164, May 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[T1.703] ANSI, "Allocation of Letters to the Keys of Numeric
Keypads for Telecommunications", Standard T1.703-1995
(R1999), 1999.
13.2. Informative References
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
URL scheme", RFC 2368, July 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
April 2000.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard
Book Numbers as Uniform Resource Names", RFC 3187, October
2001.
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet
Mail", RFC 3191, October 2001.
[RFC3192] Allocchio, C., "Minimal FAX address format in Internet
Mail", RFC 3192, October 2001.
[RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony
Routing over IP (TRIP)", RFC 3219, January 2002.
[T.50] International Telecommunications Union, "International
Reference Alphabet (IRA) (Formerly International Alphabet
No. 5 or IA5) - Information technology - 7-bit coded
character set for information interchange", Recommendation
T.50, 1992.
Author’s Address
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
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; 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 IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made 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 implementers or users of this
specification can be obtained from the IETF 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 that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.