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