The tel URI for Telephone Numbers
obsoletes
- rfc-2806 — URLs for Telephone Calls
updated by
- rfc-5341 — The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry
Extracted elements (27)
Call type (voice, fax, data) is not encoded in the tel URI because signaling protocols like SIP already negotiate call type in-band, and any static type designation in a URI would quickly become stale.
Local number contexts use either a domain name or global number prefix so that, in almost all cases, a local administrator can pick a reasonably descriptive identifier without requiring a new IANA-managed assigned number.
Parameters in tel URIs use semicolons as delimiters (matching SIP URI conventions) rather than slashes, because the forward slash in URIs indicates path hierarchy and would conflict with the URI generic syntax defined in RFC 2396.
The tel URI is a transport-independent identifier, not a dial string. It does not describe how to reach a number (via SIP-to-PSTN gateway, ENUM, H.323, or circuit-switched call) because the dialling application must supply context-specific steps like outside-line prefixes and country-code stripping.
Visual separators are retained in tel URIs despite complicating comparisons, following RFC 2396's principle that URIs are easier for people to remember when they consist of meaningful components. However, spaces are prohibited to avoid excessive percent-encoding.
The tel URI can be used as a Request-URI in SIP. SIP proxy servers must translate tel URIs to SIP URIs for routing; for local numbers, a proxy MUST NOT translate tel URIs whose contexts it does not understand, and must return 404 (Not Found) if the context is unrecognized.
The 'tel' URI syntax is backwards-compatible with RFC 2806 but removes dial strings, carrier selection, fax/modem URIs, post-dial strings, and pause characters. The URI syntax now conforms to RFC 2396.
Two tel URIs are equivalent if both are the same type (global or local), their digits are equal after removing visual separators, all mandatory and defined parameters match (case-insensitively), and neither contains a parameter name absent from the other. URI comparisons are case-insensitive, and parameter names/values SHOULD use lower-case.
All phone numbers MUST use the global (E.164) form unless they cannot be represented as such. Numbers from private numbering plans, emergency numbers (e.g., '911', '112'), and certain service codes that cannot be expressed in E.164 form MUST be represented as local numbers with a 'phone-context'.
Each parameter name (pname), the ISDN subaddress, the 'extension', and the 'context' MUST NOT appear more than once in a tel URI. If present, 'isdn-subaddress' or 'extension' MUST appear first, followed by 'context', then other parameters in lexicographical order.
Global numbers MUST be composed with the country code (CC) and national significant number (NSN) as specified in E.123 and E.164. Globally unique numbers are unambiguous worldwide and SHOULD be used.
Implementations MUST NOT assume that telephone numbers have a maximum, minimum, or fixed length, or that they always begin with or contain certain digits.
Local numbers MUST have a 'phone-context' parameter that unambiguously identifies the scope of their validity. The combination of the context descriptor and the local number must be globally unique.
Local numbers SHOULD NOT be used unless there is no way to represent the number as a global number, because they require both originator and recipient to be correctly configured with matching context descriptors, increasing risk of misconfiguration.
Mandatory parameters start with 'm-' and an implementation MUST NOT use the URI if it contains unknown mandatory parameters. Optional parameters MAY be ignored. Entities forwarding protocol requests containing tel URIs MUST NOT delete or modify parameters they do not understand.
New mandatory tel URI parameters must be described in a standards-track RFC; an informational RFC is sufficient for optional parameters.
Reserved characters '+', ';', '=', and '?' used as delimiters in a tel URI MUST NOT be percent-encoded. These characters MUST be percent-encoded if they appear in tel URI parameter values.
Tel URIs MUST NOT use spaces as visual separators, even though ITU-T E.123 recommends spaces in printed telephone numbers, in order to avoid excessive percent-encoding.
The domain name used as a phone-context does not have to resolve to an actual host but MUST be under the administrative control of the entity managing the local phone context.
The 'extension' parameter (';ext=') identifies stations behind a non-ISDN PBX and is functionally equivalent to ISDN subaddresses. At most one of 'isdn-subaddress' and 'extension' may appear in a single tel URI.
The 'isdn-subaddress' parameter (';isub=') carries an ISDN subaddress, typically IA5 characters but may contain any octet value. It cannot appear simultaneously with the 'extension' parameter.
The 'phone-context' parameter labels a local number's scope either via a global number prefix (e.g., '+33') or a domain name (e.g., 'houston.example.com'). A global number context consists of the initial digits of a valid global number assigned exclusively to one organization.
The 'tel' URI scheme identifies resources by telephone number. Its syntax is: telephone-uri = "tel:" telephone-subscriber, where telephone-subscriber is either a global-number (prefixed with '+') or a local-number (requiring a 'phone-context' parameter).
Tel URIs embedded in HTML links are a phishing vector: a malicious party may disguise a premium-rate or harmful number in link text (e.g., displaying 'tel:+1-800-555-0191' while linking to '+1-900-555-0191'). User agents should display the actual URI before placing a call.
Tel URIs may reveal private information, including unlisted phone numbers. The presence of the 'tel:' scheme identifier makes it easier for search engines to discover numbers that would otherwise be harder to find in plain text.
Web clients MUST NOT use the 'tel' URI to place telephone calls without explicit user consent. Automatic calls may incur costs, place malicious calls, take the user's line off-hook, or reveal the user's phone number (possibly unlisted) to a remote party via caller ID.
The full ABNF for the tel URI defines global-number-digits as '+' followed by phonedigits containing at least one DIGIT, local-number-digits allowing HEXDIG plus '*' and '#', and parameters as ';pname[=pvalue]'. Visual separators ('-', '.', '(', ')') are allowed in phone digits but ignored for comparison.