idnits 2.17.1
draft-ietf-iptel-rfc2806bis-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 794.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 778.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 784.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
800), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 35.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== Mismatching filename: the document gives the document name as
'draft-ietf-iptel-tel-rfc2806bis-08', but the file name used is
'draft-ietf-iptel-rfc2806bis-08'
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (May 23, 2004) is 7278 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'I-D.yu-tel-url' is defined on line 712, but no
explicit reference was found in the text
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
-- Obsolete informational reference (is this intentional?): RFC 2368
(Obsoleted by RFC 6068)
-- Obsolete informational reference (is this intentional?): RFC 2396
(Obsoleted by RFC 3986)
-- Obsolete informational reference (is this intentional?): RFC 2806
(Obsoleted by RFC 3966)
-- Obsolete informational reference (is this intentional?): RFC 2916
(Obsoleted by RFC 3761)
-- Obsolete informational reference (is this intentional?): RFC 3187
(Obsoleted by RFC 8254)
Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group H. Schulzrinne
3 Internet-Draft Columbia U.
4 Expires: November 21, 2004 May 23, 2004
6 The tel URI for Telephone Numbers
7 draft-ietf-iptel-tel-rfc2806bis-08
9 Status of this Memo
11 By submitting this Internet-Draft, I certify that any applicable
12 patent or other IPR claims of which I am aware have been disclosed,
13 and any of which I become aware will be disclosed, in accordance with
14 RFC 3668.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that other
18 groups may also distribute working documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on November 21, 2004.
33 Copyright Notice
35 Copyright (C) The Internet Society (2004). All Rights Reserved.
37 Abstract
39 This document specifies the URI (Uniform Resource Identifier) scheme
40 "tel". The ``tel'' URI describes resources identified by telephone
41 numbers.
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
47 3. URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
48 4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
49 5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 7
50 5.1 Phone Numbers . . . . . . . . . . . . . . . . . . . . . . 7
51 5.1.1 Separators in Phone Numbers . . . . . . . . . . . . . 7
52 5.1.2 Alphabetic Characters Corresponding to Digits . . . . 8
53 5.1.3 Alphabetic, * and \\# Characters as Identifiers . . . 8
54 5.1.4 Global Numbers . . . . . . . . . . . . . . . . . . . . 8
55 5.1.5 Local Numbers . . . . . . . . . . . . . . . . . . . . 8
56 5.2 ISDN Subaddresses . . . . . . . . . . . . . . . . . . . . 10
57 5.3 Phone Extensions . . . . . . . . . . . . . . . . . . . . . 10
58 5.4 Other Parameters . . . . . . . . . . . . . . . . . . . . . 10
59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
60 7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
61 7.1 Why Not Just Put Telephone Numbers in SIP URIs? . . . . . 11
62 7.2 Why Not Distinguish Between Call Types? . . . . . . . . . 12
63 7.3 Why tel? . . . . . . . . . . . . . . . . . . . . . . . . . 12
64 7.4 Do Not Confuse Numbers with How They Are Dialed . . . . . 12
65 8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 12
66 9. Use of tel URIs with SIP (Informative) . . . . . . . . . . . . 13
67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
68 11. Security Considerations . . . . . . . . . . . . . . . . . . 14
69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
70 13. Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 15
71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
72 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
73 14.2 Informative References . . . . . . . . . . . . . . . . . . . 16
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
75 Intellectual Property and Copyright Statements . . . . . . . . 18
77 1. Introduction
79 This document defines the URI scheme "tel". The "tel" URI describes
80 resources identified by telephone numbers. A telephone number is a
81 string of decimal digits that uniquely indicates the network
82 termination point. The number contains the information necessary to
83 route the call to this termination point. (This definition is
84 derived from [E.164], but encompasses both public and private
85 numbers.)
87 The "tel" URI telephone number is not restricted in the type of
88 termination point it refers to. The termination point can be in the
89 public telephone network, a private telephone network or the
90 Internet. The termination point can be fixed or wireless and address
91 a fixed wired, mobile or nomadic terminal. The terminal addressed
92 can support any electronic communication service (ECS) including
93 voice, data and fax. The URI can refer to resources identified by a
94 telephone number, including but not limited to originators or targets
95 of a telephone call.
97 The "tel" URI is a globally unique identifier ("name") only; it does
98 not describe the steps necessary to reach a particular number and
99 does not imply dialing semantics. Furthermore, it does not refer to a
100 specific physical device, only to a telephone number.
102 Telephone numbers as commonly understood actually comprise two
103 related, but distinct concepts: as a canonical address-of-record and
104 as a dial string. We define the concepts below:
106 Address-of-record or identifier: The telephone number is understood
107 here as the canonical address-of-record or identifier for a
108 termination point within a specific network. For the public
109 network, these numbers follow the rules in E.164 [E.164], while
110 private numbers follow the rules of the owner of the private
111 numbering plan. Subscribers publish such identifiers as a
112 universal means of being reached, independent of the location of
113 the caller. (Naturally, not all numbers are reachable from
114 everywhere, for a variety of technical and local policy reasons.
115 Also, a single termination point may be reachable from different
116 networks and may have multiple such identifiers.)
117 Dial string: "Dial strings" are the actual numbers, symbols and
118 pauses entered by a user to place a phone call. A dial-string is
119 consumed by one or more network entities, and understood in the
120 context of the configuration of these entities. It is used to
121 generate an address-of-record or identifier in the sense of the
122 previous paragraph so that a call can be routed. Dial-strings may
123 require pre-pended digits to egress the private branch exchange
124 (PBX) the end system is connected to, and they may include
125 post-dial dual-tone multi-frequency (DTMF) signaling that could
126 control an IVR or reach an extension. Dial strings are beyond the
127 scope of this document.
129 Both approaches can be encoded into a URI. For dial strings, this
130 URI is passed to an entity that can reproduce the actions specified
131 in the dial string. For example, in an analog phone system, a dialer
132 translates the dial string into a sequence of actions such as waiting
133 for dial tone, sending DTMF digits, pausing and generating post-dial
134 DTMF digits after the callee picks up. In an integrated services
135 digital network (ISDN) or ISDN user part (ISUP) environment, the
136 signaling elements receiving protocol messages containing the dial
137 string perform the appropriate protocol actions. As noted, this
138 approach is beyond the scope of this specification.
140 The approach described here has the URI specify the telephone number
141 as an identifier, which can be either globally unique or only be
142 valid within a local context. The dialing application is aware of
143 the local context, knowing, for example, whether special digits need
144 to be dialed to seize an outside line, whether network, pulse or tone
145 dialing is needed and what tones indicate call progress. The dialing
146 application then converts the telephone number into a dial sequence
147 and performs the necessary signaling actions. The document below
148 assumes the second model. The dialer does not have to be a user
149 application as found in traditional desktop operating systems, but
150 could well be part of an IP-to-PSTN gateway.
152 To reach a telephone number from a phone on a PBX, for example, the
153 user of that phone has to know how to convert the telephone number
154 identifier into a dial string appropriate for that phone. The
155 telephone number itself does not convey what needs to be done for a
156 particular terminal. Instructions may include dialing "9" before
157 placing a call or prepending a "00" to reach a number in a foreign
158 country. The phone may also need to strip area and country codes.
160 The identifier approach described in this document has the
161 disadvantage that certain services, such as electronic banking or
162 voicemail, cannot be specified in a "tel" URI.
164 The notation for phone numbers in this document is similar to that in
165 RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax
166 differs since this document describes URIs whereas RFC 3191 and RFC
167 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/"
168 to indicate parameters (qualifiers). Since URI use the forward slash
169 to describe path hierarchy, the URI scheme described here uses the
170 semicolon, in keeping with Session Initiation Protocol (SIP) URI
171 conventions [RFC3261].
173 The 'tel' URI can be used as a request URI in SIP [RFC3261] requests.
174 The SIP specification also inherits the 'subscriber' part of the
175 syntax as part of the 'user element' in the SIP URI. Other protocols
176 may use this URI for both query-based and prefix-based applications.
178 The "tel" URI does not specify the call type such as voice, fax, or
179 data call and does not provide the connection parameters for a data
180 call. The type and parameters are assumed to be negotiated either
181 in-band by the telephone device or through a signaling protocol such
182 as SIP.
184 2. Terminology
186 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
187 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
188 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
189 [RFC2119] and indicate requirement levels for compliant
190 implementations.
192 3. URI Syntax
194 The URI is defined using the ABNF (augmented Backus-Naur form)
195 described in RFC 2234 [RFC2234] and uses elements from the core
196 definitions (Appendix A of RFC 2234).
198 The syntax definition follows RFC 2396 [RFC2396], indicating the
199 actual characters contained in the URI. Note that the reserved
200 characters "+", ";", "=", and "?" MUST NOT be escaped as they are
201 delimiters for the "tel" URI scheme. These reserved characters MUST
202 be escaped if they appear in parameter values.
204 Characters other than those in the "reserved" and "unsafe" sets (see
205 RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" encoding.
207 The "tel" URI has the following syntax:
209 telephone-uri = "tel:" telephone-subscriber
210 telephone-subscriber = global-number / local-number
211 global-number = global-number-digits *par
212 local-number = local-number-digits *par context *par
213 par = parameter / extension / isdn-subaddress
214 isdn-subaddress = ";isub=" 1*uric
215 extension = ";ext=" 1*phonedigit
216 context = ";phone-context=" descriptor
217 descriptor = domainname / global-number-digits
218 global-number-digits = "+" 1*phonedigit
219 local-number-digits = 1*phonedigit-hex
220 domainname = *( domainlabel "." ) toplabel [ "." ]
221 domainlabel = alphanum
222 / alphanum *( alphanum / "-" ) alphanum
223 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
224 parameter = ";" pname ["=" pvalue ]
225 pname = 1*( alphanum / "-" )
226 pvalue = 1*paramchar
227 paramchar = param-unreserved / unreserved / escaped
228 unreserved = alphanum / mark
229 mark = "-" / "_" / "." / "!" / "~" / "*" /
230 "'" / "(" / ")"
231 escaped = "%" HEXDIG HEXDIG
232 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
233 phonedigit = DIGIT / [ visual-separator ]
234 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
235 visual-separator = "-" / "." / "(" / ")"
236 alphanum = ALPHA / DIGIT
237 reserved = ";" | "/" | "?" | ":" | "@" | "&" |
238 "=" | "+" | "$" | ","
239 uric = reserved | unreserved | escaped
241 Each parameter name ("pname"), the ISDN subaddress, the 'extension'
242 and the 'context' MUST NOT appear more than once. The
243 'isdn-subaddress' or 'extension' MUST appear first, if present,
244 followed by the 'context' parameter, if present, followed by any
245 other parameters in lexicographical order.
247 This simplifies comparison when the "tel" URI is compared
248 character-by-character, such as in SIP URIs [RFC3261].
250 4. URI Comparisons
252 Two "tel" URIs are equivalent according to the following rules:
254 o Both must be either a 'local-number' or both must be a
255 'global-number', i.e., start with a '+'.
257 o The 'global-number-digits' and the 'local-number-digits' must be
258 equal, after removing all visual separators.
259 o For mandatory additional parameters (Section 5.4) and the
260 'phone-context' and 'extension' parameters defined in this
261 document, The 'phone-context' parameter value is compared as a
262 host name if it is a 'domainname' or digit-by-digit if it is
263 'global-number-digits'. The latter is compared after removing all
264 'visual-separator' characters.
265 o Parameters are compared according to 'pname', regardless of the
266 order they appeared in the URI. If one URI has a parameter name
267 not found in the other, the two URIs are not equal.
268 o URI comparisons are case-insensitive.
270 All parameter names and values SHOULD use lower-case characters since
271 tel URIs may be used within contexts where comparisons are
272 case-sensitive.
274 Section 19.1.4 in the SIP specification [RFC3261] discusses one
275 such case.
277 5. Phone Numbers and Their Context
279 5.1 Phone Numbers
281 The 'telephone-subscriber' part of the URI indicates the number. The
282 phone number can be represented in either global (E.164) or local
283 notation. All phone numbers MUST use the global form unless they
284 cannot be represented as such. Numbers from private numbering plans,
285 emergency ("911", "112") and some directory assistance numbers (e.g.,
286 "411") and other "service codes" (numbers of the form N11 in the
287 United States) cannot be represented in global (E.164) form, and need
288 to be represented as a local number with a context. Local numbers
289 MUST be tagged with a 'phone-context' (Section 5.1.5).
291 Implementations MUST NOT assume that telephone numbers have a
292 maximum, minimum or fixed length, or that they always begin with a
293 certain number.
295 5.1.1 Separators in Phone Numbers
297 Phone numbers MAY contain visual separators. Visual separators
298 ('visual-separator') merely aid readability and are not used for URI
299 comparison or placing a call.
301 Despite complicating comparisons, this specification retains the
302 visual separators to follow the spirit of RFC 2396 [RFC2396],
303 which remarks that "A URI often needs to be remembered by people,
304 and it is easier for people to remember a URI when it consists of
305 meaningful components." Also, ISBN URNs documented in RFC 3187
306 [RFC3187] use visual separators in a manner similar to this
307 specification.
309 Even though ITU-T E.123 [E.123] recommends the use of space
310 characters as visual separators in printed telephone numbers,
311 "tel" URIs cannot use spaces in visual separators to avoid
312 excessive escaping.
314 5.1.2 Alphabetic Characters Corresponding to Digits
316 In some countries, it is popular to write phone numbers using
317 alphabetic characters which correspond to certain numbers on the
318 telephone keypad. The URI format does not support this notation
319 since the mapping from alphabetic characters to digits is not
320 completely uniform internationally, although there are standards
321 [E.161][T1.703] addressing this issue.
323 5.1.3 Alphabetic, * and \\# Characters as Identifiers
325 Since called and calling terminal numbers (TNs) are encoded in BCD in
326 ISUP, six additional values per digit can be encoded, sometimes
327 represented as the hexadecimal characters A through F. Similarly,
328 DTMF allows for the encoding of the symbols *, \# and A through D.
329 However, in accordance with E.164, they may not be included in global
330 numbers. Their meaning in local numbers is not defined here, but they
331 are not prohibited.
333 5.1.4 Global Numbers
335 Globally unique numbers are identified by the leading "+" character.
336 Global numbers MUST be composed with the country (CC) and national
337 (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
338 Globally unique numbers have the property of being unambiguous
339 everywhere in the world and SHOULD be used.
341 5.1.5 Local Numbers
343 Local numbers are unique only within a certain geographical area or a
344 certain part of the telephone network, e.g., a private branch
345 exchange (PBX), a state or province, a particular local exchange
346 carrier or a particular country. URIs with local phone numbers
347 should only appear in environments where all local entities can
348 successfully set up the call by passing the number to the dialing
349 software. Digits needed for accessing an outside line, for example,
350 are not included in local numbers. Local numbers SHOULD NOT be used
351 unless there is no way to represent the number as a global number.
353 Local numbers require that the originator and recipient are
354 configured appropriately, so that they can insert and recognize
355 the correct descriptors. Since there is no algorithm to
356 independently pick the same descriptor, labeling numbers with
357 their context increases the chances of mis-configuration, so that
358 valid identifiers are rejected by mistake. The algorithm to
359 select descriptors was chosen that accidental collisions should be
360 rare, but they cannot be ruled out.
362 Local numbers MUST have a 'phone-context' parameter that identifies
363 the scope of their validity. The parameter MUST be chosen to
364 unambiguously identify the local context within which the number is
365 unique. Thus, the combination of the descriptor in the
366 'phone-context' parameter and local number is again globally unique.
367 The parameter value is defined by the assignee of the local number.
368 It does NOT indicate a prefix that turns the local number into a
369 global (E.164) number.
371 There are two ways to label the context: via a global number or any
372 number of its leading digits (e.g., "+33") and via a domain name,
373 e.g., "houston.example.com". The choice between the two is left to
374 the "owner" of the local number and is governed by whether there is a
375 global number or domain name that is a valid identifier for a
376 particular local number.
378 The domain name does not have to resolve to any actual host, but MUST
379 be under the administrative control of the entity managing the local
380 phone context.
382 A global number context consists of the initial digits of a valid
383 global number. All global numbers matching these initial digits must
384 be assigned to the same organization that is describing the context
385 and no such matching number can be used by any other organization.
386 For example, +49-6151-16 would be a suitable context for the
387 Technical University of Darmstadt, as it uses all numbers starting
388 with those digits. If such an initial string of digits does not
389 exist, the organization SHOULD use the lowest number of the global
390 number range assigned to it. (This can occur if two organizations
391 share the same decimal block of numbers. For example, assume an
392 organization owns the number range +1-212-939-7000 through
393 +1-212-939-7199. +1-212-939-7 would not be a valid global number
394 context, but +1-212-939-7000 would work.) It is not required that
395 local numbers within the context actually begin with the chosen set
396 of initial numbers.
398 A context consisting of the initial digits of a global number does
399 not imply that adding these to the local number will generate a valid
400 E.164 number. It might do so by coincidence, but this cannot be
401 relied upon. (For example, "911" should be labeled with the context
402 "+1", but "+1-911" is not a valid E.164 number.)
404 National freephone numbers do not need a context, even though they
405 are not necessarily reachable from outside a particular country code
406 or numbering plan. Recall that "tel" URIs are identifiers; it is
407 sufficient that a global number is unique, but it is not required
408 that it be reachable from everywhere.
410 Even non-freephone numbers may be out of date or not be reachable
411 from a particular location. For example, premium services such as
412 "900" numbers in the North American numbering plan are often not
413 dialable from outside the particular country code.
415 The two label types were chosen so that, in almost all cases, a
416 local administrator can pick an identifier that is reasonably
417 descriptive and does not require a new IANA-managed assigned
418 number. It is up to the administrator to assign an appropriate
419 identifier and to use it consistently. Often, an organization can
420 choose among several different identifiers.
422 If the recipient of a "tel" URI uses the URI simply for
423 identification, the receiver does not need to know anything about the
424 context descriptor. It simply treats it as one part of a globally
425 unique identifier, with the other being the local number. If a
426 recipient of the URI intends to place a call to the local number, it
427 MUST understand the context and be able to place calls within that
428 context.
430 5.2 ISDN Subaddresses
432 A phone number MAY also contain an 'isdn-subaddress' parameter which
433 indicates an ISDN subaddress.
435 ISDN subaddresses typically contain International Alphabet 5 (IA5
436 [T.50]) characters, but may contain any octet value.
438 5.3 Phone Extensions
440 Phone extensions identify stations behind a non-ISDN PBX and are
441 roughly equivalent in functionality to ISDN subaddresses. They are
442 identified with the 'extension' parameter. At most one of the
443 'isdn-subaddress' and 'extension' parameters can appear in a tel URI,
444 i.e., they cannot appear both at the same time.
446 5.4 Other Parameters
448 Future protocol extensions to this URI scheme may add other
449 parameters ('parameter' in the ABNF). Such parameters can be either
450 mandatory or optional. Mandatory parameters start with "m-". An
451 implementation MAY ignore optional parameters. An implementation
452 MUST NOT use the URI if it contains unknown mandatory parameters.
453 The "m-" prefix cannot be added to parameters that were already
454 registered (except to create a new, logically distinct parameter).
455 The "phone-context" parameter in this document is mandatory, "isub"
456 and "ext" are optional.
458 New mandatory parameters must be described in a standards-track RFC,
459 while an informational RFC is sufficient for optional parameters.
461 For example, 'parameter' parameters can be used to store
462 application-specific additional data about the phone number, its
463 intended use, or any conversions that have been applied to the
464 number.
466 Entities that forward protocol requests containing tel URIs with
467 optional parameters MUST NOT delete or modify parameters they do not
468 understand.
470 6. Examples
472 tel:+1-201-555-0123: This URI points to a phone number in the United
473 States. The hyphens are included to make the number more
474 human-readable; they separate country, area codes and subscriber
475 number.
476 tel:7042;phone-context=cs.columbia.edu: The URI describes a local
477 phone number valid within the context "cs.columbia.edu".
478 tel:863-1234;phone-context=+1-914-555: The URI describes a local
479 phone number that is valid within a particular phone prefix.
481 7. Rationale
483 7.1 Why Not Just Put Telephone Numbers in SIP URIs?
485 The "tel" URI describes a service, reaching a telephone number, that
486 is independent of the means of doing so, be it via a SIP-to-PSTN
487 gateway, a direct SIP call via E.164 number ("ENUM") translation
488 [RFC2916], some other signaling protocols such as H.323 or a
489 traditional circuit-switched call initiated on the client side via,
490 say, the Telephony Application Programming Interface (TAPI). It is
491 thus, in spirit, closer to the URN schemes that also leave the
492 resolution to an external mechanism. The same "tel" URI may get
493 translated to any number of other URIs in the process of setting up
494 the call.
496 7.2 Why Not Distinguish Between Call Types?
498 Signaling protocols such as SIP allow to negotiate the call type and
499 parameters, making the very basic indication within the URI scheme
500 moot. Also, since the call type can change frequently, any such
501 indication in a URI is likely to be out of date. If such designation
502 is desired for a device that directly places calls without a
503 signaling protocol such as SIP, mechanisms such as the "type"
504 attribute for the "A" element in HTML may be more appropriate.
506 7.3 Why tel?
508 "Tel" was chosen since it is widely recognized none of the other
509 suggestions appeared appropriate. "Callto" was discarded since URI
510 schemes locate a resource and do not specify an action to be taken.
511 "Telephone" and "phone" were considered too long and not as
512 internationally recognized.
514 7.4 Do Not Confuse Numbers with How They Are Dialed
516 As an example, the E.164 number "+1-212-555-3141" will be dialed in
517 many countries as 00-1-212-555-3141, where the leading "00" is a
518 prefix for international calls. (In general, a "+" symbol in E.164
519 indicates that an international prefix is required.)
521 8. Usage of Telephone URIs in HTML
523 Links using the "tel" URI SHOULD enclose the telephone number, so
524 that users can easily predict the action taken when following the
525 link.
527 Dial +1-212-555-0101
528 for assistance.
530 instead of
532 Dial this number
533 for assistance.
535 On a public HTML page, the telephone number in the URI SHOULD always
536 be in the global form, even if the text of the link uses some local
537 format.
539 Telephone (if dialing in the United States):
540 (201) 555-0111
542 or even
543 For having RFCs read aloud, call
544 1-555-IETF-RFC.
546 9. Use of tel URIs with SIP (Informative)
548 SIP can use the "tel" URI anywhere a URI is allowed, for example as a
549 Request-URI, along with "sip" and "sips" URIs. For brevity, we will
550 imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP
551 URIs can contain telephone numbers. In SIP URIs, they appear as the
552 user part, i.e., before the @ symbol (Section 19.1.6 in [RFC3261]).
554 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
555 proxy servers has to translate the tel URI to a SIP URI, with the
556 host part of that URI pointing to a gateway. Typically, the outbound
557 proxy server, as the first proxy server visited by a call request,
558 performs this translation. A proxy server can translate all tel URIs
559 to the same SIP host name or select a different gateway for different
560 tel prefixes, based, for example, on information learned from TRIP
561 [RFC3219]. However, a proxy server could also delegate this
562 translation task to any other proxy server since proxy servers are
563 free to apply whatever routing logic they desire. For local numbers,
564 the proxy MUST NOT translate "tel" URIs whose context it does not
565 understand.
567 As noted earlier, all phone numbers MUST use the global form unless
568 they cannot be represented as such. If the local-number format is
569 used, it MUST be qualified by the 'phone-context' parameter.
570 Effectively, the combination of local number and phone context makes
571 the tel URI globally unique.
573 While web pages, vCard business cards, address books and directories
574 can easily contain global tel URIs, users on twelve-button (IP)
575 phones cannot dial such numbers directly and are typically accustomed
576 to dialing shorter strings, e.g., for PBX extensions or local
577 numbers. These so-called dial-strings (Section 1) are not directly
578 represented by tel URIs, as noted. We refer to the rules that govern
579 the translation of dial strings into SIP and tel URIs, global or
580 local, as the dial plan. Currently, translations from dial strings
581 to tel URIs have to take place in end systems. Future efforts may
582 provide means to carry dial strings in a SIP URI, for example, but no
583 such mechanisms exist at the time of writing.
585 A SIP UA can use a dial plan to translate dial strings into SIP or
586 "tel" URIs. The dial plan can be manually configured or, preferably,
587 be downloaded as part of a device configuration mechanism. (At this
588 time, there is no standardized mechanism for this.)
589 A mobile user can use at least two dial plans, namely the dial plan
590 for the network that he is currently visiting and the dial plan for
591 his home network. Generally, dialed numbers that are meant to
592 represent global numbers will look the same after the translation
593 regardless of the dial plan, even if, say, the visited network uses
594 '0' for dialing an 'outside' number and the user's home network uses
595 '9', as long as the user is aware of the current dial plan. However,
596 local extensions that do not have a direct global equivalent may well
597 behave differently. To avoid any ambiguity, the dial plan MUST
598 insert a suitable 'phone-context' string when performing the
599 translation. If the 'phone-context' is a domain name, there are
600 three cases:
601 1. The outbound proxy recognizes the domain name in the tel or SIP
602 URI as its local context and can route the request to a gateway
603 that understands the local number.
604 2. The outbound proxy does not use the same phone context, but can
605 route to a proxy that handles this phone context. This routing
606 can be done via a lookup table or the domain name of the phone
607 context might be set up to reflect the SIP domain name of a
608 suitable proxy. For example, a proxy may always route calls with
609 tel URIs like
611 tel:1234;phone-context=munich.example.com
613 to the SIP proxy located at munich.example.com. (Proxies that
614 receive a tel URI with a context they do not understand are
615 obligated to return a 404 (Not Found) status resonse, so that an
616 outbound proxy may decide to attempt such a heuristic.)
617 3. The outbound proxy does not recognize the phone context and
618 cannot find the appropriate proxy cognizant of that phone
619 context. In that case, the translation fails and the outbound
620 proxy returns a 404 (Not Found) error response.
622 10. Acknowledgments
624 This document is derived from RFC 2806 [RFC2806], written by Antti
625 Vaehae-Sipilae. Flemming Andreasen, Francois Audet, Lawrence Conroy,
626 Cullen Jennings, Michael Hammer, Paul Kyzivat, Andrew Main, Xavier
627 Marjou, Jon Peterson, Mike Pierce, Jonathan Rosenberg and James Yu
628 provided extensive comments.
630 11. Security Considerations
632 The security considerations parallel those for the mailto URL
633 [RFC2368].
635 Web clients and similar tools MUST NOT use the tel URI to place
636 telephone calls without the explicit consent of the user of that
637 client. Placing calls automatically without appropriate user
638 confirmation may incur a number of risks, such as those described
639 below:
640 o Calls may incur costs.
641 o The URI may be used to place malicious or annoying calls.
642 o A call will take the user's phone line off-hook, thus preventing
643 its use.
644 o A call may reveal the user's, possibly unlisted, phone number to
645 the remote host in the caller identification data, and may allow
646 the attacker to correlate the user's phone number with other
647 information such as the e-mail or IP address.
649 This is particularly important for tel URIs embedded in HTML links as
650 a malicious party may hide the true nature of the URI in the link
651 text, as in
653 Find free information here
654 tel:+1-800-555-1234
656 Tel URIs may reveal private information, similar to including phone
657 numbers as text. However, the presence of the tel: schema identifier
658 may make it easier for an adversary using a search engine to discover
659 such numbers.
661 12. IANA Considerations
663 This document requires no IANA actions.
665 13. Changes Since RFC 2806
667 The specification is syntactically backwards-compatible with the
668 "tel" URI defined in RFC 2806 [RFC2806], but has been completely
669 rewritten. This document more clearly distinguishes telephone
670 numbers as identifiers of network termination points from dial
671 strings and removes the latter from the purview of "tel" URIs.
672 Compared to RFC 2806, references to carrier selection, dial context,
673 fax and modem URIs, post-dial strings and pause characters have been
674 removed. The URI syntax now conforms to RFC 2396 [RFC2396].
676 A section on using tel URIs in SIP was added.
678 14. References
680 14.1 Normative References
682 [E.123] International Telecommunications Union, "Notation for
683 national and international telephone numbers, e-mail
684 addresses and web addresses", Recommendation E.123,
685 February 2001.
687 [E.161] International Telecommunications Union, "Arrangement of
688 digits, letters and symbols on telephones and other
689 devices that can be used for gaining access to a telephone
690 network", Recommendation E.161, May 1995.
692 [E.164] International Telecommunications Union, "The international
693 public telecommunication numbering plan", Recommendation
694 E.164, May 1997.
696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
697 Requirement Levels", BCP 14, RFC 2119, March 1997.
699 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
700 Specifications: ABNF", RFC 2234, November 1997.
702 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
703 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
704 "SIP: Session Initiation Protocol", RFC 3261, June 2002.
706 [T1.703] ANSI, "Allocation of Letters to the Keys of Numeric
707 Keypads for Telecommunications", Standard T1.703-1995
708 (R1999), 1999.
710 14.2 Informative References
712 [I-D.yu-tel-url]
713 Yu, J., "New Parameters for the 'tel' URL to Support
714 Number Portability and Freephone Service",
715 draft-yu-tel-url-08 (work in progress), November 2003.
717 [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
718 scheme", RFC 2368, July 1998.
720 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
721 Resource Identifiers (URI): Generic Syntax", RFC 2396,
722 August 1998.
724 [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
725 April 2000.
727 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
728 2000.
730 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard
731 Book Numbers as Uniform Resource Names", RFC 3187, October
732 2001.
734 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet
735 Mail", RFC 3191, October 2001.
737 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet
738 Mail", RFC 3192, October 2001.
740 [RFC3219] Rosenberg, J., Salama, H. and M. Squire, "Telephony
741 Routing over IP (TRIP)", RFC 3219, January 2002.
743 [T.50] International Telecommunications Union, "International
744 Reference Alphabet (IRA) (Formerly International Alphabet
745 No. 5 or IA5) - Information technology - 7-bit coded
746 character set for information interchange", Recommendation
747 T.50, 1992.
749 Author's Address
751 Henning Schulzrinne
752 Columbia University
753 Department of Computer Science
754 450 Computer Science Building
755 New York, NY 10027
756 US
758 Phone: +1 212 939 7042
759 EMail: hgs@cs.columbia.edu
760 URI: http://www.cs.columbia.edu
762 Intellectual Property Statement
764 The IETF takes no position regarding the validity or scope of any
765 Intellectual Property Rights or other rights that might be claimed to
766 pertain to the implementation or use of the technology described in
767 this document or the extent to which any license under such rights
768 might or might not be available; nor does it represent that it has
769 made any independent effort to identify any such rights. Information
770 on the IETF's procedures with respect to rights in IETF Documents can
771 be found in BCP 78 and BCP 79.
773 Copies of IPR disclosures made to the IETF Secretariat and any
774 assurances of licenses to be made available, or the result of an
775 attempt made to obtain a general license or permission for the use of
776 such proprietary rights by implementers or users of this
777 specification can be obtained from the IETF on-line IPR repository at
778 http://www.ietf.org/ipr.
780 The IETF invites any interested party to bring to its attention any
781 copyrights, patents or patent applications, or other proprietary
782 rights that may cover technology that may be required to implement
783 this standard. Please address the information to the IETF at
784 ietf-ipr@ietf.org.
786 Disclaimer of Validity
788 This document and the information contained herein are provided on an
789 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
790 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
791 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
792 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
793 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
796 Copyright Statement
798 Copyright (C) The Internet Society (2004). This document is subject
799 to the rights, licenses and restrictions contained in BCP 78, and
800 except as set forth therein, the authors retain all their rights.
802 Acknowledgment
804 Funding for the RFC Editor function is currently provided by the
805 Internet Society.