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