Network Working Group G. Parsons
Request for Comments: 3939 J. Maruszak
Category: Standards Track Nortel Networks
December 2004
Network Working Group G. Parsons
Request for Comments: 3939 J. Maruszak
Category: Standards Track Nortel Networks
December 2004
Calling Line Identification for Voice Mail Messages
语音邮件消息的呼叫线路标识
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 describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message.
本文档描述了一种在存储的语音邮件消息头中识别发起主叫方的方法。为此定义了两个新的头字段：Caller\u ID和Called\u Name。调用方id用于存储足够的信息，以便收件人回调或回复邮件的发件人。Caller name提供发送消息的人的姓名。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document. . . . . . . . . . . . . . . 3
3. Calling Line Identification Field. . . . . . . . . . . . . . . 3
3.1. Internal Call. . . . . . . . . . . . . . . . . . . . . . 4
3.2. External Call. . . . . . . . . . . . . . . . . . . . . . 4
3.3. Numbering Plan . . . . . . . . . . . . . . . . . . . . . 4
3.4. Date Header. . . . . . . . . . . . . . . . . . . . . . . 5
4. Caller Name Field. . . . . . . . . . . . . . . . . . . . . . . 5
5. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Calling Line Identification Syntax . . . . . . . . . . . 6
5.2. Caller Name Syntax . . . . . . . . . . . . . . . . . . . 6
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document. . . . . . . . . . . . . . . 3
3. Calling Line Identification Field. . . . . . . . . . . . . . . 3
3.1. Internal Call. . . . . . . . . . . . . . . . . . . . . . 4
3.2. External Call. . . . . . . . . . . . . . . . . . . . . . 4
3.3. Numbering Plan . . . . . . . . . . . . . . . . . . . . . 4
3.4. Date Header. . . . . . . . . . . . . . . . . . . . . . . 5
4. Caller Name Field. . . . . . . . . . . . . . . . . . . . . . . 5
5. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Calling Line Identification Syntax . . . . . . . . . . . 6
5.2. Caller Name Syntax . . . . . . . . . . . . . . . . . . . 6
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11
There is currently a need for a mechanism to identify the originating party of a voice mail message, outside of the "FROM" header information. The telephone number and name of the caller are typically available from the telephone network, but there is no obvious header field to store this in an Internet Mail message.
目前需要一种机制来识别语音邮件消息的发起方，而不是“发件人”标题信息。来电者的电话号码和姓名通常可从电话网络中获得，但没有明显的头字段可将其存储在Internet邮件消息中。
This information is intended for use when the VPIM message format is used for storing "Call Answer" voice messages in an Internet Mail message store, i.e., the calling party leaves a voice message for the recipient, who was unable to answer the call. The implication is that there is no RFC 2822 address known for the originator.
当VPIM消息格式用于在Internet邮件消息存储中存储“呼叫-应答”语音消息时，即主叫方为无法应答呼叫的收件人留下语音消息时，此信息可供使用。这意味着发起者不知道RFC 2822地址。
[VPIMV2R2] suggests the originating number be included as an Internet address, using the first method shown below. There are several other ways to store this information, but they all involve some manipulation of the "From" field. For example:
[VPIMV2R2]建议使用如下所示的第一种方法将原始号码作为互联网地址。存储此信息还有其他几种方法，但它们都涉及对“From”字段的一些操作。例如：
1. From: "416 555 1234" <non-mail-user@host> 2. From: "John Doe" <4165551234@host> 3. From: unknown:;
1. 发件人：“4165551234”<非邮件-user@host> 2. 摘自：“约翰·多伊”<4165551234@host> 3. 发件人：未知：；
Since any of these is a forced translation, it would be useful to store the calling party's name and number as presented by the telephone system to the called party without manipulation. This would allow the calling party's information to be displayed to the recipient (similar to it appearing on the telephone) and also allow future determination of an Internet address for the originator (if one exists). Note that there is no requirement to store meta-data (e.g., type of number, presentation restricted), as this information is not presented to the called party and is generally not available to voice mail systems. The intent is to store the available information to an analog (non-ISDN) phone (e.g., per [T1.401] in North America).
由于其中任何一项都是强制翻译，因此存储电话系统向被叫方提供的主叫方的姓名和电话号码将非常有用，而不需要进行任何操作。这将允许呼叫方的信息显示给接收者（类似于电话上出现的信息），并允许将来确定发端人的互联网地址（如果存在）。请注意，不需要存储元数据（例如，号码类型、表示受限），因为此信息不会呈现给被叫方，并且通常不可用于语音邮件系统。其目的是将可用信息存储到模拟（非ISDN）电话（例如，北美的per[T1.401]）。
[RFC2076] currently lists "phone" as an Internet message header which would hold the originating party's telephone number, but it is listed as "non-standard", i.e., usage of this header is not generally recommended. It also has no defined format, making the information unparsable. There is no similar entry for the originator's name.
[RFC2076]目前将“电话”列为互联网消息头，该消息头将保存发端方的电话号码，但它被列为“非标准”，即，通常不建议使用该头。它也没有定义的格式，使得信息不可解析。发起者的姓名没有类似的条目。
It is proposed that two new message header fields be included to hold this information, namely the Calling Line Identification ("Caller-ID") and Caller Name ("Caller-Name").
建议包括两个新的消息头字段来保存此信息，即主叫线路标识（“主叫ID”）和主叫名称（“主叫名称”）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
The Calling Line Identification header ("Caller-ID") holds sufficient information for the recipient's voice mail system to call back, or reply to, the sender of the message. The number that is contained in this header is supplied by the telephone system. The exact format of the data received depends on the type of call, that is -- internal or external call.
呼叫线路标识头（“呼叫者ID”）为接收者的语音邮件系统保留了足够的信息，以便回拨或回复消息的发送者。此标题中包含的号码由电话系统提供。接收到的数据的确切格式取决于调用的类型，即内部调用或外部调用。
Note that for both options, the number field MUST contain only the digits of the number and MUST be representable using the American Standard Code for Information Interchange [ASCII] character set; it does not include any separating character (e.g., "-").
请注意，对于这两个选项，数字字段必须仅包含数字的数字，并且必须使用美国信息交换标准代码[ASCII]字符集表示；它不包括任何分隔字符（例如“-”）。
It is expected that default, likely to be the most common case, will not have any numbering plan semantic associated with the number. However, in the case that it is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic.
预计默认情况（可能是最常见的情况）将不会有任何与编号关联的编号计划语义。但是，在已知的情况下，可以使用可选的“NumberingPlan”参数来指示语义。
For an internal call (e.g., between two extensions within the same company), it is sufficient to relay only the extension of the calling party, based on the company dialing plan.
对于内部呼叫（例如，同一公司内的两个分机之间），根据公司拨号计划，仅中继主叫方的分机就足够了。
However, the support of longer numbers may be supported by the enterprise phone system.
但是，企业电话系统可能支持更长的号码。
For an international call, the calling party's number must be the full international number as described in [E.164], i.e., Country Code (CC), National Destination Code (NDC), and Subscriber Number (SN). Other information, such as prefixes or symbols (e.g., "+"), MUST NOT be included. [E.164] allows for numbers of up to 15 digits.
对于国际呼叫，呼叫方的号码必须是[E.164]中所述的完整国际号码，即国家代码（CC）、国家目的地代码（NDC）和用户号码（SN）。其他信息，如前缀或符号（例如“+”），不得包括在内。[E.164]允许最多15位数字。
For a call within North America, it is also suggested that 15 digits per [T1.625] be supported. However, some service providers may only support 10 digits as described in [T1.401] and [GR-31-CORE]. Though it is desirable that an international number not be truncated to 10 digits if it contains more, it is recognized that limitations of various systems will cause this to happen.
对于北美范围内的呼叫，还建议支持每[T1.625]15位数字。但是，一些服务提供商可能只支持[T1.401]和[GR-31-CORE]中所述的10位数字。虽然一个国际数字如果包含更多的数字，最好不要被截断为10位，但人们认识到，各种系统的限制会导致这种情况的发生。
Implementors of this specification should be aware that some phone systems are known to truncate international numbers, even though this behavior is undesirable.
本规范的实施者应该知道，一些电话系统已知会截断国际号码，即使这种行为是不可取的。
Note that the other defined fields available to non-analog systems (e.g., subaddress, redirecting number), as well as the meta-data, are not intended to be stored in this header.
请注意，非模拟系统可用的其他定义字段（例如，子地址、重定向编号）以及元数据不打算存储在此标头中。
In this baseline case (i.e., analog lines), no numbering plan information is known or implied. However, in the case that a numbering plan is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic. Only three semantics are defined: "unknown", "local", and "e164". "unknown" is the default if no numbering plan semantic is known (and the default if the parameter is absent). "local" has meaning only within the domain of the voice mail system that stored the message (i.e., the voice mail system knows that the number belongs to a local numbering plan). "e164" indicates that the number is as described in [E.164]. "x-" may be used to indicate enterprise or service specific dialing plans.
在这种基线情况下（即模拟线），没有已知或隐含的编号计划信息。但是，在已知编号计划的情况下，可以使用可选的“NumberingPlan”参数来指示语义。仅定义了三种语义：“未知”、“本地”和“e164”。如果不知道编号计划语义，“未知”是默认值（如果参数不存在，则为默认值）。“本地”仅在存储消息的语音邮件系统域内具有含义（即，语音邮件系统知道该号码属于本地编号计划）。“e164”表示编号如[E.164]所述。“x-”可用于表示特定于企业或服务的拨号计划。
The date and time may be included by the telephone system with the calling party's telephone number per [T1.401]. This MAY be used, as there is an existing "Date" Internet header to hold this information. It is a local implementation decision whether this time or the local system time will be recorded in the "Date" header.
电话系统可根据[T1.401]将日期和时间包括在主叫方的电话号码中。这可能会被使用，因为有一个现有的“日期”互联网头来保存此信息。本地实施决定是将此时间还是本地系统时间记录在“日期”标题中。
The name of the person sending the message is also important. Information about whether the call is internal or external may be included if it is available. This information may not be available on international calls.
发送信息的人的姓名也很重要。如果有关于呼叫是内部还是外部的信息，则可以包括在内。国际电话可能无法提供此信息。
Further, the exact format for this field is typically a service provider option per [T1.641]. It is possible for the caller's name to be sent in one of several character sets depending on the service provider signaling transport (e.g., ISDN-UP, SCCP, TCAP). These include:
此外，根据[T1.641]，此字段的确切格式通常是服务提供商选项。根据服务提供商信令传输（例如，ISDN-UP、SCCP、TCAP），呼叫方的名称可能以几个字符集之一发送。这些措施包括：
1) International Reference Alphabet (IRA), formerly know as
International Alphabet No.5 or IA5 [T.50]
2) Latin Alphabet No. 1 [8859-1]
3) American National Standard Code for Information Interchange
[ASCII]
4) Character Sets for the International Teletex Service [T.61]
1) International Reference Alphabet (IRA), formerly know as
International Alphabet No.5 or IA5 [T.50]
2) Latin Alphabet No. 1 [8859-1]
3) American National Standard Code for Information Interchange
[ASCII]
4) Character Sets for the International Teletex Service [T.61]
Of these, the IRA and T.61 character sets contain a number of options that help specify national and application oriented versions. If there is no agreement between parties to use these options, then the 7-bit character set in which the graphical characters of IRA, T.61, and ASCII are coded exactly the same, will be assumed. Further, the 7-bit graphical characters of [8859-1] are the same as in [ASCII].
其中，IRA和T.61字符集包含许多选项，有助于指定国家和面向应用程序的版本。如果双方未就使用这些选项达成协议，则将假定IRA、T.61和ASCII图形字符编码完全相同的7位字符集。此外，[8859-1]的7位图形字符与[ASCII]中的相同。
Note that for delivery to customer equipment in North America, the calling name MUST be presented in ASCII per [T1.401].
请注意，对于在北美交付给客户的设备，呼叫名称必须按照[T1.401]以ASCII表示。
As a result, for the caller name header defined in this document, characters are represented with ASCII characters. However, if a name is received that cannot be represented in 7-bit ASCII, it MAY be stored using its native character set as defined in [RFC2047].
因此，对于本文档中定义的呼叫者名称标头，字符用ASCII字符表示。但是，如果接收到的名称不能用7位ASCII表示，则可以使用[RFC2047]中定义的本机字符集存储该名称。
In telephone networks, the length of the name field MUST NOT exceed 50 characters, as defined in [T1.641]. However, service providers may choose to further limit this to 15 characters for delivery to customer equipment, e.g., [T1.401] and [GR-1188-CORE].
在电话网络中，名称字段的长度不得超过[T1.641]中定义的50个字符。但是，服务提供商可能会选择进一步将其限制为15个字符，以便交付给客户设备，例如[T1.401]和[GR-1188-CORE]。
Both Calling Line Identification and Caller Name follow the syntax specification using the augmented Backus-Naur Form (BNF) as described in [RFC2234]. While the semantics of these headers are defined in sections 4 and 5, the syntax uses the 'unstructured' token defined in [RFC2822]:
呼叫线路标识和呼叫者名称都遵循使用[RFC2234]中所述的增广巴科斯诺尔形式（BNF）的语法规范。虽然这些头的语义在第4节和第5节中有定义，但语法使用了[RFC2822]中定义的“非结构化”标记：
unstructured = *([FWS] utext) [FWS]
unstructured = *([FWS] utext) [FWS]
"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan="
( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF
"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan="
( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
"Caller-Name" ":" unstructured CRLF
调用方名称“”：“非结构化CRLF”
To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne
To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne
To: 6137637582@example.com Caller-ID: 6139416900 Caller-Name: Jean Chretien
致：6137637582@example.com来电显示：6139416900来电者姓名：Jean Chretien
The intent of these headers are to record telephone number that is sent by the analog phone system with an incoming call without alteration or interpretation. If sufficient semantic is known or can be inferred, this may be included in the NumberingPlan field. This may allow it to be later translated into an addressable phone number. Addressable or dialable phone numbers (which this document does not define) are defined in other documents, such as GSTN address [RFC3191] or telephone URL [RFC2806].
这些标题的目的是记录模拟电话系统在传入呼叫时发送的电话号码，而无需更改或解释。如果已知或可以推断出足够的语义，则可以将其包括在NumberingPlan字段中。这可能会使它以后被翻译成一个可寻址的电话号码。可寻址或可拨打电话号码（本文档未定义）在其他文档中定义，如GSTN地址[RFC3191]或电话URL[RFC2806]。
There are a few scenarios of how this mechanism may fail that must be considered. The first is mentioned in section 3.2 - the truncation of an international number to 10 digits. This could result in a misinterpretation of the resulting number. For instance, an international number (e.g., from Ireland) of the form "353 91 73 3307" could be truncated to "53 91 73 3307" if received in North America, and interpreted as "539 917 3307" - a seemingly "North American" style number. Thus, the recipient is left with incorrect information to reply to the message, possibly with an annoyed callee at the North American number.
必须考虑以下几种情况，即该机制可能会失败。第一个在第3.2节-将国际数字截断为10位中提到。这可能导致对结果数字的误解。例如，如果在北美收到形式为“353 91 73 3307”的国际号码（例如来自爱尔兰），则可以将其截断为“53 91 73 3307”，并解释为“539 917 3307”——一个看似“北美”风格的号码。因此，收件人留下了不正确的信息来回复邮件，可能是北美号码上的一个恼怒的被叫人。
The second scenario is the possibility of sending an internal extension to an external recipient when a Call Answer message is forwarded. This poses two problems, the recipient is given the wrong phone number, and the company's dialing plan could be exposed.
第二种情况是，在转发呼叫应答消息时，可能会向外部收件人发送内部分机。这带来了两个问题，收件人的电话号码错误，公司的拨号计划可能会被曝光。
The final concern deals with exercising character options that are available in coding the Calling Name field. An international system may send a message with coding options that are not available on the receiving system, thus giving the recipient an incorrect Caller Name.
最后一个问题是如何使用在编码调用名称字段中可用的字符选项。国际系统可能会发送带有接收系统上不可用的编码选项的消息，从而给收件人一个错误的呼叫者名称。
Note that unlisted and restricted numbers are not a concern as these header fields are defined to contain what the called party would see (e.g., 'Private Name'), as opposed to the complete details exchanged between service providers.
请注意，未列出的和受限的号码不受关注，因为这些标题字段定义为包含被叫方将看到的内容（例如，“私有名称”），而不是服务提供商之间交换的完整详细信息。
However, it must also be noted that this mechanism allows the explicit indication of phone numbers in the headers of an email message (used to store voice messages). While the rationale for this is reviewed in section 1, the recipient of this message may not be aware that this information is contained in the headers unless the user's client presents the information. Its use is intended to be informative as it is when it appears on a telephone screen.
但是，还必须注意，此机制允许在电子邮件的标题中明确指示电话号码（用于存储语音消息）。虽然第1节对其原理进行了审查，但除非用户的客户机提供信息，否则此消息的收件人可能不知道此信息包含在标题中。当它出现在电话屏幕上时，其用途旨在提供信息。
This document defines an IANA-administered registration space for Caller-ID numbering plans in section 5.1. Each registry entry consists of an identifying token and a short textual description of the entry. There are three initial entries in this registry:
本文件在第5.1节中为呼叫者ID编号计划定义了IANA管理的注册空间。每个注册表项由一个标识标记和该项的简短文本描述组成。此注册表中有三个初始条目：
unknown - The number's semantics are unknown. This value is the default in the absence of this parameter.
未知-数字的语义未知。在没有此参数的情况下，此值是默认值。
local - The number only has meaning within the domain of the sending system identified by the RFC 2822 From field of the message.
本地-该数字仅在消息的RFC 2822 From字段标识的发送系统域内具有意义。
e164 - The number's semantics are described in [E.164].
e164-数字的语义如[E.164]所述。
The only way to add additional entries (ietf-token in section 5.1) to this registry is with a standards-track RFC.
向该注册表添加其他条目（第5.1节中的ietf令牌）的唯一方法是使用标准跟踪RFC。
[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2R2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 38012004年6月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[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月。
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[RFC2076]Palme，J.，“通用互联网消息头”，RFC2076，1997年2月。
[E.164] ITU-T Recommendation E.164 (1997), "The international public telecommunication numbering plan"
[E.164]ITU-T建议E.164（1997），“国际公共电信编号计划”
[T.50] ITU-T Recommendation T.50 (1992), "International Reference Alphabet (IRA)"
[T.50]ITU-T建议T.50（1992），“国际参考字母表（IRA）”
[T.61] CCITT Recommendation T.61 (1988) (Withdrawn), "Character Repertoire and Coded Character Sets for the International Teletex Service"
[T.61]CCITT建议T.61（1988）（撤回），“国际电传业务用字符表和编码字符集”
[8859-1] ISO/IEC International Standard 8859-1 (1998), Information Technology _ 8-bit single-byte coded graphic character sets _ Part 1: Latin Alphabet No. 1
[8859-1]ISO/IEC国际标准8859-1（1998），信息技术-8位单字节编码图形字符集-第1部分：第1号拉丁字母
[ASCII] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986.
[ASCII]美国国家标准协会（ANSI），编码字符集-信息交换用7位美国国家标准代码，ANSI X3.41986。
[T1.401] American National Standards Institute (ANSI), Telecommunications _ Network-to-Customer Installation Interfaces _ Analog Voicegrade Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features, ANSI T1.6401.03-1998
[T1.401]美国国家标准协会（ANSI），电信uuu网络到客户安装接口uuu模拟语音等级交换接入线路，具有主叫号码传送、主叫名称传送或可视消息等待指示器功能，ANSI T1.6401.03-1998
[T1.625] American National Standards Institute (ANSI), Telecommunications - Integrated Services Digital Network (ISDN) _ Calling Line identification Presentation and Restriction Supplementary Services, ANSI T1.625-1993
[T1.625]美国国家标准协会（ANSI），电信-综合业务数字网（ISDN）\呼叫线路识别表示和限制补充业务，ANSI T1.625-1993
[T1.641] American National Standards Institute (ANSI), Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995
[T1.641]美国国家标准协会（ANSI），电信-呼叫名称识别演示，ANSI T1.641-1995
[GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000
[GR-1188-CORE]Telcordia Technologies，“类别特征：呼叫名称交付通用要求”，GR-1188-CORE，第2期，2000年12月
[GR-31-CORE] Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000
[GR-31-CORE]Telcordia Technologies，“类别特征：呼叫号码传送”，GR-31-CORE，第1期，2000年6月
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[RFC3191]Allocchio，C.，“互联网邮件中的最小GSTN地址格式”，RFC31912001年10月。
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[RFC2806]Vaha Sipila，A.，“电话呼叫的URL”，RFC 2806，2000年4月。
The previous authors of versions of this document were Derrick Dunne and Jason Collins. The current authors would like to thank Derrick and Jason for their contributions.
本文件之前版本的作者是Derrick Dunne和Jason Collins。当前作者要感谢Derrick和Jason的贡献。
Authors' Addresses
作者地址
Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7
Glenn Parsons Nortel Networks邮政信箱3511，渥太华C站，K1Y 4H7
Phone: +1-613-763-7582
EMail: gparsons@nortelnetworks.com
Phone: +1-613-763-7582
EMail: gparsons@nortelnetworks.com
Janusz Maruszak
贾努斯·马鲁扎克
Phone: +1-416-885-0221
EMail: jjmaruszak@sympatico.ca
Phone: +1-416-885-0221
EMail: jjmaruszak@sympatico.ca
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编辑功能的资金目前由互联网协会提供。