RFC 3966

The tel URI for Telephone Numbers

📅 published December 2004, from ietf

RFC 3966: The tel URI for Telephone Numbers 📞

Okay bestie, let's start with the title block 🎀 This is RFC 3966, called The tel URI for Telephone Numbers, written by H. Schulzrinne at Columbia University. It came out in December 2004, it's on the Standards Track (so it's an actual standard, not a suggestion 💅), and it's published in the Network Working Group series. It obsoletes RFC 2806, meaning it replaces that one ✨

Status of This Memo 📜

Lowkey the most important legal-ish bit: this is an Internet standards track protocol for the Internet community, and the authors are literally asking 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) 📖 And yes, distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2004). 🌈

Abstract 🦋

So this document specifies the URI (Uniform Resource Identifier) scheme "tel", and the whole vibe of "tel" is that it describes resources identified by telephone numbers 📞 It also says, once more for the people in the back, that this document obsoletes RFC 2806 💜

Table of Contents 📚

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

1. Introduction ✨

Okay so this document defines the URI scheme "tel", which describes resources identified by telephone numbers 💖 A telephone number is a string of decimal digits that uniquely indicates the network termination point, and it holds the info needed to route the call to that point. (This definition is derived from [E.164] but encompasses both public and private numbers.)

The termination point of a "tel" URI telephone number is not restricted, and that's giving freedom 🦋 It can live in the public telephone network, a private telephone network, or the Internet. It can be fixed or wireless, and it can address a fixed wired, mobile, or nomadic terminal. The terminal 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 needed to reach a particular number, and it does not imply dialling semantics. It also doesn't point at a specific physical device, only at a telephone number.

As commonly understood, telephone numbers have two related but distinct concepts: a canonical address-of-record and a dial string 🎀 Here's the breakdown:

  • 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. It knows, 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, because 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 it 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.

2. Terminology 🎀

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119, [RFC2119] and indicate requirement levels for compliant implementations 💅

3. URI Syntax ✨

okay so the URI is written in ABNF (augmented Backus-Naur form), the grammar language from RFC 2234 [RFC2234], and it borrows the core definitions from appendix A of RFC 2234 🧚 very organized, very iconic.

The syntax follows RFC 2396 [RFC2396], which tells you exactly which characters can actually show up in the URI 💅 bestie, the big rule is this: if the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. BUT if they show up inside tel URI parameter values, they MUST be percent encoded 🫶

Characters that aren't in the "reserved" or "unsafe" sets (see RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent encoding, so they're basically the same thing written two different ways 🦋

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 🙅‍♀️ and the 'isdn-subaddress' or 'extension' MUST appear first, if present 👑 then the 'context' parameter comes next (if it's there), and then any other parameters go in lexicographical order. the order is strict, no cap.

This is giving comparison-friendly vibes! Putting everything in a fixed order means the "tel" URI can be compared character by character, which is exactly what happens in SIP URIs [RFC3261] 🌈

4. URI Comparisons ✨

okay so two "tel" URIs are equivalent when all of these rules pass 🔍

  • Both must be either a 'local-number' or a 'global-number', i.e., start with a '+'.
  • The 'global-number-digits' and the 'local-number-digits' must be equal, after removing all visual separators.
  • For mandatory additional parameters (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.
  • 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.
  • URI comparisons are case-insensitive.

All parameter names and values SHOULD use lower-case characters 🍓 because tel URIs might get used in places where comparisons are case sensitive, and that's a whole mess.

Section 19.1.4 in the SIP specification [RFC3261] discusses one such case 👀

5. Phone Numbers and Their Context ✨

5.1. Phone Numbers

The 'telephone-subscriber' part of the URI is what tells you the number 📱 the phone number can be written in global (E.164) notation or local notation. All phone numbers MUST use the global form unless they can't be represented that way 🌸 numbers from private numbering plans, emergency numbers ("911", "112"), some directory-assistance numbers (e.g., "411"), and other "service codes" (like N11 numbers in the United States) can't be written in global (E.164) form, so they need to be represented as a local number with a context. Local numbers MUST be tagged with a 'phone-context' (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. no assuming, bestie 🙈

5.1.1. Separators in Phone Numbers

Phone numbers MAY contain visual separators 🦋 visual separators ('visual-separator') just make things easier to read and aren't used for URI comparison or placing a call.

Even though it makes comparisons more complicated, this specification keeps visual separators anyway, to follow the spirit of RFC 2396 [RFC2396]. That RFC points out 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 similar way to this specification 📚

However, even though ITU-T E.123 [E.123] recommends using space characters as visual separators in printed telephone numbers, "tel" URIs MUST NOT use spaces in visual separators, because that would mean excessive escaping 😭

5.1.2. Alphabetic Characters Corresponding to Digits

In some countries, people write phone numbers with letters that match up with certain numbers on the telephone keypad 🎹 the URI format doesn't support this, because the mapping from letters to digits isn't uniform around the world. there are standards [E.161][T1.703] that address this issue though!

5.1.3. Alphabetic, *, and # Characters as Identifiers

As called and calling terminal numbers (TNs) are encoded in BCD in ISUP, six additional values per digit can be encoded, sometimes shown as the hexadecimal characters A through F 🔢 DTMF is similar: it allows for encoding the symbols *, #, and A through D. However, in accordance with E.164, these may not be included in global numbers. Their meaning in local numbers isn't defined here, but they aren't prohibited either 🤷‍♀️

5.1.4. Global Numbers

Globally unique numbers are identified by the leading "+" character 🌍 global numbers MUST be composed with the country (CC) and national (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. Globally unique numbers are unambiguous everywhere in the world, so they SHOULD be used whenever possible ✨

5.1.5. Local Numbers

Local numbers are only unique within a certain geographical area or part of the telephone network, like a private branch exchange (PBX), a state or province, a particular local exchange carrier, or a particular country 🏢 URIs with local phone numbers should only show up in environments where all local entities can successfully set up the call by passing the number to the dialling software. Digits needed for getting an outside line, for example, are not included in local numbers. Local numbers SHOULD NOT be used unless there's no way to represent the number as a global number 🙅‍♀️

Local numbers SHOULD NOT be used for several reasons 💀 local numbers need the originator and recipient to be set up just right so they can insert and recognize the correct context descriptors. There's no algorithm to pick the same descriptor independently, so labelling numbers with their context makes it easier to mess up and have valid identifiers rejected by mistake. The algorithm for choosing descriptors was designed so accidental collisions would be rare, but they can't be ruled out completely 🥲

Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity 🎀 the parameter MUST be chosen to identify the local context in which the number is unambiguously unique. That way, the combination of the descriptor in the 'phone-context' parameter and the local number is globally unique again 👑 the parameter value is defined by the assignee of the local number. It does NOT indicate a prefix that turns the local number into a global (E.164) number. no cap, that's the plot twist.

There are two ways to label the context: with a global number or any number of its leading digits (e.g., "+33"), or with a domain name, e.g., "houston.example.com". The choice between the two is left to the "owner" of the local number, and it depends on whether there's a global number or domain name that is a valid identifier for that particular local number 🌸

The domain name doesn't have to resolve to any actual host, but it MUST be under the administrative control of the entity managing the local phone context 🏠

A global number context is made of the initial digits of a valid global number. All global numbers with these initial digits must be assigned to the same organization, and no such matching number can be used by any other organization 🔒 for example, +49-6151-16 would be a suitable context for the Technical University of Darmstadt, since it uses all numbers starting with those digits 🎓 if no such initial string of digits exists, the organization SHOULD use the lowest number of the global number range assigned to it. (This can happen if two organizations share the same decimal block of numbers. For example, say 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's not required that local numbers within the context actually begin with the chosen set of initial numbers 🧩

A context made of the initial digits of a global number doesn't mean that adding them to the local number will make a valid E.164 number. It might do so by coincidence, but you can't rely on that 🙃 (For example, "911" should be labeled with the context "+1", but "+1-911" is not a valid E.164 number.)

National freephone numbers don't need a context, even though they might not be reachable from outside a particular country code or numbering plan 📞 remember, "tel" URIs are identifiers. It's enough that a global number is unique; it's 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's reasonably descriptive and doesn't need a new IANA-managed assigned number. It's 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 only uses it for identification, the receiver doesn't need to know anything about the context descriptor. It just treats it as one part of a globally unique identifier, with the local number being the other part 🧚 but if a recipient wants to place a call to the local number, it MUST understand the context and be able to place calls within that context 📲 periodt.

5.2. ISDN Subaddresses ✨

okay so a phone number MAY also come with an isdn-subaddress parameter 📞 that tells you the ISDN subaddress 🎀

ISDN subaddresses usually hold International Alphabet 5 (IA5 [T.50]) characters, but honestly they can hold any octet value 🫶

5.3. Phone Extensions 🦋

phone extensions point to stations sitting behind a non-ISDN PBX, and they're basically the same vibe as ISDN subaddresses 💅 they get marked with the extension parameter. Here's the rule: a "tel" URI can have at most one of isdn-subaddress and extension. They can't both show up at the same time, periodt 🙅‍♀️

5.4. Other Parameters 🌸

future protocol extensions to this URI scheme might add other parameters (the parameter in the ABNF) 🧚 these can be either mandatory or optional. Mandatory parameters start with m-. An implementation MAY ignore optional parameters, but it MUST NOT use the URI if it has unknown mandatory parameters 🚫 The m- prefix can't be stuck onto parameters that are already registered (the only exception is making a brand-new, logically distinct parameter 🌈). In this document, phone-context is mandatory, and isub and ext are optional 💜

New mandatory parameters have to be described in a standards-track RFC 📜 but an informational RFC is enough for optional ones 🍓

for example, parameter parameters can carry application-specific extra data about the phone number 🎀 like its intended use or any conversions that were applied to the number ✨

Entities that forward protocol requests with "tel" URIs carrying optional parameters MUST NOT delete or modify any parameters they don't understand 🫶 no snipping out stuff you don't get, bestie 😭

6. Examples 💖

  • tel:+1-201-555-0123: this one points to a phone number in the United States 🇺🇸 The hyphens are there to make the number easier for humans to read. They separate the country, area code and subscriber number 🌸
  • tel:7042;phone-context=example.com: this is a local phone number that's valid within the context "example.com" 🧚
  • tel:863-1234;phone-context=+1-914-555: this is a local phone number that's valid within a particular phone prefix ✨

7. Rationale 🧠

7.1. Why Not Just Put Telephone Numbers in SIP URIs? 🤔

the "tel" URI describes the service of reaching a telephone number, and it doesn't care how you get there 🦋 it could be a SIP-to-PSTN gateway, a direct SIP call via E.164 number ("ENUM") translation [RFC3761], some other signaling protocol like H.323, or a traditional circuit-switched call started on the client side through, say, the Telephony Application Programming Interface (TAPI). So in spirit it's closer to the URN schemes, which also leave resolution to an external mechanism 💅 The same "tel" URI might get translated into any number of other URIs while the call is being set up 🌈

7.2. Why Not Distinguish between Call Types? 🎀

signaling protocols like SIP let you negotiate the call type and its parameters, so a basic indication inside the URI scheme is kinda pointless 🙈 Plus the call type can change a lot, so anything stored in a URI would probably be out of date in no time 💀 If you do want that designation for a device that places calls without a signaling protocol like SIP, mechanisms like the "type" attribute on the HTML A element might fit better 🫶

7.3. Why "tel"? 🌸

"tel" was picked because it's widely recognized that none of the other suggestions seemed appropriate 💜 "Callto" got tossed because URI schemes locate a resource and don't 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 📞

here's an example 👀 in lots of countries the E.164 number +1-212-555-3141 gets dialed as 00-1-212-555-3141, where the leading "00" is the prefix for international calls 🌏 (In general, a "+" in E.164 means an international prefix is required ✨)

8. Usage of Telephone URIs in HTML 💅

links using the "tel" URI SHOULD enclose the telephone number, so users can easily predict what happens when they follow the link 🔗 like this:

Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for
assistance.

instead of this:

Dial <a href="tel:+1-212-555-0101">this number</a> for assistance.

on a public HTML page, the telephone number inside the URI SHOULD always be in the global form, even if the link text uses some local format 🎀 for example:

Telephone (if dialling in the United States):
  <a href="tel:+1-201-555-0111">(201) 555-0111</a>

or even this 🙈

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, like as a Request-URI, alongside "sip" and "sips" URIs 🧚 To keep things short, we'll just imply "sips" URIs whenever we talk about SIP URIs ✨ Both "tel" and SIP URIs can contain telephone numbers, and in SIP URIs they show up as the user part, which is the bit 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 into a SIP URI, with the host part pointing to a gateway 🌸 Usually the outbound proxy does this, since it's the first proxy a call request visits 🚀 A proxy can translate all "tel" URIs to the same SIP host name, or pick a different gateway for different "tel" prefixes based on, for example, info learned from TRIP [RFC3219] 🎀 A proxy server could also hand this translation off to any other proxy server, because proxies are free to apply whatever routing logic they like 💅 For local numbers, the proxy MUST NOT translate "tel" URIs whose contexts it doesn't understand 🚫

as mentioned earlier, all phone numbers MUST use the global form unless they can't be represented that way 🌍 If the local-number format is used, it MUST be qualified by the phone-context parameter 📞 Together, the local number and its phone context make the "tel" URI globally unique 🫶

web pages, vCard business cards, address books and directories can easily hold global "tel" URIs 💖 but people on twelve-button (IP) phones can't dial those numbers directly, and they're usually used to dialling shorter strings, like for PBX extensions or local numbers 📱 These so-called dial strings (section 1) aren't directly represented by "tel" URIs, as noted 🙅‍♀️ The rules that govern translating dial strings into SIP and "tel" URIs (global or local) are called the dial plan 🗺️ Right now, translating dial strings into "tel" URIs has to happen in end systems 🖥️ Future efforts might give us a way 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 configured by hand or, ideally, downloaded as part of a device configuration mechanism ✨ (Right now there's no standardized mechanism for this 😭)

a mobile user can use at least two dial plans: the one for the network they're currently visiting, and the one for their home network 📶 Generally, dialed numbers meant to be global numbers will look the same after translation no matter which dial plan is used, even if the visited network uses '0' to dial an 'outside' number and the home network uses '9' 🌈 as long as the user knows which dial plan is active 🙌 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 it performs 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 doesn't use the same phone context, but it can route to a proxy that handles this phone context 🗺️ This routing can happen through a lookup table, or the domain name of the phone context might be set up to match the SIP domain name of a suitable proxy 🎀 For example, a proxy may always route calls with "tel" URIs like this one:
tel:1234;phone-context=munich.example.com

to the SIP proxy located at munich.example.com. (Proxies that receive a tel URI with a context they don't understand are obligated to return a 404 (Not Found) status response, so that an outbound proxy can decide to try such a heuristic 🧠)

  1. The outbound proxy doesn't recognize the phone context and can't find the right proxy for it 💀 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 all gave extensive comments 👑 thank you all, you're the real MVPs 🌟

11. Security Considerations 🔥

okay this section is SO important, so pay attention bestie 🚨

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 can come with a bunch of risks, like these 👇

  • Calls may incur costs. 💸
  • The URI may be used to place malicious or annoying calls. 😤
  • A call will take the user's phone line off-hook, thus preventing its use. 📞
  • 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 especially important for "tel" URIs embedded in HTML links, because a malicious party may hide the true nature of the URI in the link text 🙈 like this:

<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, kind of like including phone numbers as plain text 📝 However, the tel: scheme identifier may make it easier for an adversary using a search engine to find these numbers 🔍 so yeah, be careful out there 🫶

12. Changes Since RFC 2806 🦋

the specification is syntactically backwards-compatible with the "tel" URI defined in RFC 2806 [RFC2806], but it's been completely rewritten 💖 This document more clearly separates telephone numbers, as identifiers of network termination points, from dial strings, and it takes the latter out of 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

Okay bestie, these are the docs this spec leans on the hardest, so they're basically required reading 📚🫶

  • [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

These ones are the extra reading 🧚 handy for background, but the spec doesn't depend on them the way it does on the normative list.

  • [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 🎀

Meet the author! 💜 Here's how to reach Henning:

   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

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. Big thanks to them for keeping the lights on ✨💖

📦 where this page comes from