URLs for Telephone Calls
obsoleted by
- rfc-3966 — The tel URI for Telephone Numbers
Extracted elements (29)
Call type (voice/fax/data) is encoded in the URL scheme specifier rather than as a parameter because digital networks route different call types differently; specifying a fax call via the scheme ensures correct network routing and equipment selection. Encoding it as a parameter would reduce human readability.
Phone numbers use a flat (non-hierarchical) E.164-style encoding rather than a '/'-delimited path because phone number structure (country code, area code, subscriber) is not universal — some areas lack area codes, some numbers require no prefix, and area codes change. A flat string avoids forcing the URL author to know internal numbering structure.
The scheme name 'tel' was chosen over 'callto' (URLs locate resources, not actions), 'telephone' (too long, less international), and 'phone' (less internationally acceptable). 'tel' is concise and considered more universally understood.
The tel/fax/modem URL schemes deliberately do not use hierarchical URL syntax and have no relative URL forms, because phone numbers do not have a universal hierarchical decomposition. The URLs are always absolute and always case-insensitive (except for future-extension values).
A local entity receiving a telephony URL with a local number MUST verify it knows the context in which the number is to be processed before using it; the local entity MUST NOT assume that a locally-formatted number beginning with '00' is equivalent to the corresponding global number beginning with '+'.
Modem capability compatibility is defined by superset/subset relationships: a local entity with V.22bis MUST NOT connect to a host requiring V.32bis (V.22bis is a subset), but MAY use V.32bis to connect to a host requiring V.32 (V.32bis is a superset of V.32). Compliance to any one listed modem-params alternative is acceptable.
The phone number notation is taken from RFC 2303 and RFC 2304 (PSTN/FAX address formats for Internet mail), but the separator '/' used in hierarchical URLs is replaced by ';' to avoid conflicts with RFC 2396 URL syntax. The scheme has also been synchronized with RFC 2543 (SIP).
A local-phone-number MUST include at least one area-specifier; the local entity MUST NOT attempt to place the call if it cannot originate calls within the specified locale. Multiple area-specifier instances are permitted, meaning the number is valid in all listed areas.
All phone numbers SHOULD always be written in international form (beginning with '+', country code, then national significant number per E.123/E.164) unless there is a specific reason to use local form. International numbers have the property of being unambiguous everywhere when the user-agent is correctly configured.
Any telephone number MUST contain at least one phonedigit or dtmf-digit; subscriber numbers consisting only of pause characters are not valid. Implementations MUST NOT assume a maximum, minimum, or fixed length for telephone numbers.
Implementations MUST be prepared to handle additional and/or unknown parameters gracefully but MUST NOT use a URL that contains unknown parameters, as they may be vital for correct interpretation. Instead, the implementation SHOULD report an error to the user.
Local phone numbers specified via local-phone or fax-local-phone MUST be passed to the dialing entity 'as is', without any conversion, unless the local entity opts to utilize an optional service-provider parameter.
Proprietary modem types MUST be specified using the vendor naming tree 'vnd.x.y', where 'x' is the vendor name (sharing the MIME vendor name space from RFC 2048) and 'y' is the modem type. Submitting new modem types to the ietf-types list for review is strongly recommended.
The local entity MUST call out using hardware compatible with the modem-params capability, or request the network to provide such a service. If recommended-params conflict with modem-params, the local entity MUST ignore recommended-params. New modem capability tokens MUST always be documented in an RFC.
The post-dial sequence MUST be sent using DTMF in-band signalling or pulse dialing after call setup is complete. If the user-agent does not support DTMF or pulse dialing post-connection, the post-dial sequence MUST be ignored and the user SHOULD be notified.
Unless the sender is certain of shared private-network access strings, they MUST NOT use a local dialing-plan number; they SHOULD use a global number or, as a last resort, a private context. If the local entity does not support the indicated private context, the request MUST be rejected.
visual-separator characters ('-', '.', '(', ')') MUST be ignored by the local entity when processing a URL; they exist solely for human readability. Space characters MUST NOT be used in URLs as phone number separators.
Placing a call via a tel/fax/modem URL may reveal the user's phone number (including unlisted numbers) to the remote party through caller-identification data, potentially correlating it with other identifiers such as an email or IP address. The local entity's design MUST account for this risk.
The area-specifier parameter (';phone-context=') qualifies a local phone number with the numbering context in which it is valid. It takes one of three forms: global-network-prefix ('+' followed by E.164 digits), local-network-prefix (a local dial string), or private-prefix (an opaque private context name).
The 'fax' URL scheme extends the tel syntax by adding an optional T.33 subaddress component (';tsub=' followed by phonedigits) to both global and local fax subscriber forms, reflecting the additional subaddressing capability of telefax equipment.
The future-extension mechanism (';token[=value]') allows new parameters to be appended after a semicolon. Extensions used in open environments MUST be documented in an RFC; the nonterminal is compatible with the <other-param> defined in RFC 2543.
The ISDN subaddress component (';isub=' followed by phonedigits) identifies a sub-endpoint under a shared phone number and is sent to the network via call-setup signalling. The T.33 subaddress (';tsub=') serves an analogous role for fax routing per ITU-T T.33.
The 'modem' URL scheme adds ';type=' (modem-params, minimum required capability) and ';rec=' (recommended-params) to the telephone-subscriber syntax. Capability tokens follow ITU-T standard naming (e.g., V32b for V.32bis) or a 'vnd.vendor.type' tree for proprietary modems.
The post-dial sequence (';postd=') encodes DTMF digits, pause ('p'), and wait-for-dial-tone ('w') characters to be sent in-band after call setup, used for voice-mail access codes and service control. It may contain dtmf-digit characters '*', '#', 'A'–'D' in addition to ordinary phonedigits.
The service-provider parameter (';tsp=') carries the fully qualified Internet domain name of the telephony service provider, enabling the user-agent to route the call over a specific carrier, improve billing estimates, or optimize its behavior. It may be ignored by the user-agent.
The 'tel' URL scheme identifies a voice telephone terminal. Its ABNF defines global-phone-number (starting with '+') and local-phone-number, with optional isdn-subaddress (';isub='), post-dial (';postd='), area-specifier, service-provider, and future-extension components.
The local entity SHOULD NOT place a call without the user's knowledge due to risks including unexpected call costs (long-distance, premium-rate, non-terminating post-dial), wrong numbers inserted maliciously in web pages or email, tying up the phone line, opening a back-door data connection, and revealing the user's (possibly unlisted) phone number via caller-ID.
The local entity SHOULD provide a mechanism for the user to filter unwanted numbers, SHOULD NOT perform rapid redialing on busy signals (to avoid network congestion), and SHOULD detect premature call termination and refrain from automatic retry without user instruction.
Non-unreserved characters (per RFC 2396) present in any tel/fax/modem URL MUST be percent-encoded before use. The ABNF specifies raw unescaped octets; implementations must also reverse-escape when parsing. visual-separator characters ('-', '.', '(', ')') are purely cosmetic and MUST be ignored during processing.