idnits 2.17.1
draft-ietf-iptel-rfc2806bis-03.txt:
-(708): 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):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
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-03', but the file name used is
'draft-ietf-iptel-rfc2806bis-03'
== 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).
== 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 (February 15, 2004) is 7377 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)
** 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 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-tel-rfc2806bis-03
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at http://
24 www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on August 15, 2004.
31 Copyright Notice
33 Copyright (C) The Internet Society (2004). All Rights Reserved.
35 Abstract
37 This document specifies the URI (Uniform Resource Identifier) scheme
38 "tel". The ``tel'' URI describes resources identified by telephone
39 numbers.
41 Table of Contents
43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
44 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
45 3. URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
46 4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . 9
47 5. Phone Numbers and Their Context . . . . . . . . . . . . . . 10
48 5.1 Phone Numbers . . . . . . . . . . . . . . . . . . . . . . . 10
49 5.1.1 Separators in Phone Numbers . . . . . . . . . . . . . . . . 10
50 5.1.2 Alphabetic Characters Corresponding to Digits . . . . . . . 11
51 5.1.3 Alphabetic, * and \\# Characters as Identifiers . . . . . . 11
52 5.1.4 Global Numbers . . . . . . . . . . . . . . . . . . . . . . . 11
53 5.1.5 Local Numbers . . . . . . . . . . . . . . . . . . . . . . . 11
54 5.2 ISDN Subaddresses . . . . . . . . . . . . . . . . . . . . . 13
55 5.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13
56 5.4 Other Parameters . . . . . . . . . . . . . . . . . . . . . . 13
57 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
58 7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 16
59 7.1 Why Not Just Put Telephone Numbers in SIP URIs? . . . . . . 16
60 7.2 Why Not Distinguish Between Call Types? . . . . . . . . . . 16
61 7.3 Why tel? . . . . . . . . . . . . . . . . . . . . . . . . . . 16
62 7.4 Do Not Confuse Numbers with How They Are Dialed . . . . . . 16
63 8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . 17
64 9. Use of tel URIs with SIP (Informative) . . . . . . . . . . . 18
65 9.1 Local Translation . . . . . . . . . . . . . . . . . . . . . 18
66 9.2 Proxy Translation . . . . . . . . . . . . . . . . . . . . . 19
67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22
69 12. Security Considerations . . . . . . . . . . . . . . . . . . 23
70 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 24
71 13.1 Changes from ietf-02 to ietf-03 . . . . . . . . . . . . . . 24
72 13.2 Changes from ietf-00 to ietf-01 . . . . . . . . . . . . . . 24
73 13.3 Changes from -08 to draft-ietf-iptel-rfc2806bis-00 . . . . . 24
74 13.4 Changes Since -07 . . . . . . . . . . . . . . . . . . . . . 24
75 13.5 Changes Since -06 . . . . . . . . . . . . . . . . . . . . . 24
76 13.6 Changes Since -05 . . . . . . . . . . . . . . . . . . . . . 24
77 13.7 Changes Since -04 . . . . . . . . . . . . . . . . . . . . . 24
78 13.8 Changes Since -03 . . . . . . . . . . . . . . . . . . . . . 25
79 13.9 Changes Since -02 . . . . . . . . . . . . . . . . . . . . . 25
80 13.10 Changes Since -01 . . . . . . . . . . . . . . . . . . . . . 25
81 13.11 Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 25
82 Normative References . . . . . . . . . . . . . . . . . . . . 26
83 Informative References . . . . . . . . . . . . . . . . . . . 27
84 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
85 Intellectual Property and Copyright Statements . . . . . . . 28
87 1. Introduction
89 This document defines the URI scheme "tel". The "tel" URI describes
90 resources identified by telephone numbers. A telephone number is a
91 string of decimal digits that uniquely indicates the network
92 termination point. The number contains the information necessary to
93 route the call to this termination point. (This definition is
94 derived from [E.164], but encompasses both public and private
95 numbers.)
97 The "tel" URI telephone number is not restricted in the type of
98 termination point it refers to. The termination point can be in the
99 public telephone network, a private telephone network or the
100 Internet. The termination point can be fixed or wireless and address
101 a fixed wired, mobile or nomadic terminal. The terminal addressed
102 can support any electronic communication service (ECS) including
103 voice, data and fax. The URI can refer to resources identified by a
104 telephone number, including but not limited to originators or targets
105 of a telephone call.
107 The "tel" URI is a globally unique identifier ("name") only; it does
108 not describe the steps necessary to reach a particular number and
109 does not imply dialing semantics. Furthermore, it does not refer to a
110 specific physical device, only to a telephone number.
112 Telephone numbers as commonly understood actually comprise two
113 related, but distinct concepts: as a canonical address-of-record and
114 as a dial-string. We define the concepts below:
116 Address-of-record or identifier: The telephone number is understood
117 here as the canonical address-of-record or identifier for a
118 termination point within a specific network. For the public
119 network, these numbers follow the rules in E.164 [E.164], while
120 private numbers follow the rules of the owner of the private
121 numbering plan. Subscribers publish such identifiers phone number
122 as a universal means of being reached, independent of the location
123 of the caller. (Naturally, not all numbers are reachable from
124 everywhere, for a variety of technical and local policy reasons.
125 Also, a single termination point may be reachable from different
126 networks and may have multiple such identifiers.)
128 Dial string: "Dial strings" are the actual numbers, symbols and
129 pauses entered by a user to place a phone call. A dial-string is
130 consumed by one or more network entities, and understood in the
131 context of the configuration of these entities. It is used to
132 generate a telephone number so that a call can be routed.
133 Dial-strings may require pre-pended digits to handle local PBXs,
134 and they may include post-dial DTMF signaling that could control
135 an IVR or reach an extension. Dial strings are beyond the scope
136 of this document.
138 To reach a telephone number from a phone on a PBX, for example, the
139 user of that phone has to know how to convert the telephone number
140 identifier into a dial string appropriate for that phone. The
141 telephone number itself does not convey what needs to be done for a
142 particular terminal. Instructions may include dialing "9" before
143 placing a call or prepending a "00" to reach a number in a foreign
144 country. The phone may also need to strip area and country codes.
146 The notation for phone numbers in this document is similar to that in
147 RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax
148 differs since this document describes URIs whereas RFC 3191 and RFC
149 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/"
150 to indicate parameters (qualifiers). Since URI use the forward slash
151 to describe path hierarchy, the URI scheme described here uses the
152 semicolon, in keeping with Session Initiation Protocol (SIP) URI
153 conventions [RFC3261].
155 There are at least two ways one can envision making a telephone
156 connection. In the first approach, a URI contains the dial string,
157 which is then passed to an entity that can reproduce the actions
158 specified in the dial string. For example, in an analog phone
159 system, a dialer translates the dial string into a sequence of
160 actions such as waiting for dial tone, sending DTMF digits, pausing
161 and generating post-dial DTMF digits after the callee picks up. In
162 an ISDN or ISUP environment, the recipient of the dial string
163 performs the appropriate protocol actions.
165 Another approach has the URI specify the telephone number, which can
166 be either globally unique or only be valid within a local context.
167 The dialing application is aware of the local context, knowing, for
168 example, whether special digits need to be dialed to seize an outside
169 line, whether network, pulse or tone dialing is needed and what tones
170 indicate call progress. The dialing application then converts the
171 telephone number into a dial sequence and performs the necessary
172 signaling actions. The document below assumes the second model. The
173 dialer does not have to be a user application as found in traditional
174 desktop operating systems, but could well be part of an IP-to-PSTN
175 gateway.
177 The approach pursued here has the disadvantage that certain services,
178 such as electronic banking or voicemail, cannot be specified in a
179 URI.
181 The URI can be used as a request URI in SIP [RFC3261] requests. The
182 SIP specification also inherits the 'subscriber' part of the syntax
183 as part of the 'user element' in the SIP URI. Other protocols may
184 use this URI for both query-based and prefix-based applications.
186 The "tel" URI does not specify the call type such as voice, fax, or
187 data call and does not provide the connection parameters for a data
188 call. The type and parameters are assumed to be negotiated either
189 in-band by the telephone device or through a signaling protocol such
190 as SIP.
192 2. Terminology
194 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
195 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
196 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
197 [RFC2119] and indicate requirement levels for compliant
198 implementations.
200 3. URI Syntax
202 The URI is defined using the ABNF (augmented Backus-Naur form)
203 described in RFC 2234 [RFC2234] and uses elements from the core
204 definitions (Appendix A of RFC 2234).
206 The syntax definition follows RFC 2396 [RFC2396], indicating the
207 actual characters contained in the URI. Note that the reserved
208 characters "+", ";", "=", and "?" MUST NOT be escaped if shown in the
209 grammar definitions below as they are delimiters for the "tel" URI
210 scheme. These reserved characters MUST be escaped if they appear in
211 parameter values.
213 Characters other than those in the "reserved" and "unsafe" sets (see
214 RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" encoding.
216 The "tel" URI has the following syntax:
218 telephone-uri = "tel:" telephone-subscriber
219 telephone-subscriber = global-number / local-number
220 global-number = global-number-digits *par
221 local-number = local-number-digits *par context *par
222 par = parameter / extension / isdn-subaddress
223 isdn-subaddress = ";isub=" 1*uric
224 extension = ";ext=" 1*phonedigit
225 context = ;phone-context=" descriptor
226 descriptor = domainname / global-number-digits
227 global-number-digits = "+" 1*phonedigit
228 local-number-digits = 1*phonedigit-hex
229 domainname = *( domainlabel "." ) toplabel [ "." ]
230 domainlabel = alphanum
231 / alphanum *( alphanum / "-" ) alphanum
232 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
233 parameter = ";" pname ["=" pvalue ]
234 pname = 1*( alphanum / "-" )
235 pvalue = 1*paramchar
236 paramchar = param-unreserved / unreserved / escaped
237 unreserved = alphanum / mark
238 mark = "-" | "_" | "." | "!" | "~" | "*" |
239 "'" | "(" | ")"
240 escaped = "%" HEXDIG HEXDIG
241 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
242 phonedigit = DIGIT / [ visual-separator ]
243 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
244 visual-separator = "-" / "." / "(" / ")"
245 alphanum = ALPHA / DIGIT
247 Each parameter name ("pname"), the ISDN subaddress, the extension and
248 the context MUST NOT appear more than once. The order of the URL
249 parameters is immaterial. The ISDN subaddress or extension SHOULD
250 appear first, if present, followed by the context parameter, if
251 present, followed by any other parameters in lexicographical order.
253 This simplifies comparison when the "tel" URI is compared
254 character-by-character, such as in SIP URIs [RFC3261].
256 4. URI Comparisons
258 Two "tel" URIs are equivalent according to the following rules:
260 o URI are not equal if one is a 'local-number and the other a
261 'global-number'.
263 o For mandatory additional parameters (Section 5.4) and the
264 'phone-context' and 'extension' parameters defined in this
265 document, 'phone-number' parameter values are compared
266 digit-by-digit after removing all 'visual-separator's from
267 consideration.
269 o Parameters are compared according to 'pname', regardless of the
270 order they appeared in the URI. If one URI has a parameter name
271 not found in the other, the two URIs are not equal.
273 o URI comparisons are case-insensitive.
275 All parameter names and values SHOULD use lower-case characters since
276 tel URIs may be used within contexts where comparisons are
277 case-sensitive.
279 Section 19.1.4 in the SIP specification [RFC3261] discusses one
280 such case.
282 5. Phone Numbers and Their Context
284 5.1 Phone Numbers
286 The 'subscriber part of the URI indicates the number. The phone
287 number can be represented in either global (E.164) or local notation.
288 All phone numbers MUST use the global form unless they cannot be
289 represented as such. Numbers from private numbering plans, emergency
290 ("911", "112") and some directory assistance numbers (e.g., "411")
291 and other "service codes" (numbers of the form N11 in the United
292 States) cannot be represented in global (E.164) form, and need to be
293 represented as a local number with a context. Local numbers MUST be
294 tagged with a 'phone-context' (Section 5.1.5).
296 Implementations MUST NOT assume that telephone numbers have a
297 maximum, minimum or fixed length, or that they always begin with a
298 certain number.
300 E.164 limits numbers to 15 digits. For geographic numbers, one to
301 three digits are the country code, with the remainder divided into
302 area or city code (national destination code) and subscriber
303 number. Alternatively, there is a global three-digit service
304 code, followed by a global subscriber number of up to 12 digits.
305 Finally, a "international public telecommunication number for
306 networks is composed of decimal digits arranged in three code
307 fields. The code fields are the 3-digit shared Country Code (CC)
308 field, the IC field, which varies in length between 1 to 4 digits,
309 and the Subscriber Number (SN) which can be up to 15 minus the
310 number of digits in the CC and IC fields." [E.164].
312 5.1.1 Separators in Phone Numbers
314 Phone numbers MAY contain visual separators. Visual separators
315 ('visual-separator') merely aid readability and are not used for URI
316 comparison or placing a call.
318 Despite complicating comparisons, this specification retains the
319 visual separators to follow the spirit of RFC 2396 [RFC2396],
320 which remarks that "A URI often needs to be remembered by people,
321 and it is easier for people to remember a URI when it consists of
322 meaningful components." Also, ISBN URNs documented in RFC 3187
323 [RFC3187] use visual separators in a manner similar to this
324 specification.
326 Even though ITU-T E.123 [E.123] recommends the use of space
327 characters as visual separators in printed telephone numbers,
328 "tel" URIs cannot use spaces to avoid excessive escaping.
330 5.1.2 Alphabetic Characters Corresponding to Digits
332 In some countries, it is popular to write phone numbers using
333 alphabetic characters which correspond to certain numbers on the
334 telephone keypad. The URI format does not support this notation
335 since the mapping from alphabetic characters to digits is not
336 completely uniform internationally, although there are standards
337 [E.161][T1.703] addressing this issue.
339 5.1.3 Alphabetic, * and \\# Characters as Identifiers
341 Since called and calling terminal numbers (TNs) are encoded in BCD in
342 ISUP, six additional values per digit can be encoded, sometimes
343 represented as the hexadecimal characters A through F. Similarly,
344 DTMF allows for the encoding of the symbols *, \# and A through D.
345 However, in accordance with E.164, they may not be included in global
346 numbers. Their use in local numbers is not defined, but is not
347 prohibited.
349 5.1.4 Global Numbers
351 Globally unique numbers are identified by the leading "+" character.
352 Global numbers MUST be composed with the country (CC) and national
353 (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
354 Globally unique numbers have the property of being unambiguous
355 everywhere in the world and are RECOMMENDED.
357 5.1.5 Local Numbers
359 Local numbers are unique only within a certain geographical area or a
360 certain part of the telephone network, e.g., a private branch
361 exchange (PBX), a state or province, a particular local exchange
362 carrier or a particular country. URIs with local phone numbers
363 should only appear in environments where all local entities can
364 successfully set up the call by passing the number to the dialing
365 software. Digits needed for accessing an outside line, for example,
366 are not included in local numbers. Local numbers SHOULD NOT be used
367 unless there is no way to represent the number as a global number.
369 Local numbers require that the originator and recipient are
370 configured appropriately, so that they can insert and recognize
371 the correct descriptors. Since there is no algorithm to
372 independently pick the same descriptor, labeling numbers with
373 their context increases the chances of mis-configuration, so that
374 valid identifiers are rejected by mistake. The algorithm to
375 select descriptors was chosen that accidental collisions should be
376 rare, but they cannot be ruled out.
378 Local numbers MUST have a 'phone-context' parameter that identifies
379 the scope of their validity. The parameter MUST be chosen to
380 unambiguously identify the local context within which the number is
381 unique. Thus, the combination of the descriptor in the
382 'phone-context' parameter and local number is again globally unique.
383 The parameter value is defined by the assignee of the local number.
384 It does NOT indicate a prefix that turns the local number into a
385 global (E.164) number.
387 There are two ways to label the context: via a global number or any
388 number of its leading digits (e.g., "+33") and via a domain name,
389 e.g., "houston.example.com". The choice between the two is left to
390 the "owner" of the local number and is governed by whether there is a
391 global number or domain name that is a valid identifier for a
392 particular local number.
394 The domain name does not have to resolve to any actual host, but
395 MUST"> be under the administrative control of the entity managing the
396 local phone context.
398 A global number context consists of the initial digits of a valid
399 global number. All global numbers matching these initial digits must
400 be assigned to the same organization that is describing the context
401 and no such matching number can be used by any other organization.
402 If such an initial string of digits does not exist, the organization
403 should use the lowest number of the global number range assigned to
404 it. (This can occur if two organizations share the same decimal
405 block of numbers. For example, assume an organization owns the
406 number range +1-212-939-7000 through +1-212-939-7199. +1-212-939-7
407 would not be a valid global number context, but +1-212-939-7000 would
408 work.) It is not required that local numbers within the context
409 actually begin with the chosen set of initial numbers.
411 For a local number defined within a PBX, the organization can choose
412 any number under its control to identify the context. For example, a
413 context consisting of any of the organization's global numbers may be
414 suitable, or a substring that is completely occupied by the
415 organization. For example, +49-6151-16 would be a suitable context
416 for the TU Darmstadt, as it uses all numbers starting with those
417 digits.
419 A context consisting of the initial digits of a global number does
420 not imply that adding these to the local number will generate a valid
421 E.164 number. It might do so by coincidence, but this cannot be
422 relied upon. (For example, "911" should be labeled with the context
423 "+1", but "+1-911" is not a valid E.164 number.)
425 National freephone numbers do not need a context, even though they
426 are not necessarily reachable from outside a particular country code
427 or numbering plan. Recall that "tel" URIs are identifiers; it is
428 sufficient that a global number is unique, but it is not required
429 that it be reachable from everywhere.
431 Even non-freephone numbers may be out of date or not be reachable
432 from a particular location. For example, premium services such as
433 "900" numbers in the North American numbering plan are often not
434 dialable from outside the particular country code.
436 The two label types were chosen so that, in almost all cases, a
437 local administrator can pick an identifier that is reasonably
438 descriptive and does not require a new IANA-managed assigned
439 number. It is up to the administrator to assign an appropriate
440 identifier and to use it consistently. Often, an organization can
441 choose among several different identifiers.
443 If the recipient of a "tel" URI uses the URI simply for
444 identification, the receiver does not need to know anything about the
445 context descriptor. It simply treats it as one part of a globally
446 unique identifier, with the other being the local number. If a
447 recipient of the URI intends to place a call to the local number, it
448 MUST verify that it is within the same context as one of the
449 descriptors. If it is not within the same context, it MUST NOT
450 initiate the call and treat the URI like an invalid destination.
452 5.2 ISDN Subaddresses
454 A phone number MAY also contain an 'isdn-subaddress"> parameter which
455 indicates an ISDN subaddress.
457 ISDN subaddresses typically contain IA5 characters, but may contain
458 any octet value.
460 5.3 Extensions
462 Extensions identify stations behind a PBX and are roughly equivalent
463 to ISDN subaddresses. They are identified with the 'extension">
464 parameter. At most one of the 'isdn-subaddress and 'extension
465 parameters can appear in a tel URI, i.e., they cannot appear both at
466 the same time.
468 5.4 Other Parameters
470 Future extensions to this URI scheme may add other parameters
471 ('parameter in the ABNF). Such parameters can be either mandatory or
472 optional. Mandatory parameters start with "m-". An implementation
473 MAY ignore optional parameters. An implementation MUST NOT use the
474 URI if it contains unknown mandatory parameters. The "m-" prefix
475 cannot be added to parameters that were already registered (except to
476 create a new, logically distinct parameter). The "phone-context"
477 parameter in this document is mandatory.
479 For example, 'parameter' parameters can be used to store
480 application-specific additional data about the phone number, its
481 intended use, or any conversions that have been applied to the
482 number.
484 All new parameters MUST be registered with IANA.
486 6. Examples
488 tel:+1-201-555-0123 This URI points to a phone number in the United
489 States. The hyphens are included to make the number more
490 human-readable; they separate country, area codes and subscriber
491 number.
493 tel:7042;phone-context=cs.columbia.edu: The URI describes a local
494 phone number valid within the context "cs.columbia.edu".
496 tel:863-1234;phone-context=+1-914-555: The URI describes a local
497 phone number that is valid within a particular phone prefix.
499 7. Rationale
501 7.1 Why Not Just Put Telephone Numbers in SIP URIs?
503 The "tel" URI describes a service, reaching a telephone number, that
504 is independent of the means of doing so, be it via a SIP-to-PSTN
505 gateway, a direct SIP call via ENUM translation, some other signaling
506 protocols such as H.323 or a traditional circuit-switched call
507 initiated on the client side via, say, TAPI. It is thus, in spirit,
508 closer to the URN schemes that also leave the resolution to an
509 external mechanism. The same "tel" URI may get translated to any
510 number of other URIs in the process of setting up the call.
512 7.2 Why Not Distinguish Between Call Types?
514 Signaling protocols such as SIP allow to negotiate the call type and
515 parameters, making the very basic indication within the URL scheme
516 moot. Also, since the call type can change frequently, any such
517 indication in a URI is likely to be out of date. If such designation
518 is desired for a device that directly places calls without a
519 signaling protocol such as SIP, mechanisms such as the "type"
520 attribute for the "A" element in HTML may be more appropriate.
522 7.3 Why tel?
524 "Tel" was chosen since it is widely recognized none of the other
525 suggestions appeared appropriate. "Callto" was discarded since URI
526 schemes locate a resource and do not specify an action to be taken.
527 "Telephone" and "phone" were considered too long and not as
528 internationally recognized.
530 7.4 Do Not Confuse Numbers with How They Are Dialed
532 As an example, the E.164 number "+1-212-555-3141" will be dialed in
533 many countries as 00-1-212-555-3141, where the leading "00" is a
534 prefix for international calls. (In general, "+" in E.164 indicates
535 that an international prefix is required.) Tel URIs MUST NOT contain
536 the local dialing prefixes in numbers such as +1-212-555-3141, as the
537 transformation back to an international number is not guaranteed to
538 be correct or unique.
540 If a network entity receives a "tel" URI containing a local number,
541 it MUST make sure that it knows the context in which the local phone
542 number is to be processed, or else the number MUST NOT be used.
543 Equally, the originator of a "tel" URI must take into consideration
544 that the recipient may have insufficient information about the phone
545 number's context.
547 8. Usage of Telephone URIs in HTML
549 Links using the "tel" URL SHOULD enclose the telephone number, so
550 that users can easily predict the action taken when following the
551 link.
553 Dial +1-212-555-0101
554 for assistance.
556 instead of
558 Dial this number
559 for assistance.
561 On a public HTML page, the telephone number in the URI SHOULD always
562 be in the global form, even if the text of the link uses some local
563 format.
565 Telephone (if dialing in the United States):
566 (201) 555-0111
568 or even
570 For having RFCs read aloud, call
571 1-555-IETF-RFC.
573 9. Use of tel URIs with SIP (Informative)
575 SIP can use the "tel" URI as a Request-URI, along with "sip" and
576 "sips" URIs. For brevity, we will imply "sips" URIs when talking
577 about SIP URIs. Both "tel" and SIP URIs can contain telephone
578 numbers. In SIP URIs, they appear as the user part, i.e., before the
579 @ symbol (Section 19.1.6 in [RFC3261]).
581 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
582 proxy servers has to translate the tel URI to a SIP URI, with the
583 host part of that URI pointing to a gateway. Typically, the outbound
584 proxy server, as the first proxy server visited by a call request,
585 performs this translation. A proxy server can translate all tel URIs
586 to the same SIP host name or select a different gateway for different
587 tel prefixes, based, for example, on information learned from TRIP.
588 However, a proxy server could also delegate this translation task to
589 any other proxy server since proxy servers are free to apply whatever
590 routing logic they desire.
592 As noted earlier, all phone numbers MUST use the global form unless
593 they cannot be represented as such. If the local-number format is
594 used, it MUST be qualified by the 'phone-context' parameter.
595 Effectively, the combination of local number and phone context makes
596 the tel URI globally unique.
598 While web pages, vCard business cards, address books and directories
599 can easily contain global tel URIs, users on twelve-button (IP)
600 phones cannot dial such numbers directly and are typically accustomed
601 to dialing shorter strings, e.g., for PBX extensions or local
602 numbers. These so-called dial-strings (Section 1) are not directly
603 represented by tel URIs, as noted. We refer to the translation of
604 dial strings into SIP and tel URIs, global or local, as the dial
605 plan. There are at least two appropriate ways to deal with dial
606 strings in SIP terminals, local translation and proxy translation,
607 described in turn below.
609 9.1 Local Translation
611 A SIP UA can use a dial plan to translate dial strings into SIP or
612 "tel" URIs. The dial plan can be manually configured or, preferably,
613 be downloaded as part of a device configuration mechanism. (At this
614 time, there is no standardized mechanism for this.)
616 A mobile user can use at least two dial plans, namely the dial plan
617 for the network that he is currently visiting and the dial plan for
618 the user's home network. Generally, dialed numbers that are meant to
619 represent global numbers will look the same after the translation
620 regardless of the dial plan, even if, say, the visited network uses
621 '0' for dialing an 'outside' number and the user's home network uses
622 '9', as long as the user is aware of the current dial plan. However,
623 local extensions that do not have a direct global equivalent may well
624 behave differently. To avoid any ambiguity, the dial plan MUST
625 insert a suitable 'phone-context' string when performing the
626 translation. If the 'phone-context' is a domain name, there are
627 three cases:
629 1. The outbound proxy recognizes the domain name in the SIP URI as
630 its local context and can route the request to a gateway that
631 understands the local number.
633 2. The outbound proxy does not use the same phone context, but can
634 route to a proxy that handles this phone context. This routing
635 can be done via a lookup table or the domain name of the phone
636 context might be set up to reflect the SIP domain name of a
637 suitable proxy. For example, a proxy may always route calls with
638 tel URIs like
640 tel:1234;phone-context=munich.example.com
642 to the SIP proxy located at munich.example.com. (Proxies that
643 receive a tel URI with a context they do not understand are
644 obligated to return a 404 (Not Found) status resonse, so that an
645 outbound proxy may decide to attempt such a heuristic.)
647 3. The outbound proxy does not recognize the phone context and
648 cannot find the appropriate proxy cognizant of that phone
649 context. In that case, the translation fails and the outbound
650 proxy returns a 404 (Not Found) error response.
652 9.2 Proxy Translation
654 In proxy translation mode, the SIP UA simply turns the dialed digits
655 into the user part of the SIP URI and appends a ';user=phone'
656 parameter and provides an appropriate phone context reflecting the
657 local dialing plan. The host name or IP address of the outbound
658 proxy is made the host part of the SIP request URI. The outbound
659 proxy can then apply the dial plan indicated by the phone context in
660 the URI to translate the SIP URI into a "tel" URI or other SIP URI.
661 Translation into a "tel" URI makes sense only if the proxy wants to
662 delegate finding the PSTN gateway to another proxy. For example,
663 after the user with a location-specified dial plan located in domain
664 "munich.example.com" dials the digits "1234", the device converts
665 this into a SIP URI:
667 sip:1234;phone-context=munich.example.com@example.com
668 Alternatively, the SIP UA can issue a call with a "tel" URI. For this
669 example, it might be:
671 tel:1234;phone-context=munich.example.com
673 Using a SIP URI is more robust and is thus the preferred approach.
675 Since a single proxy may receive calls from many different
676 locations with different local dial plans, devices that rely on
677 the proxy for number translation SHOULD always be configured with
678 a context. Otherwise, for example, a provider or enterprise would
679 have to provision a separate proxy for each branch office or
680 geographic area with its own dial plan.
682 10. IANA Considerations
684 IANA is requested to update the reference to RFC 2806 in the URI
685 scheme registry for the 'tel' scheme to this document.
687 "Tel" URI parameters ('parameter') MUST be registered with IANA.
688 Mandatory parameters must be described in a standards-track RFC,
689 while an informational RFC is sufficient for other parameters.
691 The registration must indicate:
693 Parameter name: The name used for the parameter, according to the BNF
694 in Section 3.
696 Applicability: A brief description of its applicability.
698 Mandatory? Whether the parameter is mandatory or not; only the names
699 of mandatory parameters must start with "m-" as described in
700 Section 5.4.;
702 Specification: A reference to the specification that defines the
703 parameter and its syntax.
705 11. Acknowledgments
707 This document is derived from RFC 2806 [RFC2806], written by Antti
708 V�h�-Sipil�. Flemming Andreasen, Francois Audet, Lawrence Conroy,
709 Cullen Jennings, Andrew Main, Michael Hammer, Jon Peterson, Mike
710 Pierce, Jonathan Rosenberg and James Yu provided extensive comments.
712 12. Security Considerations
714 The security considerations parallel those for the mailto URL
715 [RFC2368].
717 A recipient of a "tel" URI SHOULD NOT place calls without the consent
718 of its owner. Placing calls automatically without appropriate user
719 confirmation may incur a number of risks, such as those described
720 below.
722 o Calls may incur costs.
724 o The URI may be used to place malicious or annoying calls.
726 o A call will take the user's phone line off-hook, thus preventing
727 its use.
729 o A call may reveal the user's, possibly unlisted, phone number to
730 the remote host in the caller identification data, and may allow
731 the attacker to correlate the user's phone number with other
732 information such as the e-mail or IP address.
734 13. Change History
736 13.1 Changes from ietf-02 to ietf-03
738 o Added BNF definition for 'mark'.
740 o Use fictitious phone numbers.
742 13.2 Changes from ietf-00 to ietf-01
744 o Editorial changes suggested by Francois Audet.
746 o Added * and \# as characters to local numbers.
748 13.3 Changes from -08 to draft-ietf-iptel-rfc2806bis-00
750 o Editorial clarifications.
752 o Remove multiple context descriptions.
754 13.4 Changes Since -07
756 o Added section on using tel URIs in SIP.
758 13.5 Changes Since -06
760 o Clarified semantics.
762 o Removed context from freephone numbers.
764 o Added phone extensions.
766 13.6 Changes Since -05
768 o URI comparisons are case-insensitive.
770 o Specified recommended order of parameters to simplify use within
771 SIP URIs.
773 13.7 Changes Since -04
774 o ISDN subaddresses can contain any IA5 character or even binary
775 data; represented now as "uric".
777 13.8 Changes Since -03
779 o Clarified use of multiple contexts and how to express this, as a
780 comma-separated list.
782 13.9 Changes Since -02
784 o Clarifications and editorial fixes.
786 o Now, mandatory parameters are labeled, to avoid making
787 [I-D.yu-tel-url] obsolete.
789 13.10 Changes Since -01
791 The draft has been greatly simplified to reflect parts that have
792 actually been implemented.
794 o Removed references to carrier selection.
796 o Removed dial context.
798 o Removed fax and modem URIs.
800 o Removed post-dial strings.
802 o Removed pause characters.
804 13.11 Changes Since RFC 2806
806 The specification is backwards-compatible with RFC 2806.
808 o Editorial changes and clarifications. The document has been
809 shortened and reorganized. Most paragraphs have been rewritten to
810 be more concise.
812 o Syntax now conforms to RFC 2396 [RFC2396], in particular related
813 to escaping.
815 Normative References
817 [E.123] , ITU., "Notation for national and international telephone
818 numbers, e-mail addresses and web addresses",
819 Recommendation E.123, February 2001.
821 [E.161] , ITU., "Arrangement of digits, letters and symbols on
822 telephones and other devices that can be used for gaining
823 access to a telephone network", Recommendation E.161, May
824 1995.
826 [E.164] , ITU., "The international public telecommunication
827 numbering plan", Recommendation E.164, May 1997.
829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
830 Requirement Levels", BCP 14, RFC 2119, March 1997.
832 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
833 Specifications: ABNF", RFC 2234, November 1997.
835 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet
836 Mail", RFC 3191, October 2001.
838 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet
839 Mail", RFC 3192, October 2001.
841 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
842 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
843 "SIP: Session Initiation Protocol", RFC 3261, June 2002.
845 [T1.703] , ANSI., "Allocation of Letters to the Keys of Numeric
846 Keypads for Telecommunications", Standard T1.703-1995
847 (R1999), 1999.
849 Informative References
851 [I-D.yu-tel-url]
852 Yu, J., "New Parameters for the 'tel' URL to Support
853 Number Portability and Freephone Service",
854 draft-yu-tel-url-08 (work in progress), November 2003.
856 [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
857 scheme", RFC 2368, July 1998.
859 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
860 Resource Identifiers (URI): Generic Syntax", RFC 2396,
861 August 1998.
863 [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
864 April 2000.
866 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard
867 Book Numbers as Uniform Resource Names", RFC 3187, October
868 2001.
870 Author's Address
872 Henning Schulzrinne
873 Columbia University
874 Department of Computer Science
875 450 Computer Science Building
876 New York, NY 10027
877 US
879 Phone: +1 212 939 7042
880 EMail: hgs@cs.columbia.edu
881 URI: http://www.cs.columbia.edu
883 Intellectual Property Statement
885 The IETF takes no position regarding the validity or scope of any
886 intellectual property or other rights that might be claimed to
887 pertain to the implementation or use of the technology described in
888 this document or the extent to which any license under such rights
889 might or might not be available; neither does it represent that it
890 has made any effort to identify any such rights. Information on the
891 IETF's procedures with respect to rights in standards-track and
892 standards-related documentation can be found in BCP-11. Copies of
893 claims of rights made available for publication and any assurances of
894 licenses to be made available, or the result of an attempt made to
895 obtain a general license or permission for the use of such
896 proprietary rights by implementors or users of this specification can
897 be obtained from the IETF Secretariat.
899 The IETF invites any interested party to bring to its attention any
900 copyrights, patents or patent applications, or other proprietary
901 rights which may cover technology that may be required to practice
902 this standard. Please address the information to the IETF Executive
903 Director.
905 Full Copyright Statement
907 Copyright (C) The Internet Society (2004). All Rights Reserved.
909 This document and translations of it may be copied and furnished to
910 others, and derivative works that comment on or otherwise explain it
911 or assist in its implementation may be prepared, copied, published
912 and distributed, in whole or in part, without restriction of any
913 kind, provided that the above copyright notice and this paragraph are
914 included on all such copies and derivative works. However, this
915 document itself may not be modified in any way, such as by removing
916 the copyright notice or references to the Internet Society or other
917 Internet organizations, except as needed for the purpose of
918 developing Internet standards in which case the procedures for
919 copyrights defined in the Internet Standards process must be
920 followed, or as required to translate it into languages other than
921 English.
923 The limited permissions granted above are perpetual and will not be
924 revoked by the Internet Society or its successors or assignees.
926 This document and the information contained herein is provided on an
927 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
928 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
929 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
930 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
931 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
933 Acknowledgment
935 Funding for the RFC Editor function is currently provided by the
936 Internet Society.