idnits 2.17.1
draft-ietf-iptel-rfc2806bis-04.txt:
-(693): 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 3978, Section 5.5 on line 830.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 814.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 820.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
836), 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?
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 :
----------------------------------------------------------------------------
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).
-- 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 (February 15, 2004) is 7369 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 766, 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 3187
(Obsoleted by RFC 8254)
Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: August 15, 2004 February 15, 2004
6 The tel URI for Telephone Numbers
7 draft-ietf-iptel-rfc2806bis-04
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 3667.
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 August 15, 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 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 11
58 5.4 Other Parameters . . . . . . . . . . . . . . . . . . . . . . 11
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 9.1 Local Translation . . . . . . . . . . . . . . . . . . . . . 14
68 9.2 Proxy Translation . . . . . . . . . . . . . . . . . . . . . 15
69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
71 12. Security Considerations . . . . . . . . . . . . . . . . . . 16
72 13. Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 16
73 Normative References . . . . . . . . . . . . . . . . . . . . 16
74 Informative References . . . . . . . . . . . . . . . . . . . 17
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
76 Intellectual Property and Copyright Statements . . . . . . . 19
78 1. Introduction
80 This document defines the URI scheme "tel". The "tel" URI describes
81 resources identified by telephone numbers. A telephone number is a
82 string of decimal digits that uniquely indicates the network
83 termination point. The number contains the information necessary to
84 route the call to this termination point. (This definition is
85 derived from [E.164], but encompasses both public and private
86 numbers.)
88 The "tel" URI telephone number is not restricted in the type of
89 termination point it refers to. The termination point can be in the
90 public telephone network, a private telephone network or the
91 Internet. The termination point can be fixed or wireless and address
92 a fixed wired, mobile or nomadic terminal. The terminal addressed
93 can support any electronic communication service (ECS) including
94 voice, data and fax. The URI can refer to resources identified by a
95 telephone number, including but not limited to originators or targets
96 of a telephone call.
98 The "tel" URI is a globally unique identifier ("name") only; it does
99 not describe the steps necessary to reach a particular number and
100 does not imply dialing semantics. Furthermore, it does not refer to a
101 specific physical device, only to a telephone number.
103 Telephone numbers as commonly understood actually comprise two
104 related, but distinct concepts: as a canonical address-of-record and
105 as a dial-string. We define the concepts below:
107 Address-of-record or identifier: The telephone number is understood
108 here as the canonical address-of-record or identifier for a
109 termination point within a specific network. For the public
110 network, these numbers follow the rules in E.164 [E.164], while
111 private numbers follow the rules of the owner of the private
112 numbering plan. Subscribers publish such identifiers phone number
113 as a universal means of being reached, independent of the location
114 of the caller. (Naturally, not all numbers are reachable from
115 everywhere, for a variety of technical and local policy reasons.
116 Also, a single termination point may be reachable from different
117 networks and may have multiple such identifiers.)
118 Dial string: "Dial strings" are the actual numbers, symbols and
119 pauses entered by a user to place a phone call. A dial-string is
120 consumed by one or more network entities, and understood in the
121 context of the configuration of these entities. It is used to
122 generate a telephone number so that a call can be routed.
123 Dial-strings may require pre-pended digits to handle local PBXs,
124 and they may include post-dial DTMF signaling that could control
125 an IVR or reach an extension. Dial strings are beyond the scope
126 of this document.
128 To reach a telephone number from a phone on a PBX, for example, the
129 user of that phone has to know how to convert the telephone number
130 identifier into a dial string appropriate for that phone. The
131 telephone number itself does not convey what needs to be done for a
132 particular terminal. Instructions may include dialing "9" before
133 placing a call or prepending a "00" to reach a number in a foreign
134 country. The phone may also need to strip area and country codes.
136 The notation for phone numbers in this document is similar to that in
137 RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax
138 differs since this document describes URIs whereas RFC 3191 and RFC
139 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/"
140 to indicate parameters (qualifiers). Since URI use the forward slash
141 to describe path hierarchy, the URI scheme described here uses the
142 semicolon, in keeping with Session Initiation Protocol (SIP) URI
143 conventions [RFC3261].
145 There are at least two ways one can envision making a telephone
146 connection. In the first approach, a URI contains the dial string,
147 which is then passed to an entity that can reproduce the actions
148 specified in the dial string. For example, in an analog phone
149 system, a dialer translates the dial string into a sequence of
150 actions such as waiting for dial tone, sending DTMF digits, pausing
151 and generating post-dial DTMF digits after the callee picks up. In
152 an ISDN or ISUP environment, the recipient of the dial string
153 performs the appropriate protocol actions.
155 Another approach has the URI specify the telephone number, which can
156 be either globally unique or only be valid within a local context.
157 The dialing application is aware of the local context, knowing, for
158 example, whether special digits need to be dialed to seize an outside
159 line, whether network, pulse or tone dialing is needed and what tones
160 indicate call progress. The dialing application then converts the
161 telephone number into a dial sequence and performs the necessary
162 signaling actions. The document below assumes the second model. The
163 dialer does not have to be a user application as found in traditional
164 desktop operating systems, but could well be part of an IP-to-PSTN
165 gateway.
167 The approach pursued here has the disadvantage that certain services,
168 such as electronic banking or voicemail, cannot be specified in a
169 URI.
171 The URI can be used as a request URI in SIP [RFC3261] requests. The
172 SIP specification also inherits the 'subscriber' part of the syntax
173 as part of the 'user element' in the SIP URI. Other protocols may
174 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 if shown in the
199 grammar definitions below as they are delimiters for the "tel" URI
200 scheme. These reserved characters MUST be escaped if they appear in
201 parameter values.
203 Characters other than those in the "reserved" and "unsafe" sets (see
204 RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" encoding.
206 The "tel" URI has the following syntax:
208 telephone-uri = "tel:" telephone-subscriber
209 telephone-subscriber = global-number / local-number
210 global-number = global-number-digits *par
211 local-number = local-number-digits *par context *par
212 par = parameter / extension / isdn-subaddress
213 isdn-subaddress = ";isub=" 1*uric
214 extension = ";ext=" 1*phonedigit
215 context = ;phone-context=" descriptor
216 descriptor = domainname / global-number-digits
217 global-number-digits = "+" 1*phonedigit
218 local-number-digits = 1*phonedigit-hex
219 domainname = *( domainlabel "." ) toplabel [ "." ]
220 domainlabel = alphanum
221 / alphanum *( alphanum / "-" ) alphanum
222 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
223 parameter = ";" pname ["=" pvalue ]
224 pname = 1*( alphanum / "-" )
225 pvalue = 1*paramchar
226 paramchar = param-unreserved / unreserved / escaped
227 unreserved = alphanum / mark
228 mark = "-" | "_" | "." | "!" | "~" | "*" |
229 "'" | "(" | ")"
230 escaped = "%" HEXDIG HEXDIG
231 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
232 phonedigit = DIGIT / [ visual-separator ]
233 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
234 visual-separator = "-" / "." / "(" / ")"
235 alphanum = ALPHA / DIGIT
237 Each parameter name ("pname"), the ISDN subaddress, the extension and
238 the context MUST NOT appear more than once. The order of the URL
239 parameters is immaterial. The ISDN subaddress or extension SHOULD
240 appear first, if present, followed by the context parameter, if
241 present, followed by any other parameters in lexicographical order.
243 This simplifies comparison when the "tel" URI is compared
244 character-by-character, such as in SIP URIs [RFC3261].
246 4. URI Comparisons
248 Two "tel" URIs are equivalent according to the following rules:
250 o URI are not equal if one is a 'local-number and the other a
251 'global-number'.
252 o For mandatory additional parameters (Section 5.4) and the
253 'phone-context' and 'extension' parameters defined in this
254 document, 'phone-number' parameter values are compared
255 digit-by-digit after removing all 'visual-separator's from
256 consideration.
257 o Parameters are compared according to 'pname', regardless of the
258 order they appeared in the URI. If one URI has a parameter name
259 not found in the other, the two URIs are not equal.
260 o URI comparisons are case-insensitive.
262 All parameter names and values SHOULD use lower-case characters since
263 tel URIs may be used within contexts where comparisons are
264 case-sensitive.
266 Section 19.1.4 in the SIP specification [RFC3261] discusses one
267 such case.
269 5. Phone Numbers and Their Context
271 5.1 Phone Numbers
273 The 'subscriber part of the URI indicates the number. The phone
274 number can be represented in either global (E.164) or local notation.
275 All phone numbers MUST use the global form unless they cannot be
276 represented as such. Numbers from private numbering plans, emergency
277 ("911", "112") and some directory assistance numbers (e.g., "411")
278 and other "service codes" (numbers of the form N11 in the United
279 States) cannot be represented in global (E.164) form, and need to be
280 represented as a local number with a context. Local numbers MUST be
281 tagged with a 'phone-context' (Section 5.1.5).
283 Implementations MUST NOT assume that telephone numbers have a
284 maximum, minimum or fixed length, or that they always begin with a
285 certain number.
287 E.164 limits numbers to 15 digits. For geographic numbers, one to
288 three digits are the country code, with the remainder divided into
289 area or city code (national destination code) and subscriber
290 number. Alternatively, there is a global three-digit service
291 code, followed by a global subscriber number of up to 12 digits.
292 Finally, a "international public telecommunication number for
293 networks is composed of decimal digits arranged in three code
294 fields. The code fields are the 3-digit shared Country Code (CC)
295 field, the IC field, which varies in length between 1 to 4 digits,
296 and the Subscriber Number (SN) which can be up to 15 minus the
297 number of digits in the CC and IC fields." [E.164].
299 5.1.1 Separators in Phone Numbers
301 Phone numbers MAY contain visual separators. Visual separators
302 ('visual-separator') merely aid readability and are not used for URI
303 comparison or placing a call.
305 Despite complicating comparisons, this specification retains the
306 visual separators to follow the spirit of RFC 2396 [RFC2396],
307 which remarks that "A URI often needs to be remembered by people,
308 and it is easier for people to remember a URI when it consists of
309 meaningful components." Also, ISBN URNs documented in RFC 3187
310 [RFC3187] use visual separators in a manner similar to this
311 specification.
313 Even though ITU-T E.123 [E.123] recommends the use of space
314 characters as visual separators in printed telephone numbers,
315 "tel" URIs cannot use spaces to avoid excessive escaping.
317 5.1.2 Alphabetic Characters Corresponding to Digits
319 In some countries, it is popular to write phone numbers using
320 alphabetic characters which correspond to certain numbers on the
321 telephone keypad. The URI format does not support this notation
322 since the mapping from alphabetic characters to digits is not
323 completely uniform internationally, although there are standards
324 [E.161][T1.703] addressing this issue.
326 5.1.3 Alphabetic, * and \\# Characters as Identifiers
328 Since called and calling terminal numbers (TNs) are encoded in BCD in
329 ISUP, six additional values per digit can be encoded, sometimes
330 represented as the hexadecimal characters A through F. Similarly,
331 DTMF allows for the encoding of the symbols *, \# and A through D.
332 However, in accordance with E.164, they may not be included in global
333 numbers. Their use in local numbers is not defined, but is not
334 prohibited.
336 5.1.4 Global Numbers
338 Globally unique numbers are identified by the leading "+" character.
339 Global numbers MUST be composed with the country (CC) and national
340 (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
341 Globally unique numbers have the property of being unambiguous
342 everywhere in the world and are RECOMMENDED.
344 5.1.5 Local Numbers
346 Local numbers are unique only within a certain geographical area or a
347 certain part of the telephone network, e.g., a private branch
348 exchange (PBX), a state or province, a particular local exchange
349 carrier or a particular country. URIs with local phone numbers
350 should only appear in environments where all local entities can
351 successfully set up the call by passing the number to the dialing
352 software. Digits needed for accessing an outside line, for example,
353 are not included in local numbers. Local numbers SHOULD NOT be used
354 unless there is no way to represent the number as a global number.
356 Local numbers require that the originator and recipient are
357 configured appropriately, so that they can insert and recognize
358 the correct descriptors. Since there is no algorithm to
359 independently pick the same descriptor, labeling numbers with
360 their context increases the chances of mis-configuration, so that
361 valid identifiers are rejected by mistake. The algorithm to
362 select descriptors was chosen that accidental collisions should be
363 rare, but they cannot be ruled out.
365 Local numbers MUST have a 'phone-context' parameter that identifies
366 the scope of their validity. The parameter MUST be chosen to
367 unambiguously identify the local context within which the number is
368 unique. Thus, the combination of the descriptor in the
369 'phone-context' parameter and local number is again globally unique.
370 The parameter value is defined by the assignee of the local number.
371 It does NOT indicate a prefix that turns the local number into a
372 global (E.164) number.
374 There are two ways to label the context: via a global number or any
375 number of its leading digits (e.g., "+33") and via a domain name,
376 e.g., "houston.example.com". The choice between the two is left to
377 the "owner" of the local number and is governed by whether there is a
378 global number or domain name that is a valid identifier for a
379 particular local number.
381 The domain name does not have to resolve to any actual host, but MUST
382 be under the administrative control of the entity managing the local
383 phone context.
385 A global number context consists of the initial digits of a valid
386 global number. All global numbers matching these initial digits must
387 be assigned to the same organization that is describing the context
388 and no such matching number can be used by any other organization.
389 If such an initial string of digits does not exist, the organization
390 should use the lowest number of the global number range assigned to
391 it. (This can occur if two organizations share the same decimal
392 block of numbers. For example, assume an organization owns the
393 number range +1-212-939-7000 through +1-212-939-7199. +1-212-939-7
394 would not be a valid global number context, but +1-212-939-7000 would
395 work.) It is not required that local numbers within the context
396 actually begin with the chosen set of initial numbers.
398 For a local number defined within a PBX, the organization can choose
399 any number under its control to identify the context. For example, a
400 context consisting of any of the organization's global numbers may be
401 suitable, or a substring that is completely occupied by the
402 organization. For example, +49-6151-16 would be a suitable context
403 for the TU Darmstadt, as it uses all numbers starting with those
404 digits.
406 A context consisting of the initial digits of a global number does
407 not imply that adding these to the local number will generate a valid
408 E.164 number. It might do so by coincidence, but this cannot be
409 relied upon. (For example, "911" should be labeled with the context
410 "+1", but "+1-911" is not a valid E.164 number.)
412 National freephone numbers do not need a context, even though they
413 are not necessarily reachable from outside a particular country code
414 or numbering plan. Recall that "tel" URIs are identifiers; it is
415 sufficient that a global number is unique, but it is not required
416 that it be reachable from everywhere.
418 Even non-freephone numbers may be out of date or not be reachable
419 from a particular location. For example, premium services such as
420 "900" numbers in the North American numbering plan are often not
421 dialable from outside the particular country code.
423 The two label types were chosen so that, in almost all cases, a
424 local administrator can pick an identifier that is reasonably
425 descriptive and does not require a new IANA-managed assigned
426 number. It is up to the administrator to assign an appropriate
427 identifier and to use it consistently. Often, an organization can
428 choose among several different identifiers.
430 If the recipient of a "tel" URI uses the URI simply for
431 identification, the receiver does not need to know anything about the
432 context descriptor. It simply treats it as one part of a globally
433 unique identifier, with the other being the local number. If a
434 recipient of the URI intends to place a call to the local number, it
435 MUST verify that it is within the same context as one of the
436 descriptors. If it is not within the same context, it MUST NOT
437 initiate the call and treat the URI like an invalid destination.
439 5.2 ISDN Subaddresses
441 A phone number MAY also contain an 'isdn-subaddress"> parameter which
442 indicates an ISDN subaddress.
444 ISDN subaddresses typically contain IA5 characters, but may contain
445 any octet value.
447 5.3 Extensions
449 Extensions identify stations behind a PBX and are roughly equivalent
450 to ISDN subaddresses. They are identified with the 'extension">
451 parameter. At most one of the 'isdn-subaddress and 'extension
452 parameters can appear in a tel URI, i.e., they cannot appear both at
453 the same time.
455 5.4 Other Parameters
457 Future extensions to this URI scheme may add other parameters
458 ('parameter in the ABNF). Such parameters can be either mandatory or
459 optional. Mandatory parameters start with "m-". An implementation
460 MAY ignore optional parameters. An implementation MUST NOT use the
461 URI if it contains unknown mandatory parameters. The "m-" prefix
462 cannot be added to parameters that were already registered (except to
463 create a new, logically distinct parameter). The "phone-context"
464 parameter in this document is mandatory.
466 For example, 'parameter' parameters can be used to store
467 application-specific additional data about the phone number, its
468 intended use, or any conversions that have been applied to the
469 number.
471 Entities that forward protocol requests containing tel URIs with
472 optional parameters MUST NOT delete or modify parameters they do not
473 understand.
475 All new parameters MUST be registered with IANA.
477 6. Examples
479 tel:+1-201-555-0123 This URI points to a phone number in the United
480 States. The hyphens are included to make the number more
481 human-readable; they separate country, area codes and subscriber
482 number.
483 tel:7042;phone-context=cs.columbia.edu: The URI describes a local
484 phone number valid within the context "cs.columbia.edu".
485 tel:863-1234;phone-context=+1-914-555: The URI describes a local
486 phone number that is valid within a particular phone prefix.
488 7. Rationale
490 7.1 Why Not Just Put Telephone Numbers in SIP URIs?
492 The "tel" URI describes a service, reaching a telephone number, that
493 is independent of the means of doing so, be it via a SIP-to-PSTN
494 gateway, a direct SIP call via ENUM translation, some other signaling
495 protocols such as H.323 or a traditional circuit-switched call
496 initiated on the client side via, say, TAPI. It is thus, in spirit,
497 closer to the URN schemes that also leave the resolution to an
498 external mechanism. The same "tel" URI may get translated to any
499 number of other URIs in the process of setting up the call.
501 7.2 Why Not Distinguish Between Call Types?
503 Signaling protocols such as SIP allow to negotiate the call type and
504 parameters, making the very basic indication within the URL scheme
505 moot. Also, since the call type can change frequently, any such
506 indication in a URI is likely to be out of date. If such designation
507 is desired for a device that directly places calls without a
508 signaling protocol such as SIP, mechanisms such as the "type"
509 attribute for the "A" element in HTML may be more appropriate.
511 7.3 Why tel?
513 "Tel" was chosen since it is widely recognized none of the other
514 suggestions appeared appropriate. "Callto" was discarded since URI
515 schemes locate a resource and do not specify an action to be taken.
516 "Telephone" and "phone" were considered too long and not as
517 internationally recognized.
519 7.4 Do Not Confuse Numbers with How They Are Dialed
521 As an example, the E.164 number "+1-212-555-3141" will be dialed in
522 many countries as 00-1-212-555-3141, where the leading "00" is a
523 prefix for international calls. (In general, "+" in E.164 indicates
524 that an international prefix is required.) Tel URIs MUST NOT contain
525 the local dialing prefixes in numbers such as +1-212-555-3141, as the
526 transformation back to an international number is not guaranteed to
527 be correct or unique.
529 If a network entity receives a "tel" URI containing a local number,
530 it MUST make sure that it knows the context in which the local phone
531 number is to be processed, or else the number MUST NOT be used.
532 Equally, the originator of a "tel" URI must take into consideration
533 that the recipient may have insufficient information about the phone
534 number's context.
536 8. Usage of Telephone URIs in HTML
538 Links using the "tel" URL SHOULD enclose the telephone number, so
539 that users can easily predict the action taken when following the
540 link.
542 Dial +1-212-555-0101
543 for assistance.
545 instead of
547 Dial this number
548 for assistance.
550 On a public HTML page, the telephone number in the URI SHOULD always
551 be in the global form, even if the text of the link uses some local
552 format.
554 Telephone (if dialing in the United States):
555 (201) 555-0111
557 or even
559 For having RFCs read aloud, call
560 1-555-IETF-RFC.
562 9. Use of tel URIs with SIP (Informative)
564 SIP can use the "tel" URI as a Request-URI, along with "sip" and
565 "sips" URIs. For brevity, we will imply "sips" URIs when talking
566 about SIP URIs. Both "tel" and SIP URIs can contain telephone
567 numbers. In SIP URIs, they appear as the user part, i.e., before the
568 @ symbol (Section 19.1.6 in [RFC3261]).
570 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
571 proxy servers has to translate the tel URI to a SIP URI, with the
572 host part of that URI pointing to a gateway. Typically, the outbound
573 proxy server, as the first proxy server visited by a call request,
574 performs this translation. A proxy server can translate all tel URIs
575 to the same SIP host name or select a different gateway for different
576 tel prefixes, based, for example, on information learned from TRIP.
577 However, a proxy server could also delegate this translation task to
578 any other proxy server since proxy servers are free to apply whatever
579 routing logic they desire.
581 As noted earlier, all phone numbers MUST use the global form unless
582 they cannot be represented as such. If the local-number format is
583 used, it MUST be qualified by the 'phone-context' parameter.
584 Effectively, the combination of local number and phone context makes
585 the tel URI globally unique.
587 While web pages, vCard business cards, address books and directories
588 can easily contain global tel URIs, users on twelve-button (IP)
589 phones cannot dial such numbers directly and are typically accustomed
590 to dialing shorter strings, e.g., for PBX extensions or local
591 numbers. These so-called dial-strings (Section 1) are not directly
592 represented by tel URIs, as noted. We refer to the translation of
593 dial strings into SIP and tel URIs, global or local, as the dial
594 plan. There are at least two appropriate ways to deal with dial
595 strings in SIP terminals, local translation and proxy translation,
596 described in turn below.
598 9.1 Local Translation
600 A SIP UA can use a dial plan to translate dial strings into SIP or
601 "tel" URIs. The dial plan can be manually configured or, preferably,
602 be downloaded as part of a device configuration mechanism. (At this
603 time, there is no standardized mechanism for this.)
605 A mobile user can use at least two dial plans, namely the dial plan
606 for the network that he is currently visiting and the dial plan for
607 the user's home network. Generally, dialed numbers that are meant to
608 represent global numbers will look the same after the translation
609 regardless of the dial plan, even if, say, the visited network uses
610 '0' for dialing an 'outside' number and the user's home network uses
611 '9', as long as the user is aware of the current dial plan. However,
612 local extensions that do not have a direct global equivalent may well
613 behave differently. To avoid any ambiguity, the dial plan MUST
614 insert a suitable 'phone-context' string when performing the
615 translation. If the 'phone-context' is a domain name, there are
616 three cases:
617 1. The outbound proxy recognizes the domain name in the SIP URI as
618 its local context and can route the request to a gateway that
619 understands the local number.
620 2. The outbound proxy does not use the same phone context, but can
621 route to a proxy that handles this phone context. This routing
622 can be done via a lookup table or the domain name of the phone
623 context might be set up to reflect the SIP domain name of a
624 suitable proxy. For example, a proxy may always route calls with
625 tel URIs like
627 tel:1234;phone-context=munich.example.com
629 to the SIP proxy located at munich.example.com. (Proxies that
630 receive a tel URI with a context they do not understand are
631 obligated to return a 404 (Not Found) status resonse, so that an
632 outbound proxy may decide to attempt such a heuristic.)
633 3. The outbound proxy does not recognize the phone context and
634 cannot find the appropriate proxy cognizant of that phone
635 context. In that case, the translation fails and the outbound
636 proxy returns a 404 (Not Found) error response.
638 9.2 Proxy Translation
640 In proxy translation mode, the SIP UA simply turns the dialed digits
641 into the user part of the SIP URI and appends a ';user=phone'
642 parameter and provides an appropriate phone context reflecting the
643 local dialing plan. The host name or IP address of the outbound
644 proxy is made the host part of the SIP request URI. The outbound
645 proxy can then apply the dial plan indicated by the phone context in
646 the URI to translate the SIP URI into a "tel" URI or other SIP URI.
647 Translation into a "tel" URI makes sense only if the proxy wants to
648 delegate finding the PSTN gateway to another proxy. For example,
649 after the user with a location-specified dial plan located in domain
650 "munich.example.com" dials the digits "1234", the device converts
651 this into a SIP URI:
653 sip:1234;phone-context=munich.example.com@example.com;user=phone
655 Alternatively, the SIP UA can issue a call with a "tel" URI. For this
656 example, it might be:
658 tel:1234;phone-context=munich.example.com
660 Using a SIP URI is more robust and is thus the preferred approach.
662 Since a single proxy may receive calls from many different
663 locations with different local dial plans, devices that rely on
664 the proxy for number translation SHOULD always be configured with
665 a context. Otherwise, for example, a provider or enterprise would
666 have to provision a separate proxy for each branch office or
667 geographic area with its own dial plan.
669 10. IANA Considerations
671 IANA is requested to update the reference to RFC 2806 in the URI
672 scheme registry for the 'tel' scheme to this document.
674 "Tel" URI parameters ('parameter') MUST be registered with IANA.
675 Mandatory parameters must be described in a standards-track RFC,
676 while an informational RFC is sufficient for other parameters.
678 The registration must indicate:
680 Parameter name: The name used for the parameter, according to the BNF
681 in Section 3.
682 Applicability: A brief description of its applicability.
684 Mandatory? Whether the parameter is mandatory or not; only the names
685 of mandatory parameters must start with "m-" as described in
686 Section 5.4.;
687 Specification: A reference to the specification that defines the
688 parameter and its syntax.
690 11. Acknowledgments
692 This document is derived from RFC 2806 [RFC2806], written by Antti
693 V�h�-Sipil�. Flemming Andreasen, Francois Audet, Lawrence Conroy,
694 Cullen Jennings, Michael Hammer, Andrew Main, Xavier Marjou, Jon
695 Peterson, Mike Pierce, Jonathan Rosenberg and James Yu provided
696 extensive comments.
698 12. Security Considerations
700 The security considerations parallel those for the mailto URL
701 [RFC2368].
703 A recipient of a "tel" URI SHOULD NOT place calls without the consent
704 of its owner. Placing calls automatically without appropriate user
705 confirmation may incur a number of risks, such as those described
706 below.
708 o Calls may incur costs.
709 o The URI may be used to place malicious or annoying calls.
710 o A call will take the user's phone line off-hook, thus preventing
711 its use.
712 o A call may reveal the user's, possibly unlisted, phone number to
713 the remote host in the caller identification data, and may allow
714 the attacker to correlate the user's phone number with other
715 information such as the e-mail or IP address.
717 13. Changes Since RFC 2806
719 The specification is syntactically backwards-compatible with the
720 "tel" URI defined in RFC 2806 [RFC2806], but has been completely
721 rewritten. This document more clearly distinguishes telephone
722 numbers as identifiers of network termination points from dial
723 strings and removes the latter from the purview of "tel" URIs.
724 Compared to RFC 2806, references to carrier selection, dial context,
725 fax and modem URIs, post-dial strings and pause characters have been
726 removed. The URI syntax now conforms to RFC 2396 [RFC2396].
728 A section on using tel URIs in SIP was added.
730 Normative References
732 [E.123] , ITU., "Notation for national and international telephone
733 numbers, e-mail addresses and web addresses",
734 Recommendation E.123, February 2001.
736 [E.161] , ITU., "Arrangement of digits, letters and symbols on
737 telephones and other devices that can be used for gaining
738 access to a telephone network", Recommendation E.161, May
739 1995.
741 [E.164] , ITU., "The international public telecommunication
742 numbering plan", Recommendation E.164, May 1997.
744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
745 Requirement Levels", BCP 14, RFC 2119, March 1997.
747 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
748 Specifications: ABNF", RFC 2234, November 1997.
750 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet
751 Mail", RFC 3191, October 2001.
753 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet
754 Mail", RFC 3192, October 2001.
756 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
757 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
758 "SIP: Session Initiation Protocol", RFC 3261, June 2002.
760 [T1.703] , ANSI., "Allocation of Letters to the Keys of Numeric
761 Keypads for Telecommunications", Standard T1.703-1995
762 (R1999), 1999.
764 Informative References
766 [I-D.yu-tel-url]
767 Yu, J., "New Parameters for the 'tel' URL to Support
768 Number Portability and Freephone Service",
769 draft-yu-tel-url-08 (work in progress), November 2003.
771 [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
772 scheme", RFC 2368, July 1998.
774 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
775 Resource Identifiers (URI): Generic Syntax", RFC 2396,
776 August 1998.
778 [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
779 April 2000.
781 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard
782 Book Numbers as Uniform Resource Names", RFC 3187, October
783 2001.
785 Author's Address
787 Henning Schulzrinne
788 Columbia University
789 Department of Computer Science
790 450 Computer Science Building
791 New York, NY 10027
792 US
794 Phone: +1 212 939 7042
795 EMail: hgs@cs.columbia.edu
796 URI: http://www.cs.columbia.edu
798 Intellectual Property Statement
800 The IETF takes no position regarding the validity or scope of any
801 Intellectual Property Rights or other rights that might be claimed to
802 pertain to the implementation or use of the technology described in
803 this document or the extent to which any license under such rights
804 might or might not be available; nor does it represent that it has
805 made any independent effort to identify any such rights. Information
806 on the IETF's procedures with respect to rights in IETF Documents can
807 be found in BCP 78 and BCP 79.
809 Copies of IPR disclosures made to the IETF Secretariat and any
810 assurances of licenses to be made available, or the result of an
811 attempt made to obtain a general license or permission for the use of
812 such proprietary rights by implementers or users of this
813 specification can be obtained from the IETF on-line IPR repository at
814 http://www.ietf.org/ipr.
816 The IETF invites any interested party to bring to its attention any
817 copyrights, patents or patent applications, or other proprietary
818 rights that may cover technology that may be required to implement
819 this standard. Please address the information to the IETF at
820 ietf-ipr@ietf.org.
822 Disclaimer of Validity
824 This document and the information contained herein are provided on an
825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
827 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
828 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
829 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
832 Copyright Statement
834 Copyright (C) The Internet Society (2004). This document is subject
835 to the rights, licenses and restrictions contained in BCP 78, and
836 except as set forth therein, the authors retain all their rights.
838 Acknowledgment
840 Funding for the RFC Editor function is currently provided by the
841 Internet Society.