Network Working Group H. Schulzrinne Request for Comments: 3966 Columbia University Obsoletes: 2806 December 2004 Category: Standards Track The tel URI for Telephone Numbers Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6 5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 6 5.1. Phone Numbers. . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Separators in Phone Numbers . . . . . . . . . . 7 5.1.2. Alphabetic Characters Corresponding to Digits . 7 5.1.3. Alphabetic, *, and # Characters as Identifiers. 7 5.1.4. Global Numbers. . . . . . . . . . . . . . . . . 7 5.1.5. Local Numbers . . . . . . . . . . . . . . . . . 8 5.2. ISDN Subaddresses. . . . . . . . . . . . . . . . . . . 9 5.3. Phone 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 . . . . . . . . . . . . . . . 11 9. Use of "tel" URIs with SIP (Informative). . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 14 13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17 E.164] but encompasses both public and private numbers.) The termination point of the "tel" URI telephone number is not restricted. It can be in the public telephone network, a private telephone network, or the Internet. It can be fixed or wireless and address a fixed wired, mobile, or nomadic terminal. The terminal addressed can support any electronic communication service (ECS), including voice, data, 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 dialling semantics. Furthermore, it does not refer to a specific physical device, only to a telephone number. As commonly understood, telephone numbers comprise two related but distinct concepts: a canonical address-of-record and 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 [E.164], while private numbers follow the rules of the owner of the private numbering plan. Subscribers publish these identifiers so that they can be reached, regardless 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 identifiers.) 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 an address-of-record or identifier (in the sense described above) so that a call can be routed. Dial strings may require prepended digits to exit the private branch exchange (PBX) the end system is connected to, and they may include post-dial dual-tone multi-frequency (DTMF) signaling that could control an interactive voice response (IVR) system or reach an extension. Dial strings are beyond the scope of this document. Both approaches can be expressed as a URI. For dial strings, this URI is 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 integrated services digital network (ISDN) or ISDN user part (ISUP) environment, the signaling elements that receive protocol messages containing the dial string perform the appropriate protocol actions. As noted, this approach is beyond the scope of this specification. The approach described here has the URI specify the telephone number as an identifier, which can be either globally unique or only valid within a local context. The dialling 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 dialling is needed; and what tones indicate call progress. The dialling application then converts the telephone number into a dial sequence and performs the necessary signaling actions. 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. 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 dialling "9" before placing a call or prepending "00" to reach a number in a foreign country. The phone may also need to strip area and country codes.
The identifier approach described in this document has the disadvantage that certain services, such as electronic banking or voicemail, cannot be specified in a "tel" URI. The notation for phone numbers in this document is similar to that in RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax differs as 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 URIs 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 [RFC3261]. The "tel" URI can be used as a request URI in SIP [RFC3261] 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 also use this URI scheme. 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. This document obsoletes RFC 2806. BCP 14, RFC 2119, [RFC2119] and indicate requirement levels for compliant implementations. RFC2234] and uses elements from the core definitions (appendix A of RFC 2234). The syntax definition follows RFC 2396 [RFC2396], indicating the actual characters contained in the URI. If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. These characters MUST be percent encoded if they appear in tel URI parameter values.
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent encoding. The "tel" URI has the following syntax: telephone-uri = "tel:" telephone-subscriber telephone-subscriber = global-number / local-number global-number = global-number-digits *par local-number = local-number-digits *par context *par par = parameter / extension / isdn-subaddress isdn-subaddress = ";isub=" 1*uric extension = ";ext=" 1*phonedigit context = ";phone-context=" descriptor descriptor = domainname / global-number-digits global-number-digits = "+" *phonedigit DIGIT *phonedigit local-number-digits = *phonedigit-hex (HEXDIG / "*" / "#")*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 / pct-encoded unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" pct-encoded = "%" HEXDIG HEXDIG param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" phonedigit = DIGIT / [ visual-separator ] phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] visual-separator = "-" / "." / "(" / ")" alphanum = ALPHA / DIGIT reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," uric = reserved / unreserved / pct-encoded Each parameter name ("pname"), the ISDN subaddress, the 'extension', and the 'context' MUST NOT appear more than once. The 'isdn- subaddress' or 'extension' MUST 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 [RFC3261].
section 5.4) and the 'phone- context' and 'extension' parameters defined in this document, the 'phone-context' parameter value is compared as a host name if it is a 'domainname' or digit by digit if it is 'global-number- digits'. The latter is compared after removing all 'visual- separator' characters. o Parameters are compared according to '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. o URI comparisons are case-insensitive. All parameter names and values SHOULD use lower-case characters, as tel URIs may be used within contexts where comparisons are case sensitive. Section 19.1.4 in the SIP specification [RFC3261] discusses one such case. section 5.1.5). Implementations MUST NOT assume that telephone numbers have a maximum, minimum, or fixed length, or that they always begin with or contain certain digits.
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 [RFC3187] use visual separators in a manner similar to this specification. However, even though ITU-T E.123 [E.123] recommends the use of space characters as visual separators in printed telephone numbers, "tel" URIs MUST NOT use spaces in visual separators to avoid excessive escaping. E.161][T1.703] addressing this issue. E.123] and E.164 [E.164]. Globally unique numbers are unambiguous everywhere in the world and SHOULD be used.
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- 555-0100 through +1-212-555-0149. +1-212-555-1 would not be a valid global number context, but +1-212-555-0100 would work.) It is not required that local numbers within the context actually begin with the chosen set of initial numbers. 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 may 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 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 it 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 understand the context and be able to place calls within that context.
ISDN subaddresses typically contain International Alphabet 5 (IA5 [T.50]) characters but may contain any octet value.
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.
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>. 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.
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. 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. 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. [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.
[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. 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.