Internet Engineering Task Force Internet Draft Schulzrinne/Vaha-Sipila Columbia U./Nokia draft-antti-rfc2806bis-03.txt May 12, 2002 Expires: November 2002 URIs for Telephone Calls STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Schulzrinne/Vaha-Sipila [Page 1] Internet Draft RFC2806bis May 12, 2002 Abstract This document is a revision of RFC 2806. This document specifies the URI (Uniform Resource Identifier) schemes "tel" for specifying the address of a terminal in the phone network. The tel URI is service-independent and describes voice calls (phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, for landline, ISDN and mobile subscribers. 1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 2 Introduction This document defines the URI scheme "tel" that contains telephone numbers. The telephone number can refer to terminals in the telephone network or the Internet, mobile and landline devices, voice, data and fax devices. The URI can refer to originators or targets of a telephone call. Telephone numbers as commonly understood actually comprise two | related, but distinct concepts: as a canonical address-of-record and | as a dial-string. We define the concepts below: | Address-of-record: The telephone number is understood here as | the canonical address-of-record, as they are handled by the | signaling network. Generally, this means E.164 numbers, or | numbers that can be trivially converted into them. | Subscribers publish a phone number as a universal means of | being reached. | Dial string: "Dial strings" are the actual numbers, symbols and | pauses entered by a user to place a phone call. A dial- | string is consumed by one or more network entities, and | understood in the context of the configuration of these | entities. It is used to generate a telephone number so that | a call can be routed. Dial-strings may require pre-pended | digits to handle local PBXs, and they may include post-dial | DTMF signaling that could control an IVR. Dial strings are | beyond the scope of this document. | Schulzrinne/Vaha-Sipila [Page 2] Internet Draft RFC2806bis May 12, 2002 To reach a telephone number from a particular terminal, the user of | that terminal or terminal has to know how to convert my telephone | number into a dial string appropriate for that terminal. The | telephone number itself does not convey what needs to be done for a | particular terminal. Instructions may include dialing "9" before | placing a call or prefixing a "00" to reach a number in a foreign | country. Telephone numbers are also the normalized way that addresses | are signaled in the PSTN. The notation for phone numbers is the same as in RFC 2303 [2] and RFC 2304 [3]. However, the syntax differs since this document describes URIs whereas RFC 2303 and RFC 2304 specify electronic mail addresses. RFC 2303 and RFC 2304 use "/" to indicate parameters (qualifiers). Since URI use the forward slash to describe path hierarchy, the URI schemes described here use the semicolon, in keeping with SIP URI conventions [4]. There are at least two ways one can envision making a telephone connection. In the first approach, a URI contains the dial string, which is then passed to an entity that can reproduce the actions specified in the dial string, by sending DTMF digits, waiting for dial tone, pausing and generating post-dial DTMF digits after the callee picks up. Another approach has the URI specify the telephone number, which can be either globally unique or only be valid within a local context. A dialer application is aware of local context, knowing, for example, whether special digits need to be dialed to seize an outside line, whether network, pulse or tone dialing is needed and what tones indicate call progress. The dialer then converts the telephone number into a dial string and performs the necessary signaling actions. The document below assumes the second model. The dialer does not have to be a user application as found in traditional desktop operating systems, but could well be part of an IP-to-PSTN gateway. The approach pursued here has the disadvantage that certain services, such as extensions on a PBX (when direct inward dialing is not used) or electronic banking, cannot be specified in a URI. The URI is used as a request URI in SIP [4] requests. The SIP specification also inherits the subscriber part of the syntax as part of the user element in the SIP URI. Other protocols may use this URI for both query-based and prefix-based applications. A "client" is defined as software that can parse one or more of the URIs defined in this document and possibly place a call to a remote entity. 3 URI Comparisons Schulzrinne/Vaha-Sipila [Page 3] Internet Draft RFC2806bis May 12, 2002 URI comparisons are case-sensitive except that the scheme and parameter names are case-insensitive. 4 URI Syntax The URI is defined using the ABNF (augmented Backus-Naur form) described in RFC 2234 [5] and uses elements from the core definitions (Appendix A of RFC 2234). The syntax definition follows RFC 2396, indicating the actual characters contained in the URI. Note that the reserved characters "+", ";", "=", and "?" MUST NOT be escaped if shown in the grammar definitions below as they are delimiters for the tel URI schemes. These reserved characters MUST be escaped if they appear in parameter values. Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396) are equivalent to their "% HEX HEX" encoding. The "tel" URI has the following syntax: telephone-uri = "tel:" subscriber | subscriber = global-number / local-number | global-number = "+" 1*globaldigit [isdn-subaddress] | *other | local-number = 1*localdigit | [isdn-subaddress] | 1*(context) *other | isdn-subaddress = ";isub=" 1*localdigit | context = ";phone-context=" (domain / global-number) | domainname = *( domainlabel "." ) toplabel [ "." ] | domainlabel = alphanum | / alphanum *( alphanum / "-" ) alphanum | toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum | other = ";" oname ["=" ovalue ] | oname = 1*uric | ovalue = *uric | globaldigit = DIGIT / visual-separator | localdigit = HEXDIG / visual-separator | visual-separator = "-" / "." / "(" / ")" | alphanum = ALPHA / DIGIT | 5 Phone Numbers and Their Scope 5.1 Phone Numbers Schulzrinne/Vaha-Sipila [Page 4] Internet Draft RFC2806bis May 12, 2002 The part of the URI indicates the number. The phone | number can be written in either global (E.164) or local notation. | All phone numbers SHOULD be written in the international form unless | they cannot be written as such. Numbers from private numbering plans, | emergency ("911", "112") and some directory assistance numbers (e.g., | "411") and other "service codes" (numbers of the form N11 in the | United States) cannot be written in international form, and need to | be represented with a context. Implementations MUST NOT assume that telephone numbers have a maximum, minimum or fixed length, or that they always begin with a certain number. 5.1.1 Separators in Phone Numbers Phone numbers MAY contain visual separators. Visual separators () merely aid readability and MUST be ignored by the client. Even though ITU-T E.123 [6] recommends the use of space characters as visual separators in printed telephone numbers, tel URIs MUST NOT use spaces. 5.1.2 Alphabetic Characters In some countries, it is popular to write phone numbers using alphabetic characters which correspond to certain numbers on the telephone keypad. The URI format does not support this notation since the mapping from alphabetic characters to digits is not completely uniform internationally, although there are standards [7,8] addressing this issue. Since called and calling terminal numbers (TNs) are encoded in BCD in ISUP, this allows for six additional values per digit, sometimes represented as as the hexadecimal characters A through F. However, in accordance with E.164, they may not be included in global numbers. Their use in local numbers is not defined, but it not prohibited. 5.1.3 Global and Local Numbers Global (international) numbers are identified by the "+" character prefix. International numbers MUST be written with the country (CC) and national (NSN) numbers as specified in E.123 and E.164 [6,9]. International numbers have the property of being unambiguous everywhere in the world and are RECOMMENDED. Local numbers only work within a certain geographical area or a certain part of the telephone network, e.g., a private branch Schulzrinne/Vaha-Sipila [Page 5] Internet Draft RFC2806bis May 12, 2002 exchange (PBX). URIs with local phone numbers should only appear in environments where all local entities can successfully set up the call by passing the number to the dialing software. Digits needed for accessing an outside line, for example, are not included in local numbers. The phone-context parameters can be used to label the local context. | The parameter value is implementation-defined; care must be taken | that the URL does not "escape" the administrative domain that | administers the namespace. [TBD: This is hardly satisfying.] There | are two common ways to label the context: via a global number prefix | (e.g., "+33") and via a domain name, e.g., "houston.example.com". The | domain name does not have to resolve to any actual host, but MUST be | under the administrative control of the entity managing the local | phone context. | The global number prefix does not imply that adding it to the number | will generate a valid E.164 number. (For example, "911" should have | be labeled with the context "+1", but "+1-911" is not a valid E.164 | number.) | [TBD: Should the ABNF restrict the phone-context?] Multiple phone-context parameters can be used to indicate that the | number is valid in all labeled contexts. 5.2 ISDN Subaddresses A phone number MAY also contain an parameter which indicates an ISDN subaddress. The client SHOULD support ISDN subaddresses if it supports ISDN call setup. If ISDN subaddressing is not supported by the caller, MUST be ignored and the user SHOULD be notified. The user or the client MAY opt not to place a call if this feature is not supported. 5.3 Other Parameters Future extensions to these URI schemes may add other parameters ( in the BNF). Such parameters can be either mandatory or optional. Mandatory parameters start with "m-". An implementation MAY ignore optional parameters. An implementation MUST NOT use the URI if it contains unknown mandatory parameters. For example, parameters can be used to store application- specific additional data about the phone number, its intended use, or any conversions that have been applied to the number. All new parameters MUST be registered with IANA. Schulzrinne/Vaha-Sipila [Page 6] Internet Draft RFC2806bis May 12, 2002 6 Examples tel:+358-555-1234567 This URI points to a phone number in Finland capable of receiving voice calls. The hyphens are included to make the number more human- readable; they separate country, area codes and subscriber number. tel:7042;phone-context=cs.columbia.edu The URI describes a local phone number valid within the context "cs.columbia.edu". 7 Rationale 7.1 Why Not Distinguish Between Call Types? TBD. Signaling protocols such as SIP allow to negotiate the call type and parameters, making the very basic indication within the URL scheme moot. 7.2 Why "tel"? "Tel" was chosen since it is widely recognized none of the other suggestions appeared appropriate. "Callto" was discarded since URI schemes locate a resource and do not specify an action to be taken. `Telephone" and "phone" were considered too long and not as internationally recognized. 7.3 Do Not Confuse Numbers with How They Are Dialled As an example, the E.164 number "+123456789" will be dialled in many | countries as 00123456789, where the leading "00" is a prefix for | international calls. (In general, "+" in E.164 indicates that an | international prefix is required.) Tel URIs MUST NOT contain the | local dialing prefixes in numbers such as 00123456789, as the | transformation back to an international number is not guaranteed to | be correct or unique. If a client receives a "tel" URI containing a local number, it MUST make sure that it knows the context in which the local phone number is to be processed, or else the number MUST NOT be used. Equally, the originator of a "tel" URI must take into consideration that the recipient may have insufficient information about the phone number's context. Schulzrinne/Vaha-Sipila [Page 7] Internet Draft RFC2806bis May 12, 2002 When overlap signaling is used, devices which collect dial strings MUST construct a complete phone number before constructing the tel URI and including the URI in a network request. In other words, such devices must convert from overlap dialing to en bloc signaling. 8 Usage of Telephone URIs in HTML The number SHOULD be visible to the end user if it is conceivable that the user might not have a client which is able to use these URIs. Telephone: +358-555-1234567 On a public HTML page, the telephone number in the URI SHOULD always be in the international form, even if the text of the link uses some local format. Telephone: (0555) 1234567 or even For having RFCs read aloud, call 1-555-IETF-RFC. 9 IANA Considerations parameters MUST be registered with IANA. 10 Security Considerations The security considerations parallel those for the mailto URL [10]. A client SHOULD NOT place calls without the consent of its owner. Placing calls automatically without appropriate user confirmation may incur a number of risks, such as those described below. o Calls may incur costs. o The URI may be used to place malicious or annoying calls. Schulzrinne/Vaha-Sipila [Page 8] Internet Draft RFC2806bis May 12, 2002 o A call will take the user's phone line off-hook, thus preventing its use. o A call may reveal the user's, possibly unlisted, phone number to the remote host in the caller identification data, and may allow the attacker to correlate the client's phone number with other information such as the e-mail or IP address. o A call may use the same local number in different contexts, in which the number may have a different meaning. The client SHOULD NOT rapidly redial busy numbers to avoid the congestion of the (signaling) network. The client SHOULD detect if the number is unavailable or if the call is terminated before the dialing string has been completely processed (for example, the call is terminated while waiting for user input) and not try to call again, unless instructed by the user. 11 Changes Since RFC 2806 The specification is backwards-compatible with RFC 2806. o Editorial changes and clarifications. The document has been shortened and reorganized. Most paragraphs have been rewritten to be more concise. o Syntax now conforms to RFC 2396, in particular related to escaping. 12 Changes Since -02 o Clarifications and editorial fixes. o Now, mandatory parameters are labeled, to avoid making [11] obsolete. 13 Changes Since -01 The draft has been greatly simplified to reflect parts that have actually been implemented. o Removed references to carrier selection. o Removed dial context. o Removed fax and modem URIs. o Removed post-dial strings. Schulzrinne/Vaha-Sipila [Page 9] Internet Draft RFC2806bis May 12, 2002 o Removed pause characters. 14 Acknowledgements This document inherits a large amount of text from RFC 2806 [12]. Francois Audet, Lawrence Conroy, Jon Peterson and Mike Pierce provided extensive comments. 15 Authors' Addresses Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu Antti Vaha-Sipila (ISO 8859-15 quoted-printable: Antti V=E4h=E4-Sipil=E4) Nokia Mobile Phones P. O. Box 321 FIN-00045 Nokia Group Finland electronic mail: avs@iki.fi, antti.vaha-sipila@nokia.com 16 Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [2] C. Allocchio, "Minimal PSTN address format in internet mail," RFC 2303, Internet Engineering Task Force, Mar. 1998. [3] C. Allocchio, "Minimal FAX address format in internet mail," RFC 2304, Internet Engineering Task Force, Mar. 1998. [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," RFC 2543, Internet Engineering Task Force, Mar. 1999. [5] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 1997. [6] International Telecommunication Union, "Notation for national and international phone numbers," Recommendation E.123, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1998. Schulzrinne/Vaha-Sipila [Page 10] Internet Draft RFC2806bis May 12, 2002 [7] International Telecommunication Union, "Arrangement of digits, letters and symbols on telephones and other devices that can be used for gaining access to a telephone network," Recommendation E.161, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1995. [8] ANSI, "Allocation of letters to the keys of numeric keypads for telecommunications," Standard T1.703-1995 (R1999), ANSI, 1999. [9] International Telecommunication Union, "The international public telecommunication numbering plan," Recommendation E.164, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1997. [10] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL scheme," RFC 2368, Internet Engineering Task Force, July 1998. [11] J. Yu, "Using SIP to support NP and freephone service," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [12] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet Engineering Task Force, Apr. 2000. Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Schulzrinne/Vaha-Sipila [Page 11] Internet Draft RFC2806bis May 12, 2002 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Schulzrinne/Vaha-Sipila [Page 12] Table of Contents 1 Terminology ......................................... 2 2 Introduction ........................................ 2 3 URI Comparisons ..................................... 3 4 URI Syntax .......................................... 4 5 Phone Numbers and Their Scope ....................... 4 5.1 Phone Numbers ....................................... 4 5.1.1 Separators in Phone Numbers ......................... 5 5.1.2 Alphabetic Characters ............................... 5 5.1.3 Global and Local Numbers ............................ 5 5.2 ISDN Subaddresses ................................... 6 5.3 Other Parameters .................................... 6 6 Examples ............................................ 7 7 Rationale ........................................... 7 7.1 Why Not Distinguish Between Call Types? ............ 7 7.2 Why "tel"? ......................................... 7 7.3 Do Not Confuse Numbers with How They Are Dialled .... 7 8 Usage of Telephone URIs in HTML ..................... 8 9 IANA Considerations ................................. 8 10 Security Considerations ............................. 8 11 Changes Since RFC 2806 .............................. 9 12 Changes Since -02 ................................... 9 13 Changes Since -01 ................................... 9 14 Acknowledgements .................................... 10 15 Authors' Addresses .................................. 10 16 Bibliography ........................................ 10 Schulzrinne/Vaha-Sipila