Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 8197 FCC
Category: Standards Track July 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 8197 FCC
Category: Standards Track July 2017
ISSN: 2070-1721
A SIP Response Code for Unwanted Calls
不需要的呼叫的SIP响应代码
Abstract
摘要
This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.
本文档定义了607（不需要的）SIP响应代码，允许被叫方指出呼叫或消息是不需要的。SIP实体可以使用该信息来调整如何为被叫方或更广泛地处理来自该主叫方的未来呼叫。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8197.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8197.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5
5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5
5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
In many countries, an increasing number of calls are unwanted [RFC5039]: they might be fraudulent or illegal telemarketing or maybe the receiving party does not want to be disturbed by, say, surveys or solicitation by charities. Carriers and other service providers may want to help their subscribers avoid receiving such calls, using a variety of global or user-specific filtering algorithms. One input into such algorithms is user feedback. User feedback may be offered through smartphone apps, APIs or within the context of a SIP-initiated call. This document addresses feedback within the SIP call. Here, the called party either rejects the SIP [RFC3261] request as unwanted or terminates the session with a BYE request after answering the call. INVITE and MESSAGE requests are most likely to trigger such a response.
在许多国家，越来越多的电话是不需要的[RFC5039]：它们可能是欺诈性的或非法的电话营销，或者可能是接收方不希望受到（比如）调查或慈善机构的拉拢的干扰。运营商和其他服务提供商可能希望使用各种全局或特定于用户的过滤算法来帮助其用户避免接收此类呼叫。这种算法的一个输入是用户反馈。用户反馈可以通过智能手机应用程序、API或SIP发起呼叫的上下文提供。本文档介绍SIP呼叫中的反馈。这里，被叫方或者拒绝SIP[RFC3261]请求作为不需要的请求，或者在应答呼叫之后用BYE请求终止会话。INVITE和MESSAGE请求最有可能触发这样的响应。
To allow the called party to express that the call was unwanted, this document defines the 607 (Unwanted) response code. The user agent (UA) of the called party, based on input from the called party or some UA-internal logic, uses this to indicate that this call is unwanted and that future attempts are likely to be similarly rejected. While factors such as identity spoofing and call forwarding may make authoritative identification of the calling party difficult or impossible, the network can use such a rejection -- possibly combined with a pattern of rejections by other callees and/ or other information -- as input to a heuristic algorithm for determining future call treatment. The heuristic processing and possible treatment of persistently unwanted calls are outside the scope of this document.
为了允许被叫方表示该呼叫是不需要的，本文档定义了607（不需要的）响应代码。被叫方的用户代理（UA）基于被叫方的输入或某个UA内部逻辑，使用它来指示该呼叫是不需要的，并且未来的尝试很可能被类似地拒绝。虽然身份欺骗和呼叫转移等因素可能使主叫方难以或不可能进行权威性识别，网络可以使用这种拒绝——可能与其他被叫方的拒绝模式和/或其他信息相结合——作为确定未来呼叫处理的启发式算法的输入。对持续不需要的呼叫的启发式处理和可能的处理超出了本文档的范围。
When this document refers to "caller identity", it uses "identity" in the same sense as [SIP-IDENTITY], i.e., to mean either a canonical address-of-record (AOR) SIP URI employed to reach a user (such as 'sip:alice@atlanta.example.com'), or a telephone number, which commonly appears in either a tel URI [RFC3966] or as the user portion of a SIP URI.
当本文档提及“呼叫方标识”时，它使用与[SIP-identity]相同意义上的“标识”，即表示用于到达用户的规范记录地址（AOR）SIP URI（如“SIP:alice@atlanta.example.com“），或电话号码，通常出现在电话URI[RFC3966]中或作为SIP URI的用户部分。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
None of the existing 4xx, 5xx, or 6xx response codes signify that this SIP request is unwanted by the called party. For example, 603 (Decline) might be used if the called party is currently at dinner or in a meeting, but does not want to indicate any specific reason. As described in Section 21.6.2 [RFC3261], a 603 response may include a Retry-After header field to indicate a better time to attempt the call. Thus, the call is rejected due to the called party's (temporary) status. As described in Section 4, the called party invokes the "unwanted call" user interface and 607 (Unwanted) response indicating that it is instead the caller's identity that is causing the call to be rejected.
现有的4xx、5xx或6xx响应码均不表示被叫方不需要此SIP请求。例如，如果被叫方当前正在吃饭或开会，但不想指明任何具体原因，则可以使用603（拒绝）。如第21.6.2节[RFC3261]所述，603响应可能包括重试后报头字段，以指示尝试呼叫的更好时间。因此，由于被叫方的（临时）状态，呼叫被拒绝。如第4节所述，被叫方调用“不想要的呼叫”用户界面和607（不想要的）响应，指示导致呼叫被拒绝的是呼叫方的身份。
The response code 607 MAY be used in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP request to indicate that the offered communication is unwanted. The response code MAY also be used as the value of the "cause" parameter of a SIP reason-value in a Reason header field [RFC3326], typically when the called party user agent issues a BYE request terminating an incoming call or a forking proxy issues a CANCEL request after receiving a 607 response from one of the branches. (Including a Reason header field with the 607 status code allows the called party user agent that receives a CANCEL request to make an informed choice whether and how to include such calls in their missed-call list or whether to show an appropriate indication to the user.)
响应代码607可用于针对邀请、消息、订阅或其他对话外SIP请求的故障响应中，以指示所提供的通信是不需要的。响应代码还可以用作原因报头字段[RFC3326]中SIP原因值的“原因”参数的值，通常是当被叫方用户代理发出终止传入呼叫的BYE请求或分叉代理在接收到来自其中一个分支的607响应后发出取消请求时。（包括带有607状态代码的原因标头字段允许接收取消请求的被叫方用户代理做出知情选择，是否以及如何将此类呼叫包括在其未接呼叫列表中，或者是否向用户显示适当的指示。）
The SIP entities receiving this response code are not obligated to take any particular action beyond those appropriate for 6xx responses. Following the default handling for 6xx responses in [RFC5057], the 607 response destroys the transaction. The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party's identity to consumer complaint databases. As discussed in Section 6, reversing the 'unwanted' labeling is beyond the scope of this mechanism, as it will likely require a mechanism other than call signaling.
接收此响应代码的SIP实体没有义务采取任何超出适用于6xx响应的特定行动。在[RFC5057]中对6xx响应进行默认处理之后，607响应将销毁事务。向发出响应的用户发送呼叫或消息的服务提供商可以采取一系列行动，例如，将呼叫方添加到特定于被呼叫方的个人黑名单中，在计算呼叫方发出不想要的呼叫的可能性时使用该信息作为输入（“众包”），发起回溯请求，或向消费者投诉数据库报告呼叫方的身份。如第6节所述，反转“不需要的”标签超出了该机制的范围，因为它可能需要呼叫信令以外的机制。
The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user.
用户体验在某种程度上类似于电子邮件垃圾邮件按钮，其中电子邮件提供商的详细操作对用户来说仍然是不透明的。
The mechanism described here is only one of many inputs likely to be used by call-filtering algorithms operated by service providers, using data on calls from a particular identifier such as a telephone number to establish handling for future calls from the same identifier. Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. These may use call characteristics such as call duration and call volumes for a particular caller, including changes in those metrics over time, as well as user feedback via non-SIP approaches and the mechanism described here. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls.
这里描述的机制只是服务提供商操作的呼叫过滤算法可能使用的许多输入中的一个，使用来自特定标识符（例如电话号码）的呼叫数据来建立对来自相同标识符的未来呼叫的处理。不需要的呼叫处理可能涉及启发式、分析和机器学习的组合。这些可以使用呼叫特征，例如特定呼叫方的呼叫持续时间和呼叫量，包括这些指标随时间的变化，以及通过非SIP方法和此处描述的机制的用户反馈。实现必须在错误地将呼叫者标记为不需要的呼叫者和发送不需要的呼叫者之间进行适当的权衡。
Systems receiving 607 responses could decide to treat pre-call and mid-call responses differently, given that the called party has had access to call content for mid-call rejections.
接收607个响应的系统可以决定以不同的方式处理呼叫前和呼叫中的响应，因为被叫方已经可以访问呼叫中拒绝的呼叫内容。
Depending on the implementation, the response code does not necessarily automatically block all calls from that caller identity. The same user interface action might also trigger addition of the caller identity to a local, on-device blacklist or graylist, e.g., causing such calls to be flagged or alerted with a different ring tone.
根据实现的不同，响应代码不一定会自动阻止来自该呼叫者身份的所有呼叫。相同的用户界面操作还可能触发将呼叫者身份添加到本地、设备上的黑名单或灰名单，例如，导致用不同的铃声标记或提醒此类呼叫。
The actions described here do not depend on the nature of the SIP URI, e.g., whether or not it describes a telephone number; however, the same anonymous SIP URI [RFC3323] may be used by multiple callers; thus, such URIs are unlikely to be appropriate for URI-specific call treatment. SIP entities tallying responses for particular callers may need to consider canonicalzing SIP URIs, including telephone
这里描述的操作不取决于SIP URI的性质，例如，它是否描述电话号码；然而，相同的匿名SIP URI[rfc323]可由多个呼叫者使用；因此，这样的URI不太可能适合于特定于URI的调用处理。SIP实体响应特定呼叫方可能需要考虑规范化SIP URI，包括电话。
numbers, as described in [SIP-IDENTITY]. The calling party may be identified in different locations in the SIP header, e.g., the From header field, P-Asserted-Identity or History-Info, and may also be affected by diverting services.
编号，如[SIP-IDENTITY]中所述。呼叫方可以在SIP报头中的不同位置被识别，例如，From报头字段、P-Asserted-Identity或History Info，并且还可以受到转移服务的影响。
This document defines a SIP feature-capability [RFC6809], sip.607, that allows the registrar to indicate that the corresponding proxy supports this particular response code. This allows the UA, for example, to provide a suitable user-interface element, such as a "spam" button, only if its service provider actually supports the feature. The presence of the feature capability does not imply that the provider will take any particular action, such as blocking future calls. A UA may still decide to render a "spam" button even without such a capability if, for example, it maintains a device-local blacklist or reports unwanted calls to a third party.
本文档定义了SIP特性功能[RFC6809]SIP.607，该功能允许注册器指示相应的代理支持此特定响应代码。例如，这允许UA仅在其服务提供商实际支持该功能时，才提供适当的用户界面元素，例如“垃圾邮件”按钮。特性功能的存在并不意味着提供者将采取任何特定的操作，例如阻止将来的调用。UA可能仍然决定呈现“垃圾邮件”按钮，即使没有这种功能，例如，如果它维护设备本地黑名单或向第三方报告不需要的呼叫。
This document registers a new SIP response code. This response code is defined by the following information, which has been added to the "Response Codes" subregistry under the "Session Initiation Protocol (SIP) Parameters" registry <http://www.iana.org/assignments/sip-parameters>.
本文档注册了一个新的SIP响应代码。此响应代码由以下信息定义，这些信息已添加到“会话启动协议（SIP）参数”注册表下的“响应代码”子区域<http://www.iana.org/assignments/sip-parameters>.
Response Code: 607
答复代码：607
Description: Unwanted
描述：不需要的
Reference: [RFC8197]
参考文献：[RFC8197]
This document defines the feature capability sip.607 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809].
本文档在[RFC6809]中定义的“sip功能能力指标注册树”注册表中定义了功能能力sip.607。
Name: sip.607
姓名：sip.607
Description: This feature-capability indicator, when included in a Feature-Caps header field of a REGISTER response, indicates that the server supports, and will process, the 607 (Unwanted) response code.
描述：当包含在寄存器响应的feature Caps标头字段中时，此功能能力指示器表示服务器支持并将处理607（不需要的）响应代码。
Reference: [RFC8197]
参考文献：[RFC8197]
If the calling party address is spoofed, users may report the caller identity as placing unwanted calls, possibly leading to the blocking of calls from the legitimate user of the caller identity in addition to the unwanted caller, i.e., creating a form of denial-of-service attack. Thus, the response code SHOULD NOT be used for creating global call filters unless the calling party identity has been authenticated using [SIP-IDENTITY] as being assigned to the caller placing the unwanted call. (The creation of call filters local to a user agent is beyond the scope of this document.)
如果主叫方地址被欺骗，用户可能会将主叫方身份报告为放置了不需要的呼叫，这可能导致除了不需要的主叫方之外，还阻止来自主叫方身份的合法用户的呼叫，即，创建一种形式的拒绝服务攻击。因此，响应代码不应用于创建全局呼叫过滤器，除非呼叫方身份已通过使用[SIP-identity]进行身份验证，因为该身份被分配给发出不需要的呼叫的呼叫方。（创建用户代理本地的呼叫筛选器超出了本文档的范围。）
Even if the identity is not spoofed, a call or message recipient might flag legitimate caller identities, e.g., to exact vengeance on a person or business, or simply by mistake. To correct errors, any additions to a personal list of blocked caller identities should be observable and reversible by the party being protected by the blacklist. For example, the list may be shown on a web page or the subscriber may be notified by periodic email reminders. Any additions to a global or carrier-wide list of unwanted callers needs to consider that any user-initiated mechanism will suffer from an unavoidable rate of false positives and tailor their algorithms accordingly, e.g., by comparing the fraction of delivered calls for a particular caller that are flagged as unwanted rather than just the absolute number and considering time-weighted filters that give more credence to recent feedback.
即使身份没有被欺骗，呼叫或消息接收者也可能会标记合法的呼叫者身份，例如，为了报复某人或企业，或者仅仅是因为错误。为了纠正错误，被黑名单保护的一方应能观察到被阻止的来电者身份的个人列表中的任何添加内容，并且这些添加内容是可逆的。例如，该列表可以显示在网页上，或者可以通过定期电子邮件提醒通知订户。任何添加到不受欢迎的呼叫者的全球或运营商列表中，需要考虑到任何用户发起的机制都会遭受不可避免的误报率，并相应地修改它们的算法，例如，通过比较被标记为不需要的特定呼叫者的已发送呼叫的分数，而不仅仅是绝对数字，并考虑时间加权过滤器，以使最近的反馈更加可信。
If an attacker on an unsecured network can spoof SIP responses for a significant number of call recipients, it may be able to convince the call-filtering algorithm to block legitimate calls. Use of TLS to protect signaling mitigates against this risk.
如果不安全网络上的攻击者可以欺骗大量呼叫接收者的SIP响应，那么它可能能够说服呼叫过滤算法阻止合法呼叫。使用TLS来保护信令可以减轻这种风险。
Since caller identities are routinely reassigned to new subscribers, algorithms are advised to consider whether the caller identity has been reassigned to a new subscriber and possibly reset any related rating. (In some countries, there are services that track which telephone numbers have been disconnected before they are reassigned to a new subscriber.)
由于呼叫者身份被常规地重新分配给新订户，因此建议算法考虑呼叫者身份是否已重新分配给新订户，并可能重置任何相关评级。（在某些国家/地区，有一些服务跟踪哪些电话号码在重新分配给新用户之前已断开连接。）
Some call services, such as 3PCC [RFC3725] and call transfer [RFC5359], increase the complexity of identifying who (if anyone) should be impacted by the receipt of 607 within BYE. Such services might cause the wrong party to be flagged or prevent flagging the desired party.
一些呼叫服务，如3PCC[RFC3725]和呼叫转移[RFC5359]，增加了识别谁（如果有人）应该受到BYE内607接收的影响的复杂性。此类服务可能会导致错误的一方被标记或阻止标记所需的一方。
For both individually authenticated and unauthenticated calls, recipients of response code 607 may want to distinguish responses sent before and after the call has been answered, ascertaining whether either response timing suffers from a lower false-positive rate.
对于单独认证的呼叫和未认证的呼叫，响应代码607的接收者可能想要区分在呼叫被应答之前和之后发送的响应，以确定任一响应定时是否遭受较低的误报率。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，DOI 10.17487/RFC3326，2002年12月<http://www.rfc-editor.org/info/rfc3326>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, <http://www.rfc-editor.org/info/rfc6809>.
[RFC6809]Holmberg，C.，Sedlacek，I.，和H.Kaplan，“表明支持会话启动协议（SIP）中的功能和能力的机制”，RFC 6809，DOI 10.17487/RFC6809，2012年11月<http://www.rfc-editor.org/info/rfc6809>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<http://www.rfc-editor.org/info/rfc3323>.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <http://www.rfc-editor.org/info/rfc3725>.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 3725，DOI 10.17487/RFC3725，2004年4月<http://www.rfc-editor.org/info/rfc3725>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<http://www.rfc-editor.org/info/rfc3966>.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, January 2008, <http://www.rfc-editor.org/info/rfc5039>.
[RFC5039]Rosenberg，J.和C.Jennings，“会话启动协议（SIP）和垃圾邮件”，RFC 5039，DOI 10.17487/RFC5039，2008年1月<http://www.rfc-editor.org/info/rfc5039>.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[RFC5057]Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，DOI 10.17487/RFC5057，2007年11月<http://www.rfc-editor.org/info/rfc5057>.
[RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>.
[RFC5359]Johnston，A.，Ed.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，DOI 10.17487/RFC5359，2008年10月<http://www.rfc-editor.org/info/rfc5359>.
[SIP-IDENTITY] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-16, February 2017.
[SIP-IDENTITY]Peterson，J.，Jennings，C.，Rescorla，E.，和C.Wendt，“会话启动协议（SIP）中的身份验证管理”，正在进行的工作，草案-ietf-stir-rfc4474bis-16，2017年2月。
Acknowledgements
致谢
Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale Worley, and Peter Yee (Gen-ART reviewer) provided helpful comments.
托尔加·阿斯维伦、本·坎贝尔、彼得·道斯、斯宾塞·道金斯、马丁·多利、基思·德拉格、维杰·古巴尼、克里斯特·霍姆伯格、奥利·约翰逊、保罗·基齐瓦特、让·马奥尼、玛丽安·莫哈里、亚当·蒙特维尔、艾尔·莫顿、丹尼斯·奥文科、布赖恩·罗森、布雷特·泰特、克里斯·温特、戴尔·沃利和彼得·耶伊（Gen艺术评论家）提供了有益的评论。
Author's Address
作者地址
Henning Schulzrinne FCC 445 12th Street SW Washington, DC 20554 United States of America
美国华盛顿特区西南12街445号亨宁·舒尔兹林内联邦通信委员会，邮编20554
Email: henning.schulzrinne@fcc.gov
Email: henning.schulzrinne@fcc.gov