Network Working Group H. Schulzrinne
Request for Comments: 3966 Columbia University
Obsoletes: 2806 December 2004
Category: Standards Track
Network Working Group H. Schulzrinne
Request for Comments: 3966 Columbia University
Obsoletes: 2806 December 2004
Category: Standards Track
The tel URI for Telephone Numbers
电话号码的电话URI
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806.
本文档指定了URI（统一资源标识符）方案“tel”。“tel”URI描述由电话号码标识的资源。本文件淘汰了RFC 2806。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 6
5.1. Phone Numbers. . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Separators in Phone Numbers . . . . . . . . . . 7
5.1.2. Alphabetic Characters Corresponding to Digits . 7
5.1.3. Alphabetic, *, and # Characters as Identifiers. 7
5.1.4. Global Numbers. . . . . . . . . . . . . . . . . 7
5.1.5. Local Numbers . . . . . . . . . . . . . . . . . 8
5.2. ISDN Subaddresses. . . . . . . . . . . . . . . . . . . 9
5.3. Phone Extensions . . . . . . . . . . . . . . . . . . . 10
5.4. Other Parameters . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Why Not Just Put Telephone Numbers in SIP URIs?. . . . 11
7.2. Why Not Distinguish between Call Types?. . . . . . . . 11
7.3. Why tel. . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Do Not Confuse Numbers with How They Are Dialed. . . . 11
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 6
5.1. Phone Numbers. . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Separators in Phone Numbers . . . . . . . . . . 7
5.1.2. Alphabetic Characters Corresponding to Digits . 7
5.1.3. Alphabetic, *, and # Characters as Identifiers. 7
5.1.4. Global Numbers. . . . . . . . . . . . . . . . . 7
5.1.5. Local Numbers . . . . . . . . . . . . . . . . . 8
5.2. ISDN Subaddresses. . . . . . . . . . . . . . . . . . . 9
5.3. Phone Extensions . . . . . . . . . . . . . . . . . . . 10
5.4. Other Parameters . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Why Not Just Put Telephone Numbers in SIP URIs?. . . . 11
7.2. Why Not Distinguish between Call Types?. . . . . . . . 11
7.3. Why tel. . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Do Not Confuse Numbers with How They Are Dialed. . . . 11
8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 11
9. Use of "tel" URIs with SIP (Informative). . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 14
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 11
9. Use of "tel" URIs with SIP (Informative). . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 14
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
This document defines the URI scheme "tel", which describes resources identified by telephone numbers. A telephone number is a string of decimal digits that uniquely indicates the network termination point. The number contains the information necessary to route the call to this point. (This definition is derived from [E.164] but encompasses both public and private numbers.)
本文档定义了URI方案“tel”，它描述了由电话号码标识的资源。电话号码是一组十进制数字，它唯一地指示网络终止点。该号码包含将呼叫转接到此点所需的信息。（该定义来源于[E.164]，但包括公共和私人号码。）
The termination point of the "tel" URI telephone number is not restricted. It can be in the public telephone network, a private telephone network, or the Internet. It can be fixed or wireless and address a fixed wired, mobile, or nomadic terminal. The terminal addressed can support any electronic communication service (ECS), including voice, data, and fax. The URI can refer to resources identified by a telephone number, including but not limited to originators or targets of a telephone call.
“电话”URI电话号码的终止点不受限制。它可以在公用电话网、专用电话网或Internet中。它可以是固定的，也可以是无线的，并且可以寻址固定的有线、移动或游牧终端。所述终端可支持任何电子通信服务（ECS），包括语音、数据和传真。URI可以引用由电话号码标识的资源，包括但不限于电话呼叫的发起人或目标。
The "tel" URI is a globally unique identifier ("name") only; it does not describe the steps necessary to reach a particular number and does not imply dialling semantics. Furthermore, it does not refer to a specific physical device, only to a telephone number.
“tel”URI仅为全局唯一标识符（“名称”）；它没有描述达到特定号码所需的步骤，也没有暗示拨号语义。此外，它不涉及特定的物理设备，只涉及电话号码。
As commonly understood, telephone numbers comprise two related but distinct concepts: a canonical address-of-record and a dial string. We define the concepts below:
众所周知，电话号码包含两个相关但不同的概念：规范的记录地址和拨号字符串。我们定义了以下概念：
Address-of-record or identifier: The telephone number is understood here as the canonical address-of-record or identifier for a termination point within a specific network. For the public network, these numbers follow the rules in E.164 [E.164], while private numbers follow the rules of the owner of the private numbering plan. Subscribers publish these identifiers so that they can be reached, regardless of the location of the caller. (Naturally, not all numbers are reachable from everywhere, for a
记录地址或标识符：电话号码在这里被理解为特定网络内某个终端点的规范记录地址或标识符。对于公用网络，这些号码遵循E.164[E.164]中的规则，而专用号码遵循专用编号计划所有者的规则。订阅者发布这些标识符以便可以访问它们，而不管调用方的位置如何。（当然，并非所有数字都可以从任何地方获得，例如：
variety of technical and local policy reasons. Also, a single termination point may be reachable from different networks and may have multiple identifiers.)
各种技术和当地政策原因。此外，单个端点可以从不同的网络到达，并且可以具有多个标识符。）
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 an address-of-record or identifier (in the sense described above) so that a call can be routed. Dial strings may require prepended digits to exit the private branch exchange (PBX) the end system is connected to, and they may include post-dial dual-tone multi-frequency (DTMF) signaling that could control an interactive voice response (IVR) system or reach an extension. Dial strings are beyond the scope of this document.
拨号字符串：“拨号字符串”是用户在拨打电话时输入的实际号码、符号和暂停时间。拨号字符串由一个或多个网络实体使用，并在这些实体的配置上下文中理解。它用于生成记录地址或标识符（在上述意义上），以便可以路由呼叫。拨号串可能需要前置数字才能退出终端系统所连接的专用交换机（PBX），并且它们可能包括拨号后双音多频（DTMF）信令，该信令可以控制交互式语音应答（IVR）系统或到达分机。拨号字符串超出了本文档的范围。
Both approaches can be expressed as a URI. For dial strings, this URI is passed to an entity that can reproduce the actions specified in the dial string. For example, in an analog phone system, a dialer translates the dial string into a sequence of actions such as waiting for dial tone, sending DTMF digits, pausing, and generating post-dial DTMF digits after the callee picks up. In an integrated services digital network (ISDN) or ISDN user part (ISUP) environment, the signaling elements that receive protocol messages containing the dial string perform the appropriate protocol actions. As noted, this approach is beyond the scope of this specification.
这两种方法都可以表示为URI。对于拨号字符串，此URI被传递给可以重现拨号字符串中指定的操作的实体。例如，在模拟电话系统中，拨号器将拨号字符串转换为一系列操作，例如等待拨号音、发送DTMF数字、暂停以及在被叫方接听后生成拨号后DTMF数字。在综合业务数字网（ISDN）或ISDN用户部分（ISUP）环境中，接收包含拨号字符串的协议消息的信令元件执行适当的协议操作。如前所述，该方法超出了本规范的范围。
The approach described here has the URI specify the telephone number as an identifier, which can be either globally unique or only valid within a local context. The dialling application is aware of the local context, knowing, for example, whether special digits need to be dialed to seize an outside line; whether network, pulse, or tone dialling is needed; and what tones indicate call progress. The dialling application then converts the telephone number into a dial sequence and performs the necessary signaling actions. 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.
这里描述的方法使用URI将电话号码指定为标识符，该标识符可以是全局唯一的，也可以仅在本地上下文中有效。拨号应用程序知道本地上下文，例如知道是否需要拨打特殊数字以占用外线；是否需要网络、脉冲或音频拨号；以及提示通话进度的音调。然后，拨号应用程序将电话号码转换为拨号序列，并执行必要的信令操作。拨号器不必是传统桌面操作系统中的用户应用程序，但很可能是IP到PSTN网关的一部分。
To reach a telephone number from a phone on a PBX, for example, the user of that phone has to know how to convert the telephone number identifier into a dial string appropriate for that phone. The telephone number itself does not convey what needs to be done for a particular terminal. Instructions may include dialling "9" before placing a call or prepending "00" to reach a number in a foreign country. The phone may also need to strip area and country codes.
例如，要从PBX上的电话获取电话号码，该电话的用户必须知道如何将电话号码标识符转换为适合该电话的拨号字符串。电话号码本身并不表示需要为特定终端做什么。说明可能包括在拨打电话前先拨“9”，或在国外先拨“00”以拨打某个号码。手机可能还需要去除区号和国家代码。
The identifier approach described in this document has the disadvantage that certain services, such as electronic banking or voicemail, cannot be specified in a "tel" URI.
本文档中描述的标识符方法的缺点是某些服务（如电子银行或语音邮件）不能在“tel”URI中指定。
The notation for phone numbers in this document is similar to that in RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax differs as this document describes URIs whereas RFC 3191 and RFC 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/" to indicate parameters (qualifiers). Since URIs use the forward slash to describe path hierarchy, the URI scheme described here uses the semicolon, in keeping with Session Initiation Protocol (SIP) URI conventions [RFC3261].
本文件中的电话号码符号与RFC 3191[RFC3191]和RFC 3192[RFC3192]中的符号类似。但是，语法不同，因为本文档描述URI，而RFC 3191和RFC 3192指定电子邮件地址。RFC 3191和RFC 3192使用“/”表示参数（限定符）。由于URI使用正斜杠来描述路径层次结构，因此本文描述的URI方案使用分号，以符合会话初始化协议（SIP）URI约定[RFC3261]。
The "tel" URI can be used as a request URI in SIP [RFC3261] 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 also use this URI scheme.
“tel”URI可以用作SIP[RFC3261]请求中的请求URI。SIP规范还继承了语法的“订户”部分，作为SIPURI中“用户元素”的一部分。其他协议也可以使用此URI方案。
The "tel" URI does not specify the call type, such as voice, fax, or data call, and does not provide the connection parameters for a data call. The type and parameters are assumed to be negotiated either in-band by the telephone device or through a signaling protocol such as SIP.
“tel”URI不指定呼叫类型，例如语音、传真或数据呼叫，也不提供数据呼叫的连接参数。假定类型和参数由电话设备或通过信令协议（例如SIP）在频带内协商。
This document obsoletes RFC 2806.
本文件淘汰了RFC 2806。
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 BCP 14, RFC 2119, [RFC2119] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119、[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
The URI is defined using the ABNF (augmented Backus-Naur form) described in RFC 2234 [RFC2234] and uses elements from the core definitions (appendix A of RFC 2234).
URI使用RFC 2234[RFC2234]中描述的ABNF（扩展的Backus Naur表单）定义，并使用核心定义中的元素（RFC 2234的附录A）。
The syntax definition follows RFC 2396 [RFC2396], indicating the actual characters contained in the URI. If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. These characters MUST be percent encoded if they appear in tel URI parameter values.
语法定义遵循RFC22396[RFC2396]，表示URI中包含的实际字符。如果保留字符“+”、“；”、“=”和“？”用作“tel”URI的组件之间的分隔符，则它们不得进行百分比编码。如果这些字符出现在tel URI参数值中，则必须对其进行百分比编码。
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent encoding.
除“保留”和“不安全”集合中的字符（参见RFC 2396[RFC2396]）之外的字符等效于其“%HEX-HEX”百分比编码。
The "tel" URI has the following syntax:
“tel”URI具有以下语法：
telephone-uri = "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*uric
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
reserved = ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric = reserved / unreserved / pct-encoded
telephone-uri = "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*uric
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
reserved = ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric = reserved / unreserved / pct-encoded
Each parameter name ("pname"), the ISDN subaddress, the 'extension', and the 'context' MUST NOT appear more than once. The 'isdn-subaddress' or 'extension' MUST appear first, if present, followed by the 'context' parameter, if present, followed by any other parameters in lexicographical order.
每个参数名称（“pname”）、ISDN子地址、“扩展名”和“上下文”不得出现多次。如果子地址在上下文中出现，则必须在“subaddress”或“other order”后加上“present”，如果在上下文中出现，则必须在“subaddress”后加上“other order”。
This simplifies comparison when the "tel" URI is compared character by character, such as in SIP URIs [RFC3261].
当对“tel”URI逐个字符进行比较时，这简化了比较，例如在SIP URI[RFC3261]中。
Two "tel" URIs are equivalent according to the following rules:
根据以下规则，两个“电话”URI是等效的：
o Both must be either a 'local-number' or a 'global-number', i.e., start with a '+'. o The 'global-number-digits' and the 'local-number-digits' must be equal, after removing all visual separators. o For mandatory additional parameters (section 5.4) and the 'phone-context' and 'extension' parameters defined in this document, the 'phone-context' parameter value is compared as a host name if it is a 'domainname' or digit by digit if it is 'global-number-digits'. The latter is compared after removing all 'visual-separator' characters. o Parameters are compared according to 'pname', regardless of the order they appeared in the URI. If one URI has a parameter name not found in the other, the two URIs are not equal. o URI comparisons are case-insensitive.
o 两者都必须是“本地编号”或“全局编号”，即以“+”开头。o移除所有可视分隔符后，“全局数字”和“本地数字”必须相等。o对于本文档中定义的强制性附加参数（第5.4节）以及“电话上下文”和“扩展名”参数，“电话上下文”参数值作为主机名（如果是“域名”）进行比较，或者如果是“全局数字”，则逐位进行比较。删除所有“可视分隔符”字符后，将对后者进行比较。o参数根据“pname”进行比较，而不考虑它们在URI中出现的顺序。如果一个URI的参数名在另一个URI中找不到，则两个URI不相等。o URI比较不区分大小写。
All parameter names and values SHOULD use lower-case characters, as tel URIs may be used within contexts where comparisons are case sensitive.
所有参数名称和值都应该使用小写字符，因为tel URI可以在比较区分大小写的上下文中使用。
Section 19.1.4 in the SIP specification [RFC3261] discusses one such case.
SIP规范[RFC3261]第19.1.4节讨论了一种此类情况。
The 'telephone-subscriber' part of the URI indicates the number. The phone number can be represented in either global (E.164) or local notation. All phone numbers MUST use the global form unless they cannot be represented 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 represented in global (E.164) form and need to be represented as a local number with a context. Local numbers MUST be tagged with a 'phone-context' (section 5.1.5).
URI的“电话订户”部分表示号码。电话号码可以用全局（E.164）或本地符号表示。所有电话号码都必须使用全局形式，除非不能以全局形式表示。来自私人编号计划、紧急（“911”、“112”）和一些目录帮助号码（例如，“411”）以及其他“服务代码”（美国的表格N11号码）的号码不能以全局（e.164）形式表示，需要以带有上下文的本地号码表示。本地号码必须标有“电话上下文”（第5.1.5节）。
Implementations MUST NOT assume that telephone numbers have a maximum, minimum, or fixed length, or that they always begin with or contain certain digits.
实现不能假设电话号码具有最大、最小或固定长度，或者电话号码总是以某些数字开头或包含某些数字。
Phone numbers MAY contain visual separators. Visual separators ('visual-separator') merely aid readability and are not used for URI comparison or placing a call.
电话号码可能包含可视分隔符。可视分隔符（“可视分隔符”）仅帮助可读性，不用于URI比较或调用。
Although it complicates comparisons, this specification retains visual separators in order to follow the spirit of RFC 2396 [RFC2396], which remarks that "A URI often needs to be remembered by people, and it is easier for people to remember a URI when it consists of meaningful components". Also, ISBN URNs documented in RFC 3187 [RFC3187] use visual separators in a manner similar to this specification.
尽管它使比较复杂化，但本规范保留了可视分隔符，以遵循RFC 2396[RFC2396]的精神，该精神指出“URI通常需要被人们记住，当URI由有意义的组件组成时，人们更容易记住URI”。此外，RFC 3187[RFC3187]中记录的ISBN URN以类似于本规范的方式使用可视分隔符。
However, even though ITU-T E.123 [E.123] recommends the use of space characters as visual separators in printed telephone numbers, "tel" URIs MUST NOT use spaces in visual separators to avoid excessive escaping.
然而，尽管ITU-T E.123[E.123]建议在打印电话号码中使用空格字符作为可视分隔符，“电话”URI不得在可视分隔符中使用空格，以避免过度转义。
In some countries, it is common to write phone numbers with alphabetic characters corresponding to certain numbers on the telephone keypad. The URI format does not support this notation, as the mapping from alphabetic characters to digits is not completely uniform internationally, although there are standards [E.161][T1.703] addressing this issue.
在某些国家/地区，通常在电话键盘上用与特定号码对应的字母字符书写电话号码。URI格式不支持这种表示法，因为从字母字符到数字的映射在国际上并不完全统一，尽管有[E.161][T1.703]标准解决了这个问题。
As called and calling terminal numbers (TNs) are encoded in BCD in ISUP, six additional values per digit can be encoded, sometimes represented as the hexadecimal characters A through F. Similarly, DTMF allows for the encoding of the symbols *, #, and A through D. However, in accordance with E.164, these may not be included in global numbers. Their meaning in local numbers is not defined here, but they are not prohibited.
由于被叫和主叫终端号码（TN）在ISUP中用BCD编码，每个数字可以另外编码六个值，有时用十六进制字符A到F表示。同样，DTMF允许对符号*、#和A到D进行编码。但是，根据E.164，这些可能不包括在全局数字中。它们在本地数字中的含义在这里没有定义，但它们并不被禁止。
Globally unique numbers are identified by the leading "+" character. Global numbers MUST be composed with the country (CC) and national (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. Globally unique numbers are unambiguous everywhere in the world and SHOULD be used.
全局唯一数字由前导的“+”字符标识。全球编号必须由E.123[E.123]和E.164[E.164]中规定的国家（CC）和国家（NSN）编号组成。全球唯一数字在世界各地都是明确的，应该使用。
Local numbers are unique only within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX), a state or province, a particular local exchange carrier, or a particular country. 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 dialling software. Digits needed for accessing an outside line, for example, are not included in local numbers. Local numbers SHOULD NOT be used unless there is no way to represent the number as a global number.
本地号码仅在特定地理区域或电话网络的特定部分内是唯一的，例如，专用交换机（PBX）、州或省、特定本地交换机运营商或特定国家/地区。带有本地电话号码的URI只应出现在所有本地实体都可以通过将号码传递给拨号软件成功设置呼叫的环境中。例如，访问外线所需的数字不包括在本地号码中。除非无法将数字表示为全局数字，否则不应使用本地数字。
Local numbers SHOULD NOT be used for several reasons. Local numbers require that the originator and recipient are configured appropriately so that they can insert and recognize the correct context descriptors. Since there is no algorithm to pick the same descriptor independently, labelling numbers with their context increases the chances of misconfiguration so that valid identifiers are rejected by mistake. The algorithm to select descriptors was chosen so that accidental collisions would be rare, but they cannot be ruled out.
出于几个原因，不应使用本地号码。本地号码要求对发端人和收件人进行适当配置，以便他们能够插入和识别正确的上下文描述符。由于没有算法可以独立地选择相同的描述符，因此使用上下文标记数字会增加错误配置的机会，从而错误地拒绝有效标识符。选择描述符的算法是为了避免意外碰撞，但不能排除意外碰撞。
Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. The parameter MUST be chosen to identify the local context within which the number is unique unambiguously. Thus, the combination of the descriptor in the 'phone-context' parameter and local number is again globally unique. The parameter value is defined by the assignee of the local number. It does NOT indicate a prefix that turns the local number into a global (E.164) number.
本地号码必须有一个“电话上下文”参数，用于标识其有效性范围。必须选择该参数以明确标识数字唯一的本地上下文。因此，“phone context”参数中的描述符和本地号码的组合也是全局唯一的。参数值由本地号码的受让人定义。它不表示将本地号码转换为全局（E.164）号码的前缀。
There are two ways to label the context: via a global number or any number of its leading digits (e.g., "+33") and via a domain name, e.g., "houston.example.com". The choice between the two is left to the "owner" of the local number and is governed by whether there is a global number or domain name that is a valid identifier for a particular local number.
有两种方法可以标记上下文：通过一个全局数字或其任何前导数字（例如“+33”）和一个域名，例如“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.
域名不必解析为任何实际主机，但必须由管理本地电话上下文的实体进行管理控制。
A global number context consists of the initial digits of a valid global number. All global numbers with these initial digits must be assigned to the same organization, and no such matching number can be used by any other organization. For example, +49-6151-16 would be a suitable context for the Technical University of Darmstadt, as it uses all numbers starting with those digits. If such an initial
全局编号上下文由有效全局编号的初始数字组成。所有具有这些初始数字的全局编号必须分配给同一组织，任何其他组织都不能使用此类匹配编号。例如，+496151-16将是达姆施塔特技术大学的一个合适的上下文，因为它使用从这些数字开始的所有数字。如果这样的首字母
string of digits does not exist, the organization SHOULD use the lowest number of the global number range assigned to it. (This can occur if two organizations share the same decimal block of numbers. For example, assume an organization owns the number range +1-212- 555-0100 through +1-212-555-0149. +1-212-555-1 would not be a valid global number context, but +1-212-555-0100 would work.) It is not required that local numbers within the context actually begin with the chosen set of initial numbers.
数字字符串不存在，组织应使用分配给它的全局编号范围中的最低编号。（如果两个组织共享相同的十进制数字块，则可能发生这种情况。例如，假设一个组织拥有+1-212-555-0100到+1-212-555-0149的数字范围。+1-212-555-1将不是有效的全局数字上下文，但+1-212-555-0100将起作用。）上下文中的本地数字实际上不需要以所选的初始数字集开始。
A context consisting of the initial digits of a global number does not imply that adding these to the local number will generate a valid E.164 number. It might do so by coincidence, but this cannot be relied upon. (For example, "911" should be labeled with the context "+1", but "+1-911" is not a valid E.164 number.)
由全局编号的初始数字组成的上下文并不意味着将这些数字添加到本地编号将生成有效的E.164编号。它这样做可能是巧合，但这是不可靠的。（例如，“911”应标有上下文“+1”，但“+1-911”不是有效的E.164编号。）
National freephone numbers do not need a context, even though they are not necessarily reachable from outside a particular country code or numbering plan. Recall that "tel" URIs are identifiers; it is sufficient that a global number is unique, but it is not required that it be reachable from everywhere.
国家免费电话号码不需要上下文，即使它们不一定可以从特定国家代码或编号计划之外访问。回想一下，“tel”uri是标识符；一个全局数是唯一的就足够了，但并不要求它可以从任何地方访问。
Even non-freephone numbers may be out of date or may not be reachable from a particular location. For example, premium services such as "900" numbers in the North American numbering plan are often not dialable from outside the particular country code.
即使是非免费电话号码也可能已过时或无法从特定位置获取。例如，北美编号计划中的“900”号码等高级服务通常无法从特定国家代码之外拨打。
The two label types were chosen so that, in almost all cases, a local administrator can pick an identifier that is reasonably descriptive and does not require a new IANA-managed assigned number. It is up to the administrator to assign an appropriate identifier and to use it consistently. Often, an organization can choose among several different identifiers.
选择这两种标签类型是为了，在几乎所有情况下，本地管理员都可以选择一个具有合理描述性且不需要新的IANA管理分配编号的标识符。由管理员分配适当的标识符并一致使用它。通常，一个组织可以在几个不同的标识符中进行选择。
If the recipient of a "tel" URI uses it simply for identification, the receiver does not need to know anything about the context descriptor. It simply treats it as one part of a globally unique identifier, with the other being the local number. If a recipient of the URI intends to place a call to the local number, it MUST understand the context and be able to place calls within that context.
如果“tel”URI的接收者只是将其用于标识，那么接收者不需要知道任何关于上下文描述符的信息。它只是将其视为全局唯一标识符的一部分，另一部分是本地编号。如果URI的接收者打算呼叫本地号码，它必须理解上下文并能够在该上下文中呼叫。
A phone number MAY also contain an 'isdn-subaddress' parameter that indicates an ISDN subaddress.
电话号码还可能包含指示isdn子地址的“isdn子地址”参数。
ISDN subaddresses typically contain International Alphabet 5 (IA5 [T.50]) characters but may contain any octet value.
ISDN子地址通常包含国际字母表5（IA5[T.50]）字符，但可能包含任何八位字节值。
Phone extensions identify stations behind a non-ISDN PBX and are functionally roughly equivalent to ISDN subaddresses. They are identified with the 'extension' parameter. At most, one of the 'isdn-subaddress' and 'extension' parameters can appear in a "tel" URI, i.e., they cannot appear both at the same time.
电话分机识别非ISDN PBX后面的站点，在功能上大致相当于ISDN子地址。它们由“extension”参数标识。最多，“isdn子地址”和“扩展”参数中的一个可以出现在“tel”URI中，即它们不能同时出现。
Future protocol extensions to this URI scheme may add other parameters ('parameter' in the ABNF). Such parameters can be either mandatory or optional. Mandatory parameters start with "m-". An implementation MAY ignore optional parameters and MUST NOT use the URI if it contains unknown mandatory parameters. The "m-" prefix cannot be added to parameters that were already registered (except to create a new, logically distinct parameter). The "phone-context" parameter in this document is mandatory, and "isub" and "ext" are optional.
此URI方案的未来协议扩展可能会添加其他参数（“ABNF中的参数”）。这些参数可以是强制性的，也可以是可选的。强制参数以“m-”开头。实现可以忽略可选参数，如果包含未知的强制参数，则不能使用URI。“m-”前缀不能添加到已注册的参数中（创建新的逻辑上不同的参数除外）。本文档中的“电话上下文”参数是必需的，“isub”和“ext”是可选的。
New mandatory parameters must be described in a standards-track RFC, but an informational RFC is sufficient for optional parameters.
新的强制性参数必须在标准跟踪RFC中描述，但信息性RFC足以用于可选参数。
For example, 'parameter' 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.
例如，“参数”参数可用于存储有关电话号码、其预期用途或已应用于该号码的任何转换的特定于应用程序的附加数据。
Entities that forward protocol requests containing "tel" URIs with optional parameters MUST NOT delete or modify parameters they do not understand.
转发包含可选参数的“tel”URI的协议请求的实体不得删除或修改其不理解的参数。
tel:+1-201-555-0123: This URI points to a phone number in the United States. The hyphens are included to make the number more human readable; they separate country, area code and subscriber number.
电话：+1-201-555-0123：此URI指向美国的一个电话号码。包括连字符以使数字更易于阅读；它们将国家、区号和用户号码分开。
tel:7042;phone-context=example.com: The URI describes a local phone number valid within the context "example.com".
电话:7042 ;；phone context=example.com:URI描述了在上下文“example.com”中有效的本地电话号码。
tel:863-1234;phone-context=+1-914-555: The URI describes a local phone number that is valid within a particular phone prefix.
电话：863-1234；电话上下文=+1-914-555：URI描述了在特定电话前缀内有效的本地电话号码。
The "tel" URI describes a service, reaching a telephone number, that is independent of the means of doing so, be it via a SIP-to-PSTN gateway, a direct SIP call via E.164 number ("ENUM") translation [RFC3761], some other signaling protocols such as H.323, or a traditional circuit-switched call initiated on the client side via, say, the Telephony Application Programming Interface (TAPI). Thus, in spirit, it is closer to the URN schemes that also leave the resolution to an external mechanism. The same "tel" URI may get translated to any number of other URIs in the process of setting up the call.
“tel”URI描述到达电话号码的服务，该服务独立于这样做的方式，可以是经由SIP到PSTN网关、经由E.164号码（“ENUM”）翻译[RFC3761]的直接SIP呼叫、诸如H.323之类的一些其他信令协议，或者在客户端上经由（例如）发起的传统电路交换呼叫，电话应用程序编程接口（TAPI）。因此，在精神上，它更接近于URN计划，该计划也将解决方案留给外部机制。在设置调用的过程中，相同的“tel”URI可能会被转换为任意数量的其他URI。
Signaling protocols such as SIP allow negotiating the call type and parameters, making the very basic indication within the URI scheme moot. Also, since the call type can change frequently, any such indication in a URI is likely to be out of date. If such designation is desired for a device that directly places calls without a signaling protocol such as SIP, mechanisms such as the "type" attribute for the "A" element in HTML may be more appropriate.
SIP等信令协议允许协商呼叫类型和参数，使得URI方案中非常基本的指示没有意义。此外，由于调用类型可能频繁更改，URI中的任何此类指示都可能过时。如果对于在没有诸如SIP之类的信令协议的情况下直接进行呼叫的设备期望这样的指定，则诸如HTML中的“a”元素的“type”属性之类的机制可能更合适。
"tel" was chosen because it is widely recognized that none of the other suggestions appeared appropriate. "Callto" was discarded because URI schemes locate a resource and do not specify an action to be taken. "Telephone" and "phone" were considered too long and not easily recognized internationally.
之所以选择“tel”，是因为人们普遍认为其他建议似乎都不合适。“Callto”已被丢弃，因为URI方案定位资源并且未指定要执行的操作。“电话”和“电话”被认为太长，不容易在国际上得到承认。
As an example, in many countries the E.164 number "+1-212-555-3141" will be dialed as 00-1-212-555-3141, where the leading "00" is a prefix for international calls. (In general, a "+" symbol in E.164 indicates that an international prefix is required.)
例如，在许多国家，E.164号码“+1-212-555-3141”将作为00-1-212-555-3141拨号，其中前导的“00”是国际呼叫的前缀。（通常，E.164中的“+”符号表示需要国际前缀。）
Links using the "tel" URI SHOULD enclose the telephone number so that users can easily predict the action taken when following the link
使用“tel”URI的链接应包含电话号码，以便用户可以轻松预测跟踪链接时所采取的操作
Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for assistance.
拨打<a href=“电话：+1-212-555-0101”>+1-212-555-0101</a>寻求帮助。
instead of
而不是
Dial <a href="tel:+1-212-555-0101">this number</a> for assistance.
拨打此号码寻求帮助。
On a public HTML page, the telephone number in the URI SHOULD always be in the global form, even if the text of the link uses some local format:
在公共HTML页面上，URI中的电话号码应始终为全局形式，即使链接文本使用某些本地格式：
Telephone (if dialling in the United States):
<a href="tel:+1-201-555-0111">(201) 555-0111</a>
Telephone (if dialling in the United States):
<a href="tel:+1-201-555-0111">(201) 555-0111</a>
or even
甚至
For having RFCs read aloud, call <a href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.
要让RFC大声朗读，请致电<a href=“tel:+1-555-438-3732”>1-555-IETF-RFC</a>。
SIP can use the "tel" URI anywhere a URI is allowed, for example as a Request-URI, along with "sip" and "sips" URIs. For brevity, we will imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP URIs can contain telephone numbers. In SIP URIs, they appear as the user part, i.e., before the @ symbol (section 19.1.6 in [RFC3261]).
SIP可以在允许URI的任何位置使用“tel”URI，例如作为请求URI，以及“SIP”和“sips”URI。为简洁起见，在谈论SIP URI时，我们将暗示“sips”URI。“tel”和SIPURI都可以包含电话号码。在SIP URI中，它们显示为用户部分，即@符号之前（参见[RFC3261]第19.1.6节）。
Unless a SIP UA connects directly to a PSTN gateway, one of the SIP proxy servers has to translate the "tel" URI to a SIP URI, with the host part of that URI pointing to a gateway. Typically, the outbound proxy server, as the first proxy server visited by a call request, performs this translation. A proxy server can translate all "tel" URIs to the same SIP host name or select a different gateway for different "tel" prefixes, based, for example, on information learned from TRIP [RFC3219]. However, a proxy server could also delegate this translation task to any other proxy server, as proxy servers are free to apply whatever routing logic they desire. For local numbers, the proxy MUST NOT translate "tel" URIs whose contexts it does not understand.
除非SIP UA直接连接到PSTN网关，否则其中一个SIP代理服务器必须将“tel”URI转换为SIP URI，该URI的主机部分指向网关。通常，出站代理服务器作为呼叫请求访问的第一个代理服务器执行此转换。代理服务器可以将所有“tel”uri转换为相同的SIP主机名，或者基于从TRIP[RFC3219]中获取的信息，为不同的“tel”前缀选择不同的网关。但是，代理服务器也可以将此转换任务委托给任何其他代理服务器，因为代理服务器可以自由应用它们所需的任何路由逻辑。对于本地号码，代理不得翻译其不理解上下文的“tel”URI。
As noted earlier, all phone numbers MUST use the global form unless they cannot be represented as such. If the local-number format is used, it MUST be qualified by the 'phone-context' parameter. Effectively, the combination of local number and phone context makes the "tel" URI globally unique.
如前所述，所有电话号码必须使用全局形式，除非它们不能表示为全局形式。如果使用本地号码格式，则必须通过“phone context”参数限定。实际上，本地号码和电话上下文的组合使“tel”URI全局唯一。
Although web pages, vCard business cards, address books, and directories can easily contain global "tel" URIs, users on twelve-button (IP) phones cannot dial such numbers directly and are typically accustomed to dialling shorter strings, e.g., for PBX extensions or local numbers. These so-called dial strings (section
尽管网页、vCard名片、地址簿和目录可以轻松包含全局“电话”URI，但12按钮（IP）电话上的用户无法直接拨打此类号码，通常习惯于拨打较短的字符串，例如PBX分机或本地号码。这些所谓的拨号串（第
1) are not directly represented by "tel" URIs, as noted. We refer to the rules that govern the translation of dial strings into SIP and "tel" URIs, global or local, as the dial plan. Currently, translations from dial strings to "tel" URIs have to take place in end systems. Future efforts may provide means to carry dial strings in a SIP URI, for example, but no such mechanisms exist as of this writing.
1) 如“uri”所示，不直接代表“uri”。我们将控制拨号字符串转换为SIP和“电话”URI（全局或本地）的规则称为拨号计划。目前，从拨号字符串到“电话”URI的转换必须在终端系统中进行。例如，未来的工作可能会提供在SIP URI中携带拨号字符串的方法，但在撰写本文时还不存在这样的机制。
A SIP UA can use a dial plan to translate dial strings into SIP or "tel" URIs. The dial plan can be manually configured or, preferably, downloaded as part of a device configuration mechanism. (At this time, there is no standardized mechanism for this.)
SIP UA可以使用拨号计划将拨号字符串转换为SIP或“tel”URI。拨号计划可以作为设备配置机制的一部分手动配置，或者优选地下载。（目前还没有标准化的机制。）
A mobile user can use at least two dial plans, namely the dial plan for the network that he is currently visiting and the dial plan for his home network. Generally, dialed numbers meant to represent global numbers will look the same after the translation regardless of the dial plan, even if, say, the visited network uses '0' for dialling an 'outside' number and the user's home network uses '9', as long as the user is aware of the current dial plan. However, local extensions without a direct global equivalent may well behave differently. To avoid any ambiguity, the dial plan MUST insert a suitable 'phone-context' string when performing the translation. If the 'phone-context' is a domain name, there are three cases:
移动用户可以使用至少两个拨号计划，即他当前访问的网络的拨号计划和他家庭网络的拨号计划。通常，无论拨号计划如何，表示全局号码的拨号号码在转换后看起来都是相同的，即使访问的网络使用“0”拨打“外部”号码，而用户的家庭网络使用“9”，只要用户知道当前的拨号计划。然而，没有直接全局等价物的局部扩展很可能表现出不同的行为。为避免任何歧义，拨号计划在执行翻译时必须插入合适的“电话上下文”字符串。如果“电话上下文”是域名，则有三种情况：
1. The outbound proxy recognizes the domain name in the "tel" or SIP URI as its local context and can route the request to a gateway that understands the local number.
1. 出站代理将“tel”或SIP URI中的域名识别为其本地上下文，并可以将请求路由到理解本地号码的网关。
2. The outbound proxy does not use the same phone context but can route to a proxy that handles this phone context. This routing can be done via a lookup table, or the domain name of the phone context might be set up to reflect the SIP domain name of a suitable proxy. For example, a proxy may always route calls with "tel" URIs like
2. 出站代理不使用相同的电话上下文，但可以路由到处理此电话上下文的代理。此路由可以通过查找表完成，或者可以设置电话上下文的域名以反映合适代理的SIP域名。例如，代理可能总是使用“tel”URI路由调用，如
tel:1234;phone-context=munich.example.com
tel:1234;phone-context=munich.example.com
to the SIP proxy located at munich.example.com. (Proxies receiving a tel URI with a context they do not understand are obligated to return a 404 (Not Found) status response so that an outbound proxy may decide to attempt such a heuristic.)
发送到位于munich.example.com的SIP代理。（接收到不理解上下文的tel URI的代理有义务返回404（未找到）状态响应，以便出站代理可以决定尝试这种启发式。）
3. The outbound proxy does not recognize the phone context and cannot find the appropriate proxy for that phone context. In that case, the translation fails, and the outbound proxy returns a 404 (Not Found) error response.
3. 出站代理无法识别电话上下文，无法找到该电话上下文的相应代理。在这种情况下，转换失败，出站代理返回404（未找到）错误响应。
This document is derived from RFC 2806 [RFC2806], written by Antti Vaehae-Sipilae. Mark Allman, Flemming Andreasen, Francois Audet, Lawrence Conroy, Cullen Jennings, Michael Hammer, Paul Kyzivat, Andrew Main, Xavier Marjou, Jon Peterson, Mike Pierce, Jonathan Rosenberg, and James Yu provided extensive comments.
本文件源自Antti Vaehae Sipilae编写的RFC 2806[RFC2806]。马克·奥尔曼、弗莱明·安德雷森、弗朗索瓦·奥德特、劳伦斯·康罗伊、卡伦·詹宁斯、迈克尔·哈默、保罗·基齐瓦特、安德鲁·梅因、泽维尔·马约、乔恩·彼得森、迈克·皮尔斯、乔纳森·罗森博格和詹姆斯·余发表了广泛的评论。
The security considerations parallel those for the mailto URL [RFC2368].
安全注意事项与mailto URL[RFC2368]的安全注意事项类似。
Web clients and similar tools MUST NOT use the "tel" URI to place telephone calls without the explicit consent of the user of that client. Placing calls automatically without appropriate user confirmation may incur a number of risks, such as those described below:
未经客户端用户明确同意，Web客户端和类似工具不得使用“tel”URI拨打电话。在没有适当用户确认的情况下自动拨打电话可能会产生许多风险，如以下所述：
o Calls may incur costs. o The URI may be used to place malicious or annoying calls. 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 user's phone number with other information, such as an e-mail or IP address.
o 电话可能会产生费用。o URI可用于进行恶意或恼人的呼叫。o通话会使用户的电话线脱离连接，从而阻止其使用。o呼叫可能会在呼叫者标识数据中向远程主机显示用户可能未列出的电话号码，并可能允许攻击者将用户的电话号码与其他信息（如电子邮件或IP地址）关联。
This is particularly important for "tel" URIs embedded in HTML links, as a malicious party may hide the true nature of the URI in the link text, as in
这对于嵌入HTML链接中的“tel”URI尤其重要，因为恶意方可能会在链接文本中隐藏URI的真实性质，如中所示
<a href="tel:+1-900-555-0191">Find free information here</a>
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>
<a href="tel:+1-900-555-0191">Find free information here</a>
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>
"tel" URIs may reveal private information, similar to including phone numbers as text. However, the presence of the tel: schema identifier may make it easier for an adversary using a search engine to discover these numbers.
“电话”URI可能会泄露私人信息，类似于将电话号码作为文本。然而，tel:schema标识符的存在可能使使用搜索引擎的对手更容易发现这些号码。
The specification is syntactically backwards-compatible with the "tel" URI defined in RFC 2806 [RFC2806] but has been completely rewritten. This document more clearly distinguishes telephone numbers as identifiers of network termination points from dial strings and removes the latter from the purview of "tel" URIs.
该规范在语法上向后兼容RFC2806[RFC2806]中定义的“tel”URI，但已完全重写。本文档更清楚地将电话号码作为网络终端点的标识符与拨号字符串区分开来，并将后者从“电话”URI的权限中删除。
Compared to RFC 2806, references to carrier selection, dial context, fax and modem URIs, post-dial strings, and pause characters have been removed. The URI syntax now conforms to RFC 2396 [RFC2396].
与RFC 2806相比，已删除对载波选择、拨号上下文、传真和调制解调器URI、拨号后字符串和暂停字符的引用。URI语法现在符合RFC22396[RFC2396]。
A section on using "tel" URIs in SIP was added.
增加了关于在SIP中使用“tel”URI的一节。
[E.123] International Telecommunications Union, "Notation for national and international telephone numbers, e-mail addresses and web addresses", Recommendation E.123, February 2001.
[E.123]国际电信联盟，“国家和国际电话号码、电子邮件地址和网址的符号”，建议E.123，2001年2月。
[E.161] International Telecommunications 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, May 1995.
[E.161]国际电信联盟，“电话和其他可用于接入电话网络的设备上数字、字母和符号的排列”，建议E.161，1995年5月。
[E.164] International Telecommunications Union, "The international public telecommunication numbering plan", Recommendation E.164, May 1997.
[E.164]国际电信联盟，“国际公共电信编号计划”，建议E.164，1997年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[T1.703] ANSI, "Allocation of Letters to the Keys of Numeric Keypads for Telecommunications", Standard T1.703-1995 (R1999), 1999.
[T1.703]ANSI，“电信用数字键盘按键的字母分配”，标准T1.703-1995（R1999），1999年。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368]Hoffman，P.，Masinter，L.，和J.Zawinski，“邮件URL方案”，RFC 2368，1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[RFC2806]Vaha Sipila，A.，“电话呼叫的URL”，RFC 2806，2000年4月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
[RFC3187]Hakala，J.和H.Walravens，“使用国际标准书号作为统一资源名称”，RFC 3187，2001年10月。
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[RFC3191]Allocchio，C.，“互联网邮件中的最小GSTN地址格式”，RFC31912001年10月。
[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[RFC3192]Allocchio，C.，“互联网邮件中的最小传真地址格式”，RFC3192，2001年10月。
[RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[RFC3219]Rosenberg，J.，Salama，H.，和M.Squire，“IP电话路由（TRIP）”，RFC 3219，2002年1月。
[T.50] International Telecommunications Union, "International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange", Recommendation T.50, 1992.
[T.50]国际电信联盟，“国际参考字母表（IRA）（原国际字母表5或IA5）-信息技术-信息交换用7位编码字符集”，建议T.501992年。
Author's Address
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。