RFC 2806
URLs for Telephone Calls
URLs for Telephone Calls 📞
Okay, bestie, this one is RFC 2806, and it's giving phone calls on the internet 📞💖. It was written by A. Vaha-Sipila at Nokia 🎀, it's on the Standards Track 👑, and it's dated April 2000. It came out of the Network Working Group 🌸. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched by this one 🦋.
Status of this Memo 📜
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨. Distribution of this memo is unlimited 🌈.
Copyright Notice 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved. 💅
Abstract ✨
Here's the tea 🫖: this document defines the URL (Uniform Resource Locator) schemes tel, fax and modem. They're for pointing at a terminal on the phone network and saying what kinds of connection can reach it 📱. It covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, for both POTS and digital/mobile subscribers 🧚.
Table of Contents 🗂️
1. Introduction ................................................ 2
1.1 New URL schemes ............................................ 2
1.2 Formal definitions ......................................... 3
1.3 Requirements ............................................... 3
2. URL schemes for telephone calls ............................. 3
2.1 Applicability .............................................. 3
2.2 "tel" URL scheme ........................................... 4
2.3 "fax" URL scheme ........................................... 6
2.4 "modem" URL scheme ......................................... 6
2.5 Parsing telephone, fax and modem URLs ...................... 7
2.5.1 Call type ................................................ 7
2.5.2 Phone numbers and their scope ............................ 7
2.5.3 Separators in phone numbers .............................. 10
2.5.4 Converting the number to the local numbering scheme ...... 10
2.5.5 Sending post-dial sequence after call setup .............. 10
2.5.6 Pauses in dialing and post-dial sequence ................. 11
2.5.7 ISDN subaddresses ........................................ 11
2.5.8 T.33 subaddresses ........................................ 11
2.5.9 Data call parameters ..................................... 12
2.5.10 Telephony service provider identification ............... 13
2.5.11 Additional parameters ................................... 14
2.6 Examples of Use ............................................ 14
2.7 Rationale behind the syntax ................................ 15
2.7.1 Why distinguish between call types? ..................... 15
2.7.2 Why "tel" is "tel"? ..................................... 16
2.7.3 Why to use E.164-style numbering? ........................ 16
2.7.4 Not everyone has the same equipment as you ............... 17
2.7.5 Do not confuse numbers with how they are dialled ......... 17
3. Comments on usage ........................................... 17
4. References .................................................. 18
5. Security Considerations ..................................... 19
6. Acknowledgements ............................................ 20
7. Author's Address ............................................ 20
8. Full Copyright Statement .................................... 211. Introduction ✨
1.1 New URL schemes 📱
This spec defines three new URL schemes: "tel", "fax" and "modem" 🦋. They're meant for describing a terminal you can contact over the telephone network. The description includes the subscriber (telephone) number of the terminal and the parameters you need to connect to it successfully 💅.
The "tel" scheme describes a connection to a terminal that handles normal voice telephone calls, a voice mailbox or another voice messaging system, or a service that can be operated using DTMF tones 🎶.
The "fax" scheme describes a connection to a terminal that can handle telefaxes (facsimiles). The name (scheme specifier) for the URL is "fax", as recommended by [E.123] 📠.
The "modem" scheme describes a connection to a terminal that can handle incoming data calls. "Modem" refers to a device that does digital-to-analog and analog-to-digital conversions. On top of that, a "modem" scheme can describe a fully digital connection 🤖.
The phone number notation is the same one specified in [RFC2303] and [RFC2304]. The syntax is a bit different, though, because this document specifies URLs while [RFC2303] and [RFC2304] specify electronic mail addresses 📧. For example, "/" (used in URLs to separate parts in a hierarchical URL [RFC2396]) has been replaced by ";". This URL scheme has also been synchronized with [RFC2543] ✨.
When these URLs are used, the number of parameters should be kept to the minimum, unless that would make the context of use unclear 🌸. Short URLs are especially important if the URL is going to be shown to the end user, printed, or otherwise distributed so that it's visible 👑.
1.2 Formal definitions 🧠
The ABNF (augmented Backus-Naur form) notation used in formal definitions follows [RFC2234]. This spec uses elements from the 'core' definitions (Appendix A of [RFC2234]). Some elements were defined in previous RFCs. When that's the case, the RFC in question is referenced in comments 💖.
Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this document specifies strings of raw, unescaped characters. If those characters are present in a URL and are not unreserved [RFC2396], they MUST be escaped as explained in [RFC2396] prior to using the URL 🚨. Also, when parsing a URL, remember that some characters may have been escaped 🔍.
Example time 🙈: ABNF notation %x20 means a single octet with a hexadecimal value of "20" (in US-ASCII, a space character). This must be escaped in a URL, and it becomes %20.
Also, the ABNF in this document only uses lower case. URLs are case-insensitive (except for the <future-extension> parameter, whose case-sensitivity is application-specific) 🌈.
1.3 Requirements 🔑
Here's the key word rundown 💅: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] ✨.
Compliant software MUST follow this specification. 💖
2. URL schemes for telephone calls ☎️
2.1 Applicability 📶
In this document, "local entity" means software and hardware that can detect and parse one or more of these URLs, and possibly place a call to a remote entity or otherwise use the contents of the URL 🧚.
These URL schemes are used to direct the local entity to place a call over the telephone network, or as a way to transfer or store a phone number plus other relevant data. The network in question may be a landline or mobile phone network, or a combination of the two 📱. If the phone network differentiates between (for example) voice and data calls, or if the local entity has several different telecommunications equipment at its disposal, it's possible to specify which kind of call (voice/fax/data) is requested 🎯. The URL can also carry information about the capabilities of the remote entity, so the connection can be set up successfully 🫶.
The "tel", "fax" and "modem" URL schemes defined here don't use hierarchical URL syntax, so there are no applicable relative URL forms 🙅. The URLs are always case-insensitive, except for the <future-extension> parameter (see below), whose case-sensitivity is application specific. Characters in the URL MUST be escaped when needed, as explained in [RFC2396] 💀.
2.2 "tel" URL scheme ☎️
The URL syntax is formally described as follows. For the basis of this syntax, see [RFC2303] 🦋.
telephone-url = telephone-scheme ":"
telephone-subscriber
telephone-scheme = "tel"
telephone-subscriber = global-phone-number / local-phone-number
global-phone-number = "+" base-phone-number [isdn-subaddress]
[post-dial] *(area-specifier /
service-provider / future-extension)
base-phone-number = 1*phonedigit
local-phone-number = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[post-dial] area-specifier
*(area-specifier / service-provider /
future-extension)
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit /
dtmf-digit / pause-character)
area-specifier = ";" phone-context-tag "=" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = global-network-prefix / local-network-prefix
global-network-prefix = "+" 1*phonedigitlocal-network-prefix = 1*(phonedigit / dtmf-digit / pause-character)
private-prefix = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A /
%x3C-40 / %x45-4F / %x51-56 / %x58-60 /
%x65-6F / %x71-76 / %x78-7E)
*(%x21-3A / %x3C-7E)
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.2
service-provider = ";" provider-tag "=" provider-hostname
provider-tag = "tsp"
provider-hostname = domain ; <domain> is defined in [RFC1035]
; See section 2.5.10
future-extension = ";" 1*(token-char) ["=" ((1*(token-char)
["?" 1*(token-char)]) / quoted-string )]
; See section 2.5.11 and [RFC2543]
token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E
/ %x80-FF )) %x22
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
phonedigit = DIGIT / visual-separator
visual-separator = "-" / "." / "(" / ")"
pause-character = one-second-pause / wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D"Okay, so the URL kicks off with telephone-scheme 📞, which tells the local entity "hey, what comes next is a URL, parse it the way this document says" 💅. After that, the URL carries the phone number of the remote entity. Phone numbers can also have subaddresses 🦋, which let you reach different remote entities hiding behind the same phone number. If there's a subaddress, it gets tacked onto the phone number after ;isub= ✨. Phone numbers can also have a post-dial sequence 🎀. This is the stuff people use with voice mailboxes and other services where you press buttons on your keypad during the call. The post-dial sequence spells out what the local entity should send to the phone line, and when 🔥.
Phone numbers come in two flavours: "global" and "local" 🌸. Global numbers are unambiguous everywhere, no notes needed 👑. Local numbers only work inside a certain area, which is called "context" (see section 2.5.2) 🧚.
Local numbers always come with an area-specifier 💜, which says what context the number is usable in. The same number can mean different things in different network areas, so this part is kind of a big deal 💀. The context can be indicated with three different prefixes 🌈. A global-network-prefix means the number is valid inside a numbering area whose global numbers start with that prefix 🗺️. A local-network-prefix is similar, but it means the number is valid inside a numbering area whose numbers (or dial strings) start with it 📱. A private-prefix is the name of a context 🔒. The local entity has to already know about that private context to figure out whether it can use the number (see section 2.5.2) 🙈. Extra info about the phone number's usage can be included by adding the name of the telephony services provider in service-provider (see section 2.5.10) 🍓.
The future-extension mechanism lets new parameters get added to this URL scheme later on ✨ (see section 2.5.11).
The private-prefix, token-char and quoted-string nonterminals might look a little intense at first 😭, but they just describe the set of octets that are legal in each one. Some octets have to be escaped, see [RFC2396] 🫶.
2.3 "fax" URL scheme 📠
The URL syntax is formally described as follows (this definition reuses nonterminals from the one above) 💖. For the basis of this syntax, see [RFC2303] and [RFC2304] 🌟.
fax-url = fax-scheme ":" fax-subscriber
fax-scheme = "fax"
fax-subscriber = fax-global-phone / fax-local-phone
fax-global-phone = "+" base-phone-number [isdn-subaddress]
[t33-subaddress] [post-dial]
*(area-specifier / service-provider /
future-extension)
fax-local-phone = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[t33-subaddress] [post-dial]
area-specifier
*(area-specifier / service-provider /
future-extension)
t33-subaddress = ";tsub=" 1*phonedigitThe fax: URL is basically a cousin of the tel: URL 👯♀️. The big difference is that, on top of ISDN subaddresses, telefaxes have another type of subaddress too (see section 2.5.8) 🖨️✨.
2.4 "modem" URL scheme 💻
The URL syntax is formally described as follows (again, this reuses nonterminals from the earlier definitions) 🫧. For the basis of this syntax, see [RFC2303] 💜.
modem-url = modem-scheme ":" remote-host
modem-scheme = "modem"
remote-host = telephone-subscriber *(modem-params
/ recommended-params)
modem-params = ";type=" data-capabilities
recommended-params = ";rec=" data-capabilities
data-capabilities = accepted-modem ["?" data-bits parity
stop-bits]
accepted-modem = "V21" / "V22" / "V22b" /
"V23" / "V26t" / "V32" /
"V32b" / "V34" / "V90" /
"V110" / "V120" / "B103" /
"B212" / "X75" /
"vnd." vendor-name "." modem-type
data-bits = "7" / "8"
parity = "n" / "e" / "o" / "m" / "s"
stop-bits = "1" / "2"
vendor-name = 1*(ALPHA / DIGIT / "-" / "+")
modem-type = 1*(ALPHA / DIGIT / "-" / "+")The modem: URL scheme is also pretty similar to both tel: and fax: 🙌, but it adds a description of what the remote entity can do 🔥. The minimum required compliance is listed in modem-params, and the recommended compliance is listed in recommended-params 📊. For details, see section 2.5.9 🌷.
2.5 Parsing telephone, fax and modem URLs 🧩
2.5.1 Call type ☎️
The type of call is set by the scheme specifier 💅. tel means a voice call is opened 🎙️. fax means the call should be a facsimile (telefax) call 📠. modem means it should be a data call 🖥️. Not every network tells call types apart 😤. When that happens, the scheme specifier tells you which telecommunications equipment type to use 🦋.
2.5.2 Phone numbers and their scope 📞✨
okay so <telephone-subscriber> and <fax-subscriber> are basically how you tell the device which phone number to dial 💅. The number can be written in international or local notation. Both are valid, but international is the main character 👑. All phone numbers SHOULD always be written in the international form if there is no good reason to use the local form.
Not every number works in every numbering area 🙃. That's where the <area-specifier> parameter comes in. It's mandatory for local numbers, and it tells you which locale the number is valid in, or qualifies the number so it can be used unambiguously. An <area-specifier> can take three forms: <global-network-prefix>, <local-network-prefix> or <private-prefix>. They describe the validity area of the number in the global numbering plan, the local numbering plan, or a private numbering plan, respectively.
If an <area-specifier> is present, the local entity MUST NOT attempt to call out using the phone number if it cannot originate the call within the specified locale. If a <local-phone-number> is used, an <area-specifier> MUST be included as well. bestie, don't skip the area specifier 🙅♀️
You can have multiple <area-specifier> instances. When you do, the number is valid in all of the given numbering areas. Stacking them = more places it works ✨
The global prefix form is the outermost context for a phone number. It starts with a "+", followed by some part of an E.164 number, and it also says which region the number is valid in. For example, if <global-network-prefix> is +358, the number is only valid within Finland (country code 358), even if it's a <global-phone-number> 🇫🇮
The local prefix form is an intermediate context for when the outermost context is given some other way. One example is when the local entity is known to only originate calls within the North American Number Plan Area, so an "outermost" phone context can be assumed. The local context could, for example, indicate the area code the phone number is in. So tel:456-7890;phone-context=213 would suffice to deliver a call to +1-213-456-7890. Just note that the version including the <phone-context> also implies the call can only be originated within the "area code 213" region 🌸
The private prefix form is for when the context can't be expressed with the start of a global phone number or a dialing string. The <private-prefix> is actually the name of a private context. The creator of the URL and the local entity have been configured to recognize this name, so they can interpret the number and know how to use it. For example, a private network numbering plan might be called X-COMPANY-NET, but the private dialling plans of the sender's locale and the local entity's locale can be different. The syntax of these tokens will be left for future specification. The ABNF above specifies the accepted characters that can be part of <private-prefix> 🔐
Unless the sender is absolutely sure they share the same private network access digit string with the local entity, they MUST NOT use a dialling plan number (a local phone number, or one qualified by a local context), because the result may be incorrect. Instead, they SHOULD use a global number, or if that isn't possible, a private context as the last resort. If the local entity doesn't support dialling into the private network indicated by that context, the request MUST be rejected. If it does, it will use the access digit string appropriate for its locale.
Note that using <area-specifier> is orthogonal to using the telephony service provider parameter (see 2.5.10). It qualifies the phone number, whilst the <service-provider> parameter indicates the carrier to be used for the call attempt. These are two different jobs, so don't mix them up 🧠
For example, a large company may have private network interconnections between its sites, as well as connections to the Global Switched Telephone Network. A phone number may be given in "public network" form, but with a <service-provider> indicating that the call should be carried over the corporate network 🏢
Conversely, it's possible to represent a phone number in private network form, with a private context to indicate this, but indicate a public telephony service provider. This would request that the user agent convert the private network number plan address into a form that can be carried using the selected service provider 🔄
Any telephone number MUST contain at least one <phonedigit> or <dtmf-digit>. In other words, subscriber numbers made up only of pause characters are not allowed 🚫
International numbers MUST begin with the "+" character. Local numbers MUST NOT contain that character. International numbers MUST be written with the country (CC) and national (NSN) numbers as specified in [E.123] and [E.164]. They have the property of being totally unambiguous everywhere in the world, as long as the local entity is properly configured 🌍
Local numbers MAY be used if the number only works from inside a certain geographical area or network. Some numbers may work from several networks but not from the whole world. These SHOULD be written in international form, with a set of <area-specifier> tags and optional <service-provider> parameters. URLs containing local phone numbers should only appear in an environment where all local entities can get the call successfully set up by passing the number to the dialing entity "as is". An example could be a company intranet, where all local entities are located under the same private telephone exchange. If local phone numbers are used, the document they appear in SHOULD contain an indication of the context they're intended for, and an appropriate <area-specifier> SHOULD be present in the URL 📝
In some regions, people write phone numbers using letters that match certain numbers on the telephone keypad. Letters in <dtmf-digit> characters have nothing to do with this, and this method isn't supported by these URL schemes. Not a vibe 🙅♀️
It should also be noted that implementations MUST NOT assume that telephone numbers have a maximum, minimum or fixed length, or that they will always begin with a certain number. Implementors are encouraged to familiarize themselves with the international standards 📚
2.5.3 Separators in phone numbers 🫧
All <visual-separator> characters MUST be ignored by the local entity when using the URL. They're only there to help readability, so they MUST NOT have any other meaning. Note that although [E.123] recommends using space (SP) characters as separators in printed telephone numbers, spaces MUST NOT be used in phone numbers in URLs, because the space character can't be used in a URL without escaping it 🚫🫧
2.5.4 Converting the number to the local numbering scheme 🔁
After the telephone number has been extracted, it can be converted to the local dialing convention. For example, the "+" might be swapped for the international call prefix, or the international and trunk prefixes might be dropped to place a local call. Numbers specified using <local-phone> or <fax-local-phone> MUST be used by the local entity "as is", without any conversions, unless the local entity decides to make use of the information in an optional <service-provider> parameter 🙌
2.5.5 Sending post-dial sequence after call setup 📲
The number may contain a <post-dial> sequence, which MUST be dialled using Dual Tone Multifrequency (DTMF) in-band signalling or pulse dialing after the call setup is complete. If the user agent doesn't support DTMF or pulse dialing after the call has been set up, <post-dial> MUST be ignored. In that case, the user SHOULD be notified 🔔
2.5.6 Pauses in dialing and post-dial sequence ⏸️
A local phone number or a post-dial sequence may contain <pause-character> characters, which indicate a pause while dialing ("p"), or a wait for dial tone ("w").
Local entities MAY support this method of dialing, and the final interpretation of these characters is left to the local entity. It is RECOMMENDED that the length of each pause is about one second ⏱️
If it isn't supported, local entities MUST ignore everything in the dial string after the first <pause-character>, and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature isn't supported and these characters are present in the URL 🙅♀️
Any <dtmf-digit> characters, and all dial string characters after the first <pause-character> or <dtmf-digit>, SHOULD be sent to the line using DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is done using direct network signaling (a digital subscriber loop or a mobile phone). If the local infrastructure doesn't support DTMF codes, the local entity MAY opt to use pulse dialing. However, it should be noted that certain services controlled using DTMF tones cannot be controlled with pulse dialing. If pulse dialing is used, the user SHOULD be notified 🎶
2.5.7 ISDN subaddresses 🧩
A phone number MAY also contain an <isdn-subaddress>, which indicates an ISDN subaddress. The local entity SHOULD support ISDN subaddresses. These addresses are sent to the network using a method available to the local entity. Typically, ISDN subscribers send the address with the call setup signalling. If ISDN subaddressing isn't supported by the caller, <isdn-subaddress> MUST be ignored and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature isn't supported 🧩✨
2.5.8 T.33 subaddresses 📠
A fax number MAY also contain a <t33-subaddress>, which indicates the start of a T.33 subaddress [T.33]. Local entities SHOULD support this. Otherwise, <t33-subaddress> MUST be ignored and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature isn't supported 💖
2.5.9 Data call parameters 🎀
Okay so <modem-params> is the minimum the local entity needs to connect to the remote one 💖 Its setup has to be equal to or a superset of what the listed modem type can do. You can list several <modem-param> values, and if the local entity matches any one of them, that's a yes ✨
<recommended-params> is the compliance the remote side would love you to have 😭 It's usually the fastest and/or most reliable modem type the modem pool supports, and the local entity can use it to pick the best number out of a group of modem URLs 👑 You can have several recommended modem types too, and they're all equally desirable from the pool's point of view.
Here's the tea: <recommended-params> MAY NOT conflict with <modem-params>. If they do, the local entity MUST ignore the <recommended-params> 🙈
The local entity MUST call out using compatible hardware, or ask the network to provide that service for it 📞
Let's do an example 💅 Say the local entity only has a V.22bis modem, but the URL says the minimum acceptable connection is V.32bis. The local entity MUST NOT try to connect to that host, because V.22bis is a subset of V.32bis, so it's not enough. But if the URL says the minimum is V.32, the local entity can use V.32bis, since V.32bis is a superset of V.32. Iconic behaviour 🦋
Why does this feature even exist? Modem pools often have separate numbers for slow modems and fast ones, or different numbers for analog and ISDN, or they use proprietary modems that aren't standards-compatible 🌈 It's kind of like the connection type specifier (typecode) in FTP URLs [RFC1738]. It gives the local entity info that can't be worked out from the scheme name but still helps things go smoothly 🫶
Also, the number of data bits, stop bits and parity MUST be set according to what the URL says, or to the default values given in this document if the URL doesn't say 🍓
The capability tokens are listed below. If the capabilities suggest it's impossible to make a connection, the connection MUST NOT be created 💀
If ITU-T standardizes new modem types, this list can be extended with their capability tokens. Tokens are formed by taking the number of the standard and joining together the first letter (for example, "V"), the number (for example, 22), and the first letter of the postfix (for example, "bis" becomes "b") ✨
Capability Explanation
V21 ITU-T V.21
V22 ITU-T V.22
V22b ITU-T V.22bis
V23 ITU-T V.23
V26t ITU-T V.26ter
V32 ITU-T V.32
V32b ITU-T V.32bis
V34 ITU-T V.34
V90 ITU-T V.90
V110 ITU-T V.110
V120 ITU-T V.120
X75 ITU-T X.75
B103 Bell 103
B212 Bell 212
Data bits: "8" or "7" The number of data bits. If not
specified, defaults to "8".
Parity: "n", "e", "o", Parity. None, even, odd, mark or
"m", "s" space parity, respectively. If
not specified, defaults to "n".
Stop bits: "1" or "2" The number of stop bits. If not
specified, defaults to "1".Proprietary modem types MUST be specified using the 'vendor naming tree', which looks like vnd.x.y. Here x is the name of the entity where you can get the specs for that modem type, and y is the type or model 🧚 Vendor names MUST share the same name space as the vendor names used in MIME types [RFC2048]. Submitting modem types to the ietf-types list for review is strongly recommended 💜
New capabilities MUST always be documented in an RFC, and they MUST refer to this document or a newer version of it. The documentation SHOULD also list the existing modem types that the newly defined modem type is compatible with 🌸
2.5.10 Telephony service provider identification 🌷
You can also say who the telephony service provider is for a given phone number 📱 A <service-provider> MAY be used by the user-agent to place the call over that network, to level up the user interface, for billing estimates, or to otherwise optimize things 🔥 It MAY also be ignored by the user-agent, no drama 🙃
A <service-provider> is a fully qualified Internet domain name of the telephony service provider, like ;tsp=terrifictelecom.com. The domain name syntax follows the usual Internet domain name rules and is defined in [RFC1035] 🌐
2.5.11 Additional parameters ✨
Besides T.33 and ISDN subaddresses and modem types and area specifiers, future versions of this URL scheme might add other parameters (<future-extension> in the BNF) 🔮 These get tacked onto the URL after a semicolon (";"). Implementations MUST be prepared to handle additional and/or unknown parameters gracefully 🫶 But implementations MUST NOT use the URL if it has unknown parameters, because those might be vital for reading the URL correctly. Instead, the implementation SHOULD report an error ⚠️
For example, <future-extension> could store app-specific extra data about the phone number, what it's for, or any conversions that were applied to it 🍓 Whenever a <future-extension> gets used in an open environment, its syntax and usage MUST be properly documented in an RFC 📜
The <future-extension> nonterminal is a rephrased version of, and compatible with, the <other-param> defined in [RFC2543] (which actually borrows its BNF from an earlier version of this specification) 🦋
2.6 Examples of Use 💅
Let's look at some examples, bestie 👀
tel:+358-555-1234567This URL points to a phone number in Finland that can receive voice calls. The hyphens are there to make the number easier for humans to read, since the country and area codes are separated from the subscriber number ✨
fax:+358.555.1234567This one describes a phone number that can receive fax calls 📠 It uses dots as separators instead of hyphens, but that doesn't change how it works 🌈
modem:+3585551234567;type=v32b?7e1;type=v110This phone number belongs to an entity that can receive data calls 💻 The local entity can choose to use an ITU-T V.32bis modem (or a faster one that's compatible with V.32bis), with 7 data bits, even parity and one stop bit. Or it can make an ISDN connection using the ITU-T V.110 protocol. Options, options, options 🫶
tel:+358-555-1234567;postd=pp22This URL tells the local entity to place a voice call to +358-555-1234567, then wait for an implementation-dependent amount of time (for example, two seconds) and play two DTMF "2" dialing tones down the line 🎶 That's useful for picking a particular extension or invoking a particular service 💖
tel:0w003585551234567;phone-context=+3585551234This URL places a voice call to the given number. This number format is meant for local use: the first zero opens an outside line, the "w" waits for a second dial tone, and the number already has the international access code ("00") attached 🧚 A number like this MUST NOT be used in an environment where all the users of this URL might not be able to dial out with it directly. That said, it might be a good fit for pages on a company intranet 🏢 The <area-specifier> that's present hints that the number only works where the local entity's phone number starts with the given string. That's probably a company-wide block of phone numbers 🌸
tel:+1234567890;phone-context=+1234;vnd.company.option=fooThis URL describes a phone number that, even though it's written in international form, only works inside the numbering area where phone numbers start with +1234 🌍 It also has a proprietary extension, "vnd.company.option", with the value "foo". What that extension means is up to the application. Also, the order of the parameters (phone-context and vnd.company.option) doesn't matter 💜
2.7 Rationale behind the syntax 🧠
2.7.1 Why distinguish between call types? 📞
URLs locate resources, and here the resource is some telecom equipment at a given phone number. But knowing the subscriber number isn't always enough to actually talk to that equipment 😤 Digital phone networks tell voice, fax and data calls apart (and there might be other call types that this spec doesn't cover). So to reach, say, a fax machine, the caller may have to say that a fax call is being made. Otherwise the call might get routed to the subscriber's voice line instead 🙈 In that sense, the call type is a real part of where the target resource is located.
Why put the call type in the scheme name? To make the URL simple to remember and use 🍓 If it were a parameter, like modem parameters are now, the URL would be a lot harder for humans to read.
2.7.2 Why "tel" is "tel"? 🤔
People argued about whether "tel" was the right scheme name, so here's the summary of what was said against the other proposals 💅
callto URL schemes locate a resource and do not specify
an action to be taken.
telephone Too long. Also, "tel" considered to be a more
international form.
phone Was countered on the basis that "tel" is more
internationally acceptable.2.7.3 Why to use E.164-style numbering? 🌍
E.164 is the standard for international phone numbers, and the string of digits after the country code is usually a national matter 🌎 Phone numbers are almost always written as a simple string of digits anyway, so the syntax here feels intuitive to most people. It's the usual way to write numbers on business cards, ads, phone books and so on 📇
Phone numbers can have 'hierarchical' qualities, so you could build a 'forest' of them with country codes as roots, area codes as branches and subscriber numbers as leaves 🌳 But that isn't always the case. Not every area has area codes. Some areas have different area codes depending on how you want to route the call. Some numbers have to be dialled "as is", without any area or country code added (emergency numbers are the big example). And area codes can and do change 🚨
Usually, if something has a hierarchical structure, the URL syntax should reflect that. These URLs are the exception 🙃
Also, when you write a phone number in the form this spec describes, you don't need to know which part is the country code and which part is the area code. If a hierarchical URL used a "/" character to separate the parts of the number, the person writing the URL would have to know which part is which 😩
Finally, when phone numbers are written in the international form specified here, they're unambiguous and can always be converted to the local dialing convention, as long as the user agent knows the local country and area codes 🫶✨
2.7.4 Not everyone has the same equipment as you 📞
Okay so, there are a few different ways a subscriber can dial a phone number, and not everyone's setup is the same bestie 💅
- Pulse dialing 🕰️ is typically what old telephone exchanges use. Usually this dialing method only has to be used to set up the call. After connecting to the remote entity,
<post-dial>can be sent to the line using DTMF, because it'll typically be processed by the remote entity, not the telephone network. Iconic glow-up 🦋 - DTMF 🎶 is the 'beeps' you hear when you dial on most phones. Literal main character sound 💖
- Direct network signalling 🛰️ is what ISDN subscribers and mobile phone users usually have. There's no dial tone (or if there is one, the equipment generates it locally), and the number of the called party gets communicated to the telephone network using some network signalling method. After setting up the call,
<post-dial>sequences are usually sent using DTMF codes. It's giving efficiency ✨
2.7.5 Do not confuse numbers with how they are dialled 🙅♀️
Okay this one is so important, no cap 🫶 As an example, +123456789 gets dialled in lots of countries as 00123456789, where the leading "00" is a prefix for international calls. BUT if a URL contains a local phone number 00123456789, the user-agent MUST NOT assume that this number is equal to the global phone number +123456789. 😭 If a user-agent receives a telephony URL 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, anyone sending a telephony URL MUST take into consideration that the recipient may have insufficient information about the phone number's context. Context is literally everything, periodt 💀
3. Comments on usage 🎀
These are examples of the recommended usage of this URL in HTML documents. Let's get into it 💜
First of all, the number SHOULD be visible to the end user, if it's conceivable that the user might not have a local entity which is able to use these URLs. Like, show the digits so nobody gets lost 🙈
Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>Second, on a public HTML page, the telephone number in the URL SHOULD always be in the international form, even if the text of the link uses some local format. Global girlies only 🌍
Telephone: <a href="tel:+3585551234567">(0555) 1234567</a>or even
For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-
OK</a>.Moreover, if the number is a <local-phone-number>, and the scope of the number isn't clear from the context in which the URL is displayed, a human-readable explanation SHOULD be included. Don't leave people guessing, bestie 🧚
For customer service, dial <a href="tel:1234;phone-
context=+358555">1234</a> (only from Terrific Telecom mobile
phones).4. References 📚
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)",
RFC 1738, December 1994.
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language
- 2.0", RFC 1866, November 1995.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet
Mail", RFC 2303, March 1998.
[RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet
Mail", RFC 2304, March 1998.
[RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[E.123] ITU-T Recommendation E.123: Telephone Network and ISDN
Operation, Numbering, Routing and Mobile Service: Notation
for National and International Telephone Numbers. 1993.
[E.164] ITU-T Recommendation E.164/I.331 (05/97): The International
Public Telecommunication Numbering Plan. 1997.
[T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing the
Subaddress. 1996.5. Security Considerations 🚨
Okay, this section is SERIOUS, so read it carefully bestie 😤 It should be noted that the local entity SHOULD NOT call out without the knowledge of the user, because of the associated risks, which include:
- call costs (including long calls, long distance calls, international calls and premium rate calls, or calls which do not terminate due to
<post-dial>sequences that have been left out by the local entity) 💸 - wrong numbers inserted on web pages by malicious users, or sent via e-mail, perhaps in direct advertising 📧
- making the user's phone line unavailable (off-hook) for a malicious purpose ☎️
- opening a data call to a remote host, thus possibly opening a back door to the user's computer 🚪
- revealing the user's (possibly unlisted) phone number to the remote host in the caller identification data, and correlating the local entity's phone number with other information such as the e-mail or IP address 🕵️
- using the same local number in different contexts, in which the number may have a different meaning 🌀
All of these risks MUST be taken into consideration when designing the local entity. Non-negotiable, no debate 🔒
The local entity SHOULD have some mechanism that the user can use to filter out unwanted numbers. Gatekeeping is self-care 🛡️ The local entity SHOULD NOT use rapid redialing of the number if it is busy, to avoid congesting the (signaling) network. Nobody wants that chaos 🙅♀️ Also, the local entity 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. Hands off the redial unless the user says so 💅
6. Acknowledgements 🫶
Writing this specification would not have been possible without extensive support from many people. So many legends helped out 🌟
Contributors include numerous people from IETF FAX, PINT, URI and URLREG mailing lists, as well as from World Wide Web Consortium and several companies, plus several individuals. Thanks to all people who offered criticism, corrections and feedback. Thank you all, you're the real MVPs 👑
All phone numbers and company names used in the examples of this specification are fictional. Any similarities to real entities are coincidental. Phew, no real numbers were harmed 📱
7. Author's Address 🖋️
Antti Vaha-Sipila
(quoted-printable: Antti V=E4h=E4-Sipil=E4)
Nokia Mobile Phones
P. O. Box 68
FIN-33721 Tampere
Finland
EMail: avs@iki.fi
antti.vaha-sipila@nokia.com8. Full Copyright Statement ⚖️
Here's the legal stuff, and it's kept exactly as written because it needs to be 🤍
Copyright (C) The Internet Society (2000). 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 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.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you for reading the whole thing with me, bestie 🦋💖
📦 where this page comes from
- ietf: rfc2806 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms