Network Working Group D. Willis, Ed.
Request for Comments: 5373 Softarmor Systems
Category: Standards Track A. Allen
Research in Motion (RIM)
November 2008
Network Working Group D. Willis, Ed.
Request for Comments: 5373 Softarmor Systems
Category: Standards Track A. Allen
Research in Motion (RIM)
November 2008
Requesting Answering Modes for the Session Initiation Protocol (SIP)
请求会话启动协议（SIP）的应答模式
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" (STD1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关此协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined.
本文档使用两个标题字段和相关选项标记扩展了SIP，这些字段和标记可用于INVITE请求中，以传达请求者对与响应该请求相关的用户界面处理的偏好。第一个报头“应答模式”表示目标节点的用户界面是在接受请求之前等待用户输入，还是在不等待用户输入的情况下接受请求。第二个报头“Priv Answer Mode”与第一个报头类似，只是它请求管理级别的访问，并具有相应的附加身份验证和授权要求。这些行为适用于按键通话等应用程序和环回等诊断。还定义了响应中用于指示如何处理请求的每个头字段的用法。
Table of Contents
目录
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Syntax of Header Fields and Option Tags . . . . . . . . . . . 5
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields . 6
4. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Requests . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The Difference Between Answer-Mode and Priv-Answer-Mode . 7
4.2. The "require" Modifier . . . . . . . . . . . . . . . . . . 9
4.3. Procedures at User Agent Clients (UAC) . . . . . . . . . . 9
4.3.1. All Requests . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. REGISTER Transactions . . . . . . . . . . . . . . . . 9
4.3.3. INVITE Transactions . . . . . . . . . . . . . . . . . 10
4.4. Procedures at Intermediate Proxies . . . . . . . . . . . . 12
4.4.1. General Proxy Behavior . . . . . . . . . . . . . . . . 12
4.4.2. Issues with Automatic Answering and Forking . . . . . 12
4.5. Procedures at User Agent Servers (UAS) . . . . . . . . . . 13
4.5.1. INVITE Transactions . . . . . . . . . . . . . . . . . 13
5. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Responses . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedures at the UAS . . . . . . . . . . . . . . . . . . 14
5.2. Procedures at the UAC . . . . . . . . . . . . . . . . . . 15
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 15
6.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 15
6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16
6.3. 200 (OK) Response . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Attack Sensitivity Depends on Media Characteristics . . . 17
7.2. Application Design Affects Attack Opportunity . . . . . . 19
7.3. Applying the Analysis . . . . . . . . . . . . . . . . . . 19
7.4. Minimal Policy Requirement . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Registration of Header Fields . . . . . . . . . . . . . . 22
8.2. Registration of Header Field Parameters . . . . . . . . . 22
8.3. Registration of SIP Option Tags . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Syntax of Header Fields and Option Tags . . . . . . . . . . . 5
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields . 6
4. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Requests . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The Difference Between Answer-Mode and Priv-Answer-Mode . 7
4.2. The "require" Modifier . . . . . . . . . . . . . . . . . . 9
4.3. Procedures at User Agent Clients (UAC) . . . . . . . . . . 9
4.3.1. All Requests . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. REGISTER Transactions . . . . . . . . . . . . . . . . 9
4.3.3. INVITE Transactions . . . . . . . . . . . . . . . . . 10
4.4. Procedures at Intermediate Proxies . . . . . . . . . . . . 12
4.4.1. General Proxy Behavior . . . . . . . . . . . . . . . . 12
4.4.2. Issues with Automatic Answering and Forking . . . . . 12
4.5. Procedures at User Agent Servers (UAS) . . . . . . . . . . 13
4.5.1. INVITE Transactions . . . . . . . . . . . . . . . . . 13
5. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Responses . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedures at the UAS . . . . . . . . . . . . . . . . . . 14
5.2. Procedures at the UAC . . . . . . . . . . . . . . . . . . 15
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 15
6.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 15
6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16
6.3. 200 (OK) Response . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Attack Sensitivity Depends on Media Characteristics . . . 17
7.2. Application Design Affects Attack Opportunity . . . . . . 19
7.3. Applying the Analysis . . . . . . . . . . . . . . . . . . 19
7.4. Minimal Policy Requirement . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Registration of Header Fields . . . . . . . . . . . . . . 22
8.2. Registration of Header Field Parameters . . . . . . . . . 22
8.3. Registration of SIP Option Tags . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
The conventional model for session establishment using the Session Initiation Protocol (SIP, [RFC3261]) involves 1) sending a request for a session (a SIP INVITE) and notifying the user receiving the request, 2) acceptance of the request and of the session by that user, and 3) the sending of a response (SIP 200 OK) back to the requester before the session is established. Some usage scenarios deviate from this model, specifically with respect to the notification and acceptance phase. While it has always been possible for the node receiving the request to skip the notification and acceptance phases, there has been no standard mechanism for the party sending the request to specifically indicate a desire (or requirement) for this sort of treatment. This document defines a SIP extension header field that can be used to request specific treatment related to the notification and acceptance phase.
使用会话发起协议（SIP，[RFC3261]）建立会话的传统模型涉及1）发送会话请求（SIP INVITE）并通知接收请求的用户，2）该用户接受请求和会话，以及3）发送响应（SIP 200 OK）在会话建立之前返回请求者。某些使用场景与此模型不同，特别是在通知和接受阶段。虽然接收请求的节点总是可以跳过通知和接受阶段，但对于发送请求的一方来说，还没有标准的机制来明确表示这种处理的愿望（或要求）。本文档定义了一个SIP扩展头字段，可用于请求与通知和接受阶段相关的特定处理。
The first usage scenario is the requirement for diagnostic loopback calls. In this sort of scenario, a testing service sends an INVITE to a node being tested. The tested node accepts and a dialog is established. But rather than establishing a two-way media flow, the tested node loops back or "echoes" media received from the testing service back toward the testing service. The testing service can then analyze the media flow for quality and timing characteristics. Session Description Protocol (SDP) usage for this sort of flow is described in [LOOPBACK]. In this sort of application, it might not be necessary that the human using the tested node interact with the node in any way for the test to be satisfactorily executed. In some cases, it might be appropriate to alert the user to the ongoing test, and in other cases it might not be.
第一个使用场景是诊断环回调用的需求。在这种情况下，测试服务向正在测试的节点发送邀请。测试节点接受并建立对话框。但是，测试节点不会建立双向媒体流，而是将从测试服务接收到的媒体回送或“回送”到测试服务。然后，测试服务可以分析媒体流的质量和时序特征。这种流的会话描述协议（SDP）用法在[LOOPBACK]中描述。在这种类型的应用程序中，可能不需要使用被测试节点的人员以任何方式与节点交互，才能令人满意地执行测试。在某些情况下，提醒用户正在进行的测试可能是合适的，而在其他情况下可能不是。
The second scenario is that of push-to-talk applications, which have been specified by the Open Mobile Alliance. In this sort of environment, SIP is used to establish a dialog supporting asynchronous delivery of unidirectional media flow, providing a user experience like that of a traditional two-way radio. It is conventional for the INVITES used to be automatically accepted by the called UA (User Agent), and the media is commonly played out on a loudspeaker. The called party's UA's microphone is not engaged until the user presses the local "talk" button to respond.
第二个场景是由开放移动联盟指定的按键通话应用程序。在这种环境中，SIP用于建立支持单向媒体流异步交付的对话，提供与传统双向无线电类似的用户体验。通常，被调用的UA（用户代理）自动接受邀请，媒体通常通过扬声器播放。在用户按下本地“通话”按钮进行响应之前，被叫方的UA麦克风不会接通。
A third scenario is the Private Branch Exchange (PBX) attendant. Traditional office PBX systems often include intercom functionality. A typical use for the intercom function is to allow a receptionist to activate a loudspeaker on a desk telephone in order to announce a visitor. Not every caller can access the loudspeaker, only the
第三种方案是专用交换机（PBX）助理。传统的办公室PBX系统通常包括对讲机功能。对讲机功能的一个典型用途是允许接待员启动桌上电话上的扬声器，以便通知来访者。并非每个来电者都能使用扬声器，只有
receptionist or operator, and it is not expected that these callers will always want "intercom" functionality -- they might instead want to make an ordinary call.
接待员或接线员，不希望这些来电者总是想要“对讲”功能——他们可能想打一个普通的电话。
There are presumably many more use cases for the extensions defined in this specification, but this document was developed to specifically meet the requirements of these scenarios, or others with essentially similar properties.
本规范中定义的扩展可能有更多的用例，但本文档的开发是为了专门满足这些场景的要求，或者其他具有基本相似属性的场景的要求。
These sorts of mechanisms are not required to provide the functionality of an "answering machine" or "voice mail recorder". Such a device knows that it is expected to answer and does not require a SIP extension to support its behavior.
提供“答录机”或“语音邮件记录器”的功能不需要这些机制。这样的设备知道它需要应答，并且不需要SIP扩展来支持其行为。
Much of the discussion of this topic in working group meetings and on the mailing list dealt with differentiating "answering mode" from "alerting mode". Some early work did not make this distinction. We therefore proceed with the following definitions:
在工作组会议和邮件列表中，对这一主题的讨论大多涉及区分“应答模式”和“提醒模式”。一些早期的工作没有做出这种区分。因此，我们采用以下定义：
o Answering Mode includes behaviors in a SIP UA relating to acceptance or rejection of a request that are contingent on interaction between the UA and the user of that UA after the UA has received the request. We are principally concerned with the user interaction involved in accepting the request and initiating an active session. An example of this might be pressing the "yes" button on a mobile phone.
o 应答模式包括SIP UA中与请求的接受或拒绝相关的行为，这些行为取决于UA在接收到请求后与该UA的用户之间的交互。我们主要关注接受请求和启动活动会话所涉及的用户交互。例如，按下手机上的“是”按钮。
o Alerting Mode includes behaviors in a SIP UA relating to informing the user of the UA that a request to initiate a session has been received. An example of this might be activating the ring tone of a mobile phone.
o 警报模式包括SIP UA中与通知UA的用户已经接收到发起会话的请求有关的行为。例如，激活手机铃声。
This document deals only with "Answering Mode". Issues relating to "Alerting Mode" are outside its scope.
本文件仅涉及“应答模式”。与“警报模式”相关的问题超出其范围。
This document defines two SIP extension header fields: "Answer-Mode" and "Priv-Answer-Mode". These two extensions take the same parameters and operate in the same general way.
本文档定义了两个SIP扩展头字段：“应答模式”和“Priv应答模式”。这两个扩展采用相同的参数，并以相同的一般方式运行。
The distinction between Answer-Mode and Priv-Answer-Mode relates to the level of authorization claimed by the User Agent Client (UAC) and verified and policed by the User Agent Server (UAS). Requests are usually made using Answer-Mode. Requests made using Priv-Answer-Mode request "privileged" treatment from the UAS. This mechanism is discussed in greater detail below, in Section 4.1.
应答模式和Priv应答模式之间的区别与用户代理客户端（UAC）声明并由用户代理服务器（UAS）验证和管理的授权级别有关。请求通常使用应答模式进行。使用Priv应答模式发出的请求请求来自UAS的“特权”处理。下文第4.1节将更详细地讨论该机制。
Priv-Answer-Mode is not an assertion of privilege. Instead, it is a request for privileged treatment. This is similar to the UNIX model, where a user might run a command normally or use "sudo" to request administrative privilege for the command. Including "Priv-" is equivalent to prefixing a UNIX command with "sudo". In other words, a separate policy table (like "/etc/sudoers") is consulted to determine whether the user may receive the requested treatment.
Priv应答模式不是特权的断言。相反，这是一种特权待遇的要求。这与UNIX模型类似，在UNIX模型中，用户可以正常运行命令或使用“sudo”请求命令的管理权限。包含“Priv-”相当于在UNIX命令前面加上“sudo”。换言之，咨询一个单独的策略表（如“/etc/sudoers”），以确定用户是否可以接受请求的治疗。
This distinction is discussed in greater detail in Section 4.1.
第4.1节将更详细地讨论这一区别。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following syntax uses ABNF as defined in [RFC5234]. Further, it relies on the syntax for SIP defined in [RFC3261].
以下语法使用[RFC5234]中定义的ABNF。此外，它依赖于[RFC3261]中定义的SIP语法。
The syntax for the header fields defined in this document is:
本文档中定义的标题字段的语法为：
Answer-Mode = "Answer-Mode" HCOLON answer-mode-value *(SEMI answer-mode-param)
应答模式=“应答模式”HCOLON应答模式值*（半应答模式参数）
Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value *(SEMI answer-mode-param)
Priv-Answer Mode=“Priv-Answer Mode”HCOLON应答模式值*（半应答模式参数）
answer-mode-value = "Manual" / "Auto" / token
answer-mode-value = "Manual" / "Auto" / token
answer-mode-param= "require" / generic-param
应答模式param=“require”/generic param
The SIP option tag indicating support for this extension is "answermode".
表示支持此扩展的SIP选项标记为“answermode”。
For implementors: SIP header field names and values are always compared in a case-insensitive manner. The pretty capitalization is just for readability.
对于实现者：SIP头字段名称和值总是以不区分大小写的方式进行比较。漂亮的大写字母只是为了可读性。
This syntax includes extension hooks ("token" for answer-mode values and "generic-param" for optional parameters) that could be defined in future. This specification defines only the behavior for the values given explicitly above. In order to provide forward compatibility, implementations MUST ignore unknown values.
该语法包括扩展钩子（应答模式值的“token”和可选参数的“generic param”），这些钩子可以在将来定义。本规范仅定义上面明确给出的值的行为。为了提供前向兼容性，实现必须忽略未知值。
This document defines usage of the Answer-Mode and Priv-Answer-Mode header fields in initial (dialog-forming) SIP INVITE requests and in 200 (OK) responses to those requests. This document specifically does not define usage in any other sort of request or response, including but not limited to ACK, CANCEL, or any mid-dialog usage.
本文档定义了在初始（对话框形成）SIP INVITE请求和对这些请求的200（确定）响应中应答模式和Priv应答模式头字段的用法。本文档未明确定义任何其他类型的请求或响应中的用法，包括但不限于ACK、CANCEL或任何mid对话框用法。
This limitation stems from the intended usage of this extension, which is to affect the way that users interact with communications devices when requesting new communications sessions and when responding to such requests. This sort of interaction occurs only during the formation of a dialog and its initial usage, not during subsequent operations such as re-INVITE. However, the security aspects of the session initiation must be applied to changes in media description introduced by re-INVITES or similar requests. See Section 7.1 for further discussion of this issue.
此限制源于此扩展的预期用途，它将影响用户在请求新通信会话和响应此类请求时与通信设备交互的方式。这种交互仅在对话框的形成及其初始使用期间发生，而不是在后续操作（如重新邀请）期间发生。但是，会话启动的安全方面必须应用于重新邀请或类似请求引起的媒体描述更改。有关此问题的进一步讨论，请参见第7.1节。
4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Requests
4. 在请求中使用应答模式和Priv应答模式标头字段
The Answer-Mode or Priv-Answer-Mode header field is used by a UAC in an INVITE request to invoke specific handling by the responding UAS; this handling is related to "automatic answering" functionality for any dialog resulting from that INVITE request. If no Answer-Mode or Priv-Answer-Mode header field is included in the request, answering behavior is at the discretion of the UAS, as it would be in the absence of this specification. The desired handling is indicated by the value of the Answer-Mode or Priv-Answer-Mode header field, as follows:
UAC在INVITE请求中使用应答模式或Priv应答模式标头字段来调用响应UAS的特定处理；此处理与该邀请请求产生的任何对话框的“自动应答”功能有关。如果请求中未包含应答模式或Priv Answer Mode header字段，则应答行为由UAS自行决定，在没有本规范的情况下也是如此。所需的处理由应答模式或Priv应答模式标题字段的值指示，如下所示：
Manual: The UAS is asked to defer accepting the request until the user of the UAS has interacted with the user interface (UI) of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
手动：要求UAS推迟接受请求，直到UAS的用户与UAS的用户界面（UI）进行交互，以表明用户希望UAS接受请求。
Auto: The UAS is asked to accept the request automatically, without waiting for the user of the UAS to interact with the UI of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
自动：要求UAS自动接受请求，无需等待UAS用户与UAS的UI交互，以表明用户希望UAS接受请求。
Each value of the Answer-Mode or Priv-Answer-Mode header field can include an optional parameter, "require". If present, this parameter indicates that the UAC would prefer that the UAS reject the request if the UAS is unwilling (perhaps due to policy) to answer in the mode requested, rather than answering in another mode. For example, this
应答模式或Priv应答模式标题字段的每个值都可以包含一个可选参数“require”。如果存在，此参数表示如果UAS不愿意（可能是由于政策原因）以请求的模式应答，而不是以另一种模式应答，UAC更希望UAS拒绝请求。比如说这个,
parameter could be used to make sure that a test "loopback" call doesn't disturb a user who has configured her phone to manually answer even if the caller requests an automatic answer.
参数可用于确保测试“环回”呼叫不会干扰已将其手机配置为手动应答的用户，即使来电者请求自动应答。
The UAS is responsible for deciding how to honor this preference. In general, the UAS makes an authorization decision based on the authenticated identity presented in the request using authentication mechanisms such as SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], or (within the restricted networks for which it is suitable) the SIP mechanism for asserted identity within trusted networks [RFC3325]. When making an authorization decision, the UAS should also use authorization information or policy available to the UAS. This decision-making MUST consider the risk model of the media session corresponding to the request, and the UAS MUST NOT answer without user input in cases where the privacy or security of the user would be compromised as a result. Making this determination is a matter of system or application design, and cannot in general be addressed by having a set of functions that are configurable on or off. Specific discussion of media sessions and appropriate policy is discussed in Section 7.
UAS负责决定如何履行这一优惠。通常，UAS使用诸如SIP摘要认证[RFC3261]、SIP身份机制[RFC4474]或（在其适用的受限网络内）等认证机制，基于请求中呈现的认证身份做出授权决策可信网络中断言身份的SIP机制[RFC3325]。在做出授权决策时，UAS还应使用UAS可用的授权信息或策略。这种决策必须考虑对应于请求的媒体会话的风险模型，并且在用户的隐私或安全性将因此受到损害的情况下，UAS必须在没有用户输入的情况下不应答。做出这一决定是一个系统或应用程序设计的问题，通常不能通过一组可配置开或关的功能来解决。第7节讨论了媒体会议和适当政策的具体讨论。
The functions of the Answer-Mode and Priv-Answer-Mode header fields are similar; they both ask that the UAS handle the request as specified by the header field's value (automatic or manual). The difference is in the way the requests interact with the UAS's policy. A typical UAS will have different policies for handling each header field. For example, assume that the user of a UAS has placed that UAS into "meeting mode", indicating that she is engaged in an important activity and does not wish to be spuriously interrupted. The UAS might disallow automatic answering for Answer-Mode requests while in "meeting mode". However, that UAS might allow automatic answering for requests made with Priv-Answer-Mode. There will probably be differences in authorization policy. For example, a UAS might be configured such that callers on the "friends" list are allowed to make requests using Answer-Mode but not Priv-Answer-Mode. That same UAS might be configured to only allow callers on the "administrators" list to use Priv-Answer-Mode. This is different from always basing the behavior on the identity of the calling party. For example, assume caller "Bob" is on both the "friends" list and "administrators" list. If Bob wants his request to be processed according to the regular policy, he uses Answer-Mode. If Bob wants his request to be processed under the more restrictive "privileged" policy, he uses Priv-Answer-Mode.
应答模式和Priv应答模式标题字段的功能相似；它们都要求UAS根据标题字段的值（自动或手动）处理请求。区别在于请求与UAS策略的交互方式。典型的UAS将有不同的策略来处理每个标头字段。例如，假设UAS的用户已将该UAS置于“会议模式”，表示她正在进行一项重要活动，不希望被错误打断。UAS可能不允许在“会议模式”下对应答模式请求进行自动应答。但是，UAS可能允许自动应答以Priv应答模式发出的请求。授权策略可能会有所不同。例如，UAS可能被配置为允许“朋友”列表中的呼叫者使用应答模式而不是Priv应答模式发出请求。相同的UAS可能被配置为仅允许“管理员”列表上的呼叫者使用Priv应答模式。这与总是基于呼叫方身份的行为不同。例如，假设调用方“Bob”同时在“朋友”列表和“管理员”列表中。如果Bob希望根据常规策略处理他的请求，他将使用应答模式。如果Bob希望在更严格的“特权”策略下处理他的请求，他将使用Priv应答模式。
A UAS SHOULD apply a stricter authorization policy to a request with Priv-Answer-Mode than it does to requests with Answer-Mode. The default policy SHOULD be to refuse requests containing Priv-Answer-Mode header fields unless the requester is authenticated and specifically authorized to make Priv-Answer-Mode requests. Failure to enforce such a policy leaves the user potentially vulnerable to abuses, as discussed in Section 7.
UAS应该对具有Priv应答模式的请求应用比对具有应答模式的请求更严格的授权策略。默认策略应该是拒绝包含Priv-Answer-Mode头字段的请求，除非请求者经过身份验证并被特别授权发出Priv-Answer-Mode请求。如第7节所述，如果不执行此类政策，用户可能会被滥用。
The use case envisioned for Priv-Answer-Mode relates to handling urgent requests from authorized callers. For example, assume Larry is a limousine driver working with a fleet dispatcher. Larry likes to provide a quiet environment for his car, so his communicator is configured for manual answer mode for all non-privileged calls, including push-to-talk (Answer-Mode: Auto) calls. Each time he gets a call, Larry's communicator chimes softly to alert him to the call. If the circumstances permit it, Larry presses the communicator in order to accept the call, the communicator sends a 200 (OK) response, and the calling party's talk-burst is played out through the communicator's loudspeaker. This treatment is delivered to incoming requests that have an Answer-Mode header field having values of "Manual" or "Auto" (or no Answer-Mode header field at all), no matter who the caller is.
Priv Answer模式设想的用例涉及处理授权呼叫者的紧急请求。例如，假设拉里是一名与车队调度员一起工作的豪华轿车司机。Larry喜欢为他的车提供一个安静的环境，因此他的通讯器配置为所有非特权通话的手动应答模式，包括按键通话（应答模式：自动）通话。每次接到电话，拉里的通讯员都会轻轻地发出蜂鸣声提醒他注意电话。如果情况允许，Larry按下通讯器以接受呼叫，通讯器发送200（OK）响应，呼叫方的通话脉冲通过通讯器的扬声器播放。无论调用方是谁，都会将此处理传递给具有应答模式标头字段（其值为“手动”或“自动”（或根本没有应答模式标头字段）的传入请求。
Larry's fleet dispatch operator is familiar with this policy, and needs to inform Larry about a critical matter. The dispatch operator tries several times to push-to-talk call Larry (including Answer-Mode: Auto in the requests), but the calls aren't accepted because Larry has fallen asleep, and therefore isn't pressing his communicator to accept the call.
拉里的车队调度运营商熟悉该政策，需要将关键事项告知拉里。调度操作员多次尝试按键通话呼叫Larry（包括应答模式：请求中的自动），但呼叫未被接受，因为Larry睡着了，因此没有按通讯器接受呼叫。
The operator then presses his "urgent" button and calls Larry again. This time, the INVITE request carries a "Priv-Answer-Mode: Auto" header field. Larry's communicator checks the identity of the caller (using a SIP Identity assertion or functionally equivalent mechanism), and matches the operator's identity against the list of users allowed to do Priv-Answer-Mode. Since the operator is listed, the communicator immediately returns a 200 (OK) response accepting the call. The operator speaks, and the resulting talk-burst is summarily played out the loudspeaker on Larry's communicator, waking him up.
接线员然后按下“紧急”按钮，再次给拉里打电话。这一次，INVITE请求带有一个“Priv Answer Mode:Auto”标题字段。Larry的通信器检查呼叫者的身份（使用SIP身份断言或功能等效的机制），并将操作员的身份与允许执行Priv应答模式的用户列表相匹配。由于操作员已列出，通讯器立即返回200（OK）响应，接受呼叫。接线员讲话，由此产生的讲话突发立即通过拉里通讯器上的扬声器播放，把他吵醒。
The effect of requesting Priv-Answer-Mode is different than the effect of simply granting higher privilege to an Answer-Mode request based on the requester's identity and corresponding authorization level. This distinction is what allows the fleet operator to make polite (Answer-Mode: Auto) requests to Larry under normal conditions, and receive different handling (Priv-Answer-Mode: Auto) for a request having greater urgency.
请求Priv-Answer模式的效果不同于基于请求者的身份和相应的授权级别向应答模式请求授予更高权限的效果。这种区别使车队运营商能够在正常情况下向Larry发出礼貌（应答模式：自动）请求，并对紧急程度更高的请求接受不同的处理（Priv应答模式：自动）。
In normal operations, only one of either Answer-Mode or Priv-Answer-Mode would be used in an INVITE request. If both are present, the UAS will first test the authorization of the requester for Priv-Answer-Mode and, if authorized, process the request as if only Priv-Answer-Mode had been included. If the requester is not authorized for Priv-Answer-Mode, then the UAS will process the request as if only Answer-Mode had been included.
在正常操作中，INVITE请求中只能使用应答模式或Priv应答模式中的一种。如果两者都存在，UAS将首先测试请求者对Priv-Answer模式的授权，如果授权，则处理请求，就像只包括Priv-Answer模式一样。如果请求者未被授权使用Priv应答模式，则UAS将处理该请求，就像只包括应答模式一样。
Both Answer-Mode and Priv-Answer-Mode allow a modifier of "require" (example: "Priv-Answer-Mode: Auto;require"). This modifier does not influence the UAS's policy in choosing whether to answer manually or automatically. The UAS decides whether or not to answer automatically based on other aspects of the request. The "require" modifier is only evaluated after the UAS has selected an answering mode. If the UAS's policy has resulted in an answering mode that is different from that specified in the request, the presence of the "require" modifier asks the UAS to reject the call. In the given example, the UAS is being asked to answer automatically if the caller is authorized for automatic answering under the "privileged" policy, and to reject the call (rather than answering manually) if the caller is not authorized for this mode. This is discussed in more depth in Section 4.5.
应答模式和Priv应答模式都允许修改器“require”（例如：“Priv应答模式：Auto；require”）。此修饰符不影响UAS选择手动还是自动应答的策略。UAS根据请求的其他方面决定是否自动应答。“require”修饰符仅在UAS选择应答模式后进行评估。如果UAS的策略导致应答模式不同于请求中指定的应答模式，则“require”修饰符的存在会要求UAS拒绝呼叫。在给定的示例中，如果根据“特权”策略授权呼叫者自动应答，UAS将被要求自动应答，如果呼叫者未被授权此模式，UAS将被要求拒绝呼叫（而不是手动应答）。第4.5节对此进行了更深入的讨论。
A UA supporting the Answer-Mode and Priv-Answer-Mode header fields SHOULD indicate its support by including an option tag of "answermode" in the Supported header field of all requests it sends.
支持应答模式和Priv应答模式标头字段的UA应通过在其发送的所有请求的受支持标头字段中包含选项标记“answermode”来表示其支持。
To indicate that it supports the answer-mode negotiation feature, a UA MAY include an extensions parameter with a value that includes "answermode". Example:
为了表明其支持应答模式协商功能，UA可以包括一个扩展参数，其值包括“应答模式”。例子：
;extensions="answermode,100rel,gruu"
;extensions=“应答模式，100rel，gruu”
in the Contact header field of its REGISTER requests. This usage of feature tags is described in [RFC3840].
在其注册请求的联系人标头字段中。[RFC3840]中描述了特征标记的这种用法。
If a UA is dependent on support for callee capabilities in the registrar, it MAY include a Require header field with the value "pref" in its REGISTER request. This will cause the registrar to reject the request if the registrar does not support callee capabilities and caller preferences. Example:
如果UA依赖于注册器中对被叫方能力的支持，则它可以在其注册请求中包含一个值为“pref”的Require头字段。如果注册器不支持被叫方功能和主叫方首选项，这将导致注册器拒绝请求。例子：
Require: pref
要求：pref
A UAC supporting this specification MAY include an Answer-Mode or Priv-Answer-Mode header field in an INVITE where it wishes to influence the answering mode of the responding UAS.
支持本规范的UAC可在邀请中包括应答模式或Priv应答模式报头字段，其中UAC希望影响响应UAS的应答模式。
Note: This is meaningful only in initial or dialog-forming INVITE requests. Answer-Mode and Priv-Answer-Mode header fields appearing in other requests are ignored. In general, if the request would not normally result in a notification to the user and acceptance by that user (for example, "ringing" and "answering"), then these extensions are not applicable.
注意：这仅在初始或对话框形式的INVITE请求中有意义。其他请求中出现的应答模式和Priv应答模式标头字段将被忽略。一般来说，如果请求通常不会导致向用户发出通知并被该用户接受（例如，“响铃”和“应答”），则这些扩展不适用。
To request that the UAS answer only after having interacted with its user and receiving an affirmative instruction from that user, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Manual". Example:
为了请求UAS仅在与其用户交互并接收到该用户的肯定指示后进行应答，UAC包括一个值为“Manual”的应答模式或Priv应答模式报头字段。例子：
Answer-Mode: Manual
回答方式：手动
To request that the UAS answer manually, and ask that it reject the INVITE request if unable or unwilling to answer manually, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Manual" and a parameter of "require". Example:
为了请求UAS手动应答，并要求其在无法或不愿意手动应答时拒绝INVITE请求，UAC包括一个值为“Manual”和参数为“require”的应答模式或Priv应答模式标题字段。例子：
Answer-Mode: Manual;require
应答方式：手动；要求
To request that the UAS answer automatically without waiting for input from the user, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Auto". Example:
为了请求UAS在不等待用户输入的情况下自动应答，UAC包括一个值为“Auto”的应答模式或Priv应答模式报头字段。例子：
Answer-Mode: Auto
回答方式：自动
To request that the UAS answer automatically, and ask that it reject the INVITE request if unable or unwilling to answer automatically, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Auto" and a parameter of "require". Example:
为了请求UAS自动应答，并要求其在无法或不愿意自动应答时拒绝INVITE请求，UAC包括一个值为“Auto”和参数为“require”的应答模式或Priv应答模式标题字段。例子：
Answer-Mode: Auto;require
应答方式：自动；要求
To require that the UAS either support this extension or reject the request, the UAC includes a Require header field having the value "answermode". This does not actually force the UAS to automatically answer, it just requires that the UAS either understand this extension or reject the request. We do not have a SIP negotiation technique to force specific behavior. Rather, the desired behavior is indicated in the SIP extension itself. Example:
为了要求UAS支持此扩展或拒绝请求，UAC包含一个值为“answermode”的require标头字段。这实际上并不强制UAS自动应答，它只要求UAS理解此扩展或拒绝请求。我们没有SIP协商技术来强制特定的行为。而是在SIP扩展本身中指示所需的行为。例子：
Require: answermode
要求：应答模式
To request that retargeting proxies in the path preferentially select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter having a value of "answermode". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
为了请求路径中的重定目标代理优先选择在其注册中已指示支持此扩展的目标，UAC包括带有扩展参数值为“answermode”的Accept Contact header字段。[RFC3841]中描述了Accept Contact的这种用法。如上文所述，这通常与“Require:answermode”标题字段一起使用。例子：
Require: answermode Accept-Contact:
*;extensions="answermode";methods="INVITE"
Require: answermode Accept-Contact:
*;extensions="answermode";methods="INVITE"
To request that retargeting proxies in the path do not select targets that have indicated non-support for this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter having a value of "answermode" and an option field of "require". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
为了请求路径中的重定目标代理不选择已在其注册中指示不支持此扩展的目标，UAC包括一个Accept Contact标头字段，其中扩展参数的值为“answermode”，选项字段为“require”。[RFC3841]中描述了Accept Contact的这种用法。如上文所述，这通常与“Require:answermode”标题字段一起使用。例子：
Require: answermode Accept-Contact:
*;extensions="answermode"; methods="INVITE";require
Require: answermode Accept-Contact:
*;extensions="answermode"; methods="INVITE";require
To request that retargeting proxies in the path exclusively select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field extensions parameter having a value of "answermode" and options of "require" and "explicit". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
为了请求路径中的重定目标代理专门选择在其注册中表示支持此扩展的目标，UAC包括一个Accept Contact header field extensions参数，该参数的值为“answermode”，选项为“require”和“explicit”。[RFC3841]中描述了Accept Contact的这种用法。如上文所述，这通常与“Require:answermode”标题字段一起使用。例子：
Require: answermode Accept-Contact:
*;extensions="answermode";
methods="INVITE";require;explicit
Require: answermode Accept-Contact:
*;extensions="answermode";
methods="INVITE";require;explicit
The general procedure at all intermediate proxies, including the UAC's serving proxy or proxies and the UAS's serving proxy or proxies, is to ignore the Answer-Mode header field. However, the serving proxies (proxies responsible for resolving an address-of-record (AOR) into a registered contact) MAY exercise control over the requested answer mode, either inserting or deleting an Answer-Mode or Priv-Answer-Mode header field or altering the value of an existing header field, in accord with local policy. This could result in behavior that is inconsistent with user expectations (such as having a call that was intended to be a diagnostic loopback answered by a human) and consequently proxies MUST NOT insert, delete, or alter Answer-Mode or Priv-Answer-Mode header fields unless explicitly authorized to do so by an external agreement between the proxy operator and the user of the UA that the proxy is serving. These serving proxies MAY also reject a request according to local policy and, if they do so, SHOULD use the rejection codes as specified below for the UAS.
所有中间代理（包括UAC的一个或多个服务代理和UAS的一个或多个服务代理）的一般程序是忽略应答模式头字段。然而，服务代理（负责将记录地址（AOR）解析为注册联系人的代理）可以根据本地策略对请求的应答模式进行控制，插入或删除应答模式或Priv应答模式头字段，或更改现有头字段的值。这可能会导致与用户期望不一致的行为（例如，有一个由人工应答的诊断环回呼叫），因此代理不得插入、删除、，或更改应答模式或Priv应答模式头字段，除非代理操作员和代理服务的UA用户之间的外部协议明确授权这样做。这些服务代理还可以根据本地政策拒绝请求，如果他们这样做，则应使用下面为UAS指定的拒绝代码。
One of the well-known issues with forking is the problem of multiple acceptance. If an INVITE request is forked to several UASs and more than one replies with a 200 (OK) response, the conventional approach is to continue the dialog with the first respondent and tear down the dialog (using BYE requests) with all other respondents.
分叉的一个众所周知的问题是多重接受问题。如果一个INVITE请求被分叉到多个UAS，并且多个UAS回复200（OK）响应，传统的方法是继续与第一个响应者的对话，并与所有其他响应者中断对话（使用BYE请求）。
While this problem exists without an auto-answer negotiation capability, it is apparent that widespread adoption of UAs that engage in auto-answer behavior will exacerbate the multiple acceptance problem. Consequently, systems designers need to take this aspect into consideration. In general, auto-answer is NOT RECOMMENDED in environments that include parallel forking.
虽然这个问题在没有自动应答协商能力的情况下存在，但显然，广泛采用参与自动应答行为的UAs将加剧多重接受问题。因此，系统设计者需要考虑这一方面。通常，在包括并行分叉的环境中不建议使用自动应答。
As an alternative, it might be reasonable to use a variation on manual-answer combined with no alerting and early media. In this approach, the initial message or talk-burst is transmitted as early media to all recipients, where it is displayed or played out. Any response utterance (pushing the transmit key and talking) from the user of a UAS following this would serve as an "acceptance", resulting in a 200 (OK) response being transmitted by their UAS. Consequently, the race-condition for acceptance would be limited to the subset of UAs actually responding under user control, rather than the full set of UAs to which the request was forked.
另一种选择是，在手动回答的基础上，结合使用无警报和早期媒体，这可能是合理的。在这种方法中，初始消息或通话突发作为早期媒体发送给所有接收者，在那里显示或播放。UAS用户在此之后发出的任何响应（按下传输键并讲话）都将被视为“接受”，从而导致其UAS传输200（OK）响应。因此，接受的竞争条件将限于在用户控制下实际响应的UAs的子集，而不是请求分叉到的完整UAs集。
Another alternative would be to use dynamic conferencing instead of forking. In this approach, instead of forking the request, a conference would be initiated and all registered UAs invited into that conference. The mixer attached to the conference would then mediate traffic flows appropriately.
另一种选择是使用动态会议，而不是分叉。在这种方法中，将启动一次会议，并邀请所有注册的UAs参加该会议，而不是提出请求。然后，连接到会议的混合器将适当地调节交通流。
For a request having an Answer-Mode value of "Manual" and not having an Answer-Mode parameter of "require", the UAS SHOULD defer accepting the request until the user of the UAS has confirmed willingness to accept the request. This behavior MAY be altered as needed for unattended UASs or other local characteristics or policy. For example, an auto-attendant or Public Switched Telephone Network (PSTN) gateway system that always answers automatically would go ahead and answer, despite the presence of the "Manual" Answer-Mode header field value.
对于应答模式值为“手动”且应答模式参数为“要求”的请求，UAS应推迟接受该请求，直到UAS用户确认愿意接受该请求。根据无人值守UAS或其他本地特性或政策的需要，可以更改此行为。例如，始终自动应答的自动助理或公共交换电话网络（PSTN）网关系统将继续应答，尽管存在“手动”应答模式标题字段值。
For a request having an Answer-Mode value of "Manual" and an Answer-Mode parameter of "require", the UAS MUST defer accepting the request until the user of the UAS has confirmed willingness to accept the request. If the UAS is not capable of answering the request in this "Manual" mode or is unwilling to do so, it MUST reject the request, SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "manual answer forbidden".
对于应答模式值为“手动”且应答模式参数为“要求”的请求，UAS必须推迟接受该请求，直到UAS用户确认愿意接受该请求。如果UAS无法在此“手动”模式下回答请求或不愿意这样做，则必须拒绝请求，并应以“403（禁止）”响应进行拒绝，并可能包括“手动回答禁止”的原因短语。
For a request having an Answer-Mode value of "Auto", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request without further user input. The UAS MAY, according to local policy or user preferences, treat this request as it would treat a request having an Answer-Mode with a value of "Manual" or having no Answer-Mode header field. If the calling party is not authenticated and authorized for automatic answer, the UAS MAY either handle the request as per "manual", or reject the request. If the UAS rejects the request, it SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden". There may be an interaction with [RFC3261] section 23.2, which in some cases requires user validation of certificates used for S/MIME. Since this places the same interrupt burden on the user as would manually answering the request, a UAS experiencing this requirement for user validation of a request that requires automatic answering SHOULD reject the request with a "403 (Forbidden)" response and MAY include a reason phrase of "certificate validation requires user input not compatible with automatic answer."
对于应答模式值为“Auto”的请求，如果呼叫方经过身份验证并获得自动应答授权，UAS应在无需进一步用户输入的情况下接受该请求。UAS可根据本地策略或用户偏好，将该请求视为其将处理具有值为“手动”的应答模式或无应答模式报头字段的请求。如果主叫方未经身份验证和自动应答授权，UAS可根据“手册”处理请求，或拒绝请求。如果UAS拒绝请求，则应以“403（禁止）”响应进行拒绝，并可能包括“自动回答禁止”的原因短语。可能存在与[RFC3261]第23.2节的交互，在某些情况下需要用户验证用于S/MIME的证书。由于这会给用户带来与手动应答请求相同的中断负担，因此遇到需要自动应答的请求的用户验证要求的UAS应使用“403（禁止）”响应拒绝该请求，并可能包括以下原因短语：“证书验证要求用户输入与自动应答不兼容。”
For a request having an Answer-Mode value of "Auto" and an Answer-Mode parameter of "require", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request. The UAS MUST NOT allow "manual" answer of this request, but MAY reject it. If, for whatever reason, the UAS chooses not to accept the request automatically, the UAS MUST reject the request, SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden".
对于应答模式值为“Auto”且应答模式参数为“require”的请求，如果主叫方已被认证并授权自动应答，UAS应接受该请求。UAS不得允许“手动”回答该请求，但可以拒绝该请求。如果出于任何原因，UAS选择不自动接受请求，则UAS必须拒绝该请求，并应做出“403（禁止）”响应，并可能包括“自动回答禁止”的原因短语。
Similar behavior applies for Priv-Answer-Mode, except that the policy for authorization may be different (and generally more stringent).
类似的行为适用于Priv Answer模式，但授权策略可能不同（通常更严格）。
5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Responses
5. 应答中应答模式和Priv应答模式头字段的使用
The Answer-Mode or Priv-Answer-Mode header field can be inserted by a UAS into a response in order to indicate how it handled the associated request with respect to automatic answering functionality. The UAC might use this information to inform the user or otherwise adapt the behavior of the user interface. The handling is indicated by the value of the header field, as follows:
UAS可将应答模式或Priv应答模式标题字段插入到响应中，以指示其如何处理与自动应答功能相关的请求。UAC可能会使用此信息通知用户或以其他方式调整用户界面的行为。处理由标题字段的值指示，如下所示：
Manual: The UAS responded after the user of the UAS interacted with the user interface (UI) of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
手动：UAS的用户与UAS的用户界面（UI）交互后，UAS作出响应，表明用户希望UAS接受请求。
Auto: The UAS responded automatically, without waiting for the user of the UAS to interact with the UI of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
自动：UAS自动响应，无需等待UAS的用户与UAS的UI交互，以表明用户希望UAS接受请求。
The Answer-Mode and Priv-Answer-Mode header fields, when used in responses, are only valid in a 200 (OK) response to an INVITE request.
应答模式和Priv应答模式标头字段在应答中使用时，仅在对INVITE请求的200（确定）应答中有效。
A UAS supporting this specification inserts an Answer-Mode or Priv-Answer-Mode header field into the 200 (OK) response to an INVITE request when it wishes to inform the UAC as to whether the request was answered manually or automatically. It is reasonable for a UAS to assume that if the UAC included an Answer-Mode header field in the request, it would probably like to see an Answer-Mode header field in the response. The full rationale for including or not including this header field in a response is outside of the scope of this specification, and is sensitive to the privacy concerns of the user of the UAS. For example, informing the calling party that a call was answered manually might reveal the presence of an "actual human" at the responding UAS. While in the general case the ensuing
支持本规范的UAS希望通知UAC请求是手动响应还是自动响应时，会在对INVITE请求的200（确定）响应中插入应答模式或Priv应答模式标头字段。UAS有理由假设，如果UAC在请求中包含应答模式头字段，它可能希望在响应中看到应答模式头字段。在响应中包含或不包含此标题字段的全部理由不在本规范的范围内，并且对UAS用户的隐私问题敏感。例如，通知呼叫方人工接听呼叫可能会显示响应UAS中存在“实际人员”。而在一般情况下
conversation would also reveal this same information, there might be cases where this information might need to be protected. Consequently, UASs supporting this specification SHOULD include appropriately configurable policy mechanisms for making this determination, and the default configuration SHOULD be to exclude this header field from responses.
对话也会透露同样的信息，在某些情况下可能需要保护这些信息。因此，支持此规范的UAS应该包括用于进行此确定的适当可配置的策略机制，默认配置应该是从响应中排除此标头字段。
A UAC MAY use the value of the Answer-Mode or Priv-Answer-Mode header field, if present, to adapt the user interface and/or inform the user about the handling of the request. For example, the user of a push-to-talk system might speak differently if she knows that the called party answered "in person" vs. having the call blare out of an unattended speaker phone.
UAC可以使用应答模式或Priv应答模式报头字段（如果存在）的值来调整用户界面和/或通知用户请求的处理。例如，一键通系统的用户如果知道被叫方是“亲自”接听电话，而不是通过无人值守的扬声器电话接听电话，可能会说不同的话。
The following examples show Bob registering a contact that supports the negotiation of answering mode. Alice then calls Bob with an INVITE request, asking for automatic answering and explicitly asking that the request not be routed to contacts that have not indicated support for this extension. Further, Alice requires that the request be rejected if Bob's UA does not support negotiation of answering mode. Bob replies with a 200 (OK) response indicating that the call was answered automatically.
以下示例显示Bob正在注册支持应答模式协商的联系人。Alice然后打电话给Bob，请求自动应答，并明确要求不要将请求路由到未表示支持此扩展的联系人。此外，如果Bob的UA不支持协商应答模式，Alice要求拒绝请求。Bob回复为200（OK），表示呼叫已自动应答。
The Content-Length header field shown in the examples contains a placeholder "..." instead of a valid Content-Length. Furthermore, the SDP bodies that would be expected in the INVITE requests and 200 (OK) responses are not shown.
示例中显示的内容长度标题字段包含占位符“…”而不是有效的内容长度。此外，未显示INVITE请求和200（OK）响应中预期的SDP主体。
In the following example, Bob's UA is registering and indicating that it supports the answermode extension.
在下面的示例中，Bob的UA正在注册并指示它支持answermode扩展。
REGISTER sip:example.com SIP/2.0
From: Bob<sip:bob@example.com>
To: Bob <sip:bob@example.com>
CallID: hh89as0d-asd88jkk@cell-phone.example.com
CSeq: 1 REGISTER
Contact: sip:cell-phone.example.com;
;audio
;+sip.extensions="answermode"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip"
REGISTER sip:example.com SIP/2.0
From: Bob<sip:bob@example.com>
To: Bob <sip:bob@example.com>
CallID: hh89as0d-asd88jkk@cell-phone.example.com
CSeq: 1 REGISTER
Contact: sip:cell-phone.example.com;
;audio
;+sip.extensions="answermode"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip"
In this example, Alice is calling Bob and asking Bob's UA to answer automatically. However, Alice is willing for Bob to answer manually if Bob's policy is to prefer manual answer, so Alice does not include a ";require" modifier on "Answer-Mode: Auto".
在本例中，Alice给Bob打电话，要求Bob的UA自动应答。但是，如果Bob的策略是更喜欢手动回答，Alice愿意让Bob手动回答，因此Alice在“回答模式：自动”上不包含“require”修饰符。
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>
Call-ID:3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Require: answermode
Accept-contact:*;require;explicit;extensions="answermode"
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>
Call-ID:3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Require: answermode
Accept-contact:*;require;explicit;extensions="answermode"
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
Here, Bob has accepted the call and his UA has answered automatically, which it indicates in the 200 (OK) response.
这里，Bob已接受呼叫，他的UA已自动应答，这在200（OK）响应中表示。
SIP/2.0 200 OK
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
From: Alice <sip:alice@example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>;tag=8321234356
Call-ID: 3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
SIP/2.0 200 OK
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
From: Alice <sip:alice@example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>;tag=8321234356
Call-ID: 3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
This specification adds the ability for a UAC to request potentially risky user interface behavior relating to the acceptance of an INVITE request by the UAS receiving the request. Specifically, the UAC can request that the UAS accept the request without input to the UAS by the user of the UAS (Answer-Mode: Auto).
本规范增加了UAC请求潜在风险用户界面行为的能力，该行为与接收请求的UAS接受INVITE请求有关。具体而言，UAC可以请求UAS接受请求，而无需UAS用户向UAS输入（应答模式：自动）。
There are several attacks possible here -- the most obvious being the ability to turn a phone into a remote listening device without its user being aware. Additional potential attacks include reverse
这里有几种可能的攻击——最明显的是在用户不知情的情况下将手机变成远程监听设备的能力。其他潜在攻击包括反向攻击
charge fraud, unsolicited push-to-talk communications (spam over push-to-talk (SPTT)), playout of obnoxious noises (the "whoopee cushion" attack), battery-rundown denial of service, "forced busy" denial of service, running up the victim's data transport bill, and phishing via session insertion (where an ongoing session is replaced by another without the victim's awareness).
收费欺诈、未经请求的一键通通信（spam over push-to-talk（SPTT））、播放令人讨厌的噪音（“呼呼声缓冲”攻击）、电池耗尽拒绝服务、“强迫忙碌”拒绝服务、抬高受害者的数据传输账单，以及通过会话插入进行钓鱼（在被害人不知情的情况下，正在进行的会话被另一个会话替换）。
Since SIP implementations do not commonly implement end-to-end message protections, this specification is completely dependent on transitive security across SIP proxies. Any misbehaving proxy can insert, delete, and/or alter the contents of the Answer-Mode and Priv-Answer-Mode header fields, and in general can do so without being noticed by either the UAC or UAS. Consequently, it is critical that any proxies in the path be not only trusted, but worthy of that trust. While proxies do not generally intentionally insert, delete, or alter the Answer-Mode and Priv-Answer-Mode header fields, this specification does note a use case for such manipulation by proxies acting on behalf of the user of a UAC or UAS that has limited support for the authentication or policy enforcement needed to securely exercise these extensions. Proxies that perform such extension-sensitive manipulation MUST therefore provide complete policy enforcement, as per the minimal policy discussed in Section 7.4.
由于SIP实现通常不实现端到端消息保护，因此该规范完全依赖于跨SIP代理的可传递安全性。任何行为不端的代理都可以插入、删除和/或更改应答模式和Priv Answer Mode头字段的内容，并且通常可以在UAC或UAS未注意到的情况下这样做。因此，路径中的任何代理不仅要受信任，而且要值得信任，这一点至关重要。虽然代理通常不会有意插入、删除或更改应答模式和Priv应答模式标题字段，本规范确实说明了代理代表UAC或UAS用户进行此类操作的用例，该UAC或UAS对安全执行这些扩展所需的身份验证或策略实施的支持有限。因此，根据第7.4节讨论的最低策略，执行此类扩展敏感操作的代理必须提供完整的策略实施。
The existing body of SIP work provides strong capabilities for authentication of requests, prevention of man-in-the-middle attacks, protection of the privacy and integrity of media flows, and so on (although as noted above, these capabilities usually rely on transitive trust across proxies). The behaviors added by the extensions in this document raise additional possibilities for attacks against media flows not completely addressed by existing SIP work, and therefore require analysis in this document.
现有的SIP工作为请求认证、防止中间人攻击、保护媒体流的隐私和完整性等提供了强大的功能（尽管如上所述，这些功能通常依赖于代理之间的可传递信任）。本文档中扩展添加的行为增加了攻击现有SIP工作未完全解决的媒体流的其他可能性，因此需要在本文档中进行分析。
Media attacks can be loosely categorized as:
媒体攻击大致可分为以下几类：
Insertion: Media is inserted into and played out by the victim UA without consent of the UA's user.
插入：媒体在未经UA用户同意的情况下插入并由受害UA播放。
Interception: The victim UA's media acquisition facility (such as a microphone or camera) is activated, producing a media stream, without the consent of the UA's user.
拦截：未经UA用户同意，激活受害者UA的媒体采集设备（如麦克风或摄像头），生成媒体流。
The danger of abuse varies greatly depending on the media characteristics of the session being established. Since the expressive range of media sessions that can be established by SIP is
滥用的危险性因所设立会议的媒体特点而大不相同。因为可以通过SIP建立的媒体会话的表达范围是
unbounded, we might find it more effective to model loose categories of media modality rather than explicitly describing every possible scenario. Security analysis can then be applied per modality.
无界的，我们可能会发现对松散的媒体形态分类建模比明确描述每一种可能的场景更有效。然后可以对每个模态应用安全性分析。
The media modalities of interest appear to be:
媒体关注的方式似乎是：
UAC-sourced (Inbound) Unidirectional Media Insertion: Sensitive media flows from the UAC and is rendered by the UAS, annoying the user of the UAS or disrupting the function of the UAS. We refer to this as the "whoopee-cushion" attack because of its utility in replicating the rude-noise-making seat cushion. The danger of this attack is quite literally amplified by a loudspeaker apparatus attached to the victim UAS. Media that has minimal secondary implication (such as sending a move in a chess game to a computer that isn't running a chess game) is related, but of far less significance. This sort of attack can also have other consequences, such as discharging the victim's battery or increasing charges for data transport to be paid by the victim.
UAC来源（入站）单向媒体插入：敏感媒体从UAC流出，由UAS呈现，骚扰UAS用户或干扰UAS功能。我们称之为“呼呼声座垫”攻击，因为它在复制制造噪音的座垫时非常有用。这种攻击的危险实际上被附在受害者UAS上的扬声器装置放大了。次要影响最小的媒体（例如，将棋局中的一步发送到不运行棋局的计算机）是相关的，但意义要小得多。这类攻击还可能产生其他后果，如放电受害者的电池或增加受害者支付的数据传输费用。
UAS-sourced (Outbound) Unidirectional Media Interception: Sensitive media flows from the UAS and is rendered by the UAC, violating the privacy of the user of the UAS. We refer to this as the "bug-my-phone" attack because that would appear to be the primary attack motivator.
UAS来源（出站）单向媒体拦截：敏感媒体从UAS流出，由UAC提供，侵犯了UAS用户的隐私。我们称之为“窃听我的手机”攻击，因为这似乎是主要的攻击动机。
Bidirectional Media Insertion or Interception: Bidirectional media is the common case when SIP is used in a voice-over-IP scenario or "traditional phone call". Once a media flow is established, both ends send and receive media without further engagement. The media information is presumed to be sensitive -- that is, if intercepted it damages the victim's privacy, and if inserted, it annoys or interferes with the recipient. Attacks of this sort might produce either the "whoopee-cushion" or "bug-my-phone" scenarios, potentially even simultaneously.
双向媒体插入或拦截：在IP语音场景或“传统电话呼叫”中使用SIP时，双向媒体是常见的情况。建立媒体流后，两端发送和接收媒体，无需进一步参与。媒体信息被认为是敏感的——也就是说，如果被截获会损害受害者的隐私，如果被插入，会骚扰或干扰接收者。这类攻击可能产生“呼呼缓冲”或“窃听我的手机”场景，甚至可能同时发生。
It seems reasonable to consider the "bug-my-phone" attack as being in a different class (potentially far more severe) than the "whoopee-cushion" attack. This distinction suggests that security policy could be established in different and presumably less restrictive fashion for inbound media flows than for outbound media flows. The set of callers from which a user would be willing to automatically accept inbound media is reasonably much broader than the set of callers to which a user would be willing to automatically grant outbound media access, although this may not be true in all environments, especially those where reception of unwanted media has unwanted financial consequences.
认为“Bug My Phone”攻击与“Woopee缓冲”攻击在一个不同的类（潜在地更严重）似乎是合情合理的。这种区别表明，对于入站媒体流，安全策略可以采用不同的方式建立，并且可能比对于出站媒体流的限制更少。用户愿意从中自动接受入站媒体的呼叫者集合比用户愿意自动授予出站媒体访问权限的呼叫者集合要广泛得多，尽管这可能并非在所有环境中都是如此，尤其是那些接收不需要的媒体会带来不需要的经济后果的地方。
For example, assume a UA is designed such that it can be used to receive push-to-talk calls to a loudspeaker, and it can be used as a "baby monitor" (has an open mic and streams received audio to listeners). The policy for activating the push-to-talk loudspeaker would probably need to be reasonably broad (perhaps "all the user's buddies"). However, the policy for the baby monitor would need to be very narrow (perhaps "only the baby's mother") or even completely closed. The minimal policy defined in Section 7.4 explicitly forbids the "baby monitor" functionality.
例如，假设UA的设计可以用于接收到扬声器的按键通话呼叫，并且可以用作“婴儿监视器”（有一个打开的麦克风，并将接收到的音频流传送给听众）。激活按键通话扬声器的策略可能需要相当广泛（可能是“所有用户的好友”）。然而，婴儿监护仪的政策需要非常狭窄（也许“只有婴儿的母亲”）甚至完全封闭。第7.4节中定义的最低政策明确禁止“婴儿监视器”功能。
In the most common use cases, the security aspects are somewhat mitigated by design aspects of the application. For example, in traditional telephony, the called party is alerted to the request (the phone rings), no media session is established without the acceptance of the called party (picking up the phone), and the media path is most commonly delivered to a single-user handset. Consequently, this application (although bidirectional) is relatively secure against both media insertion and media interception attacks of the sort enabled by the extensions in this document. The use of policy-free automatic-answering devices (like answering machines) and amplifiers (speakerphones and call-screening devices) weakens this defense.
在最常见的用例中，应用程序的设计方面在某种程度上减轻了安全方面的影响。例如，在传统电话技术中，被叫方收到请求（电话铃响），没有被叫方的接受（拿起电话），就不会建立媒体会话，并且媒体路径最常见地传送到单用户手机。因此，该应用程序（尽管是双向的）相对安全，可以抵御本文档中扩展所支持的媒体插入和媒体拦截攻击。使用无策略自动应答设备（如答录机）和扩音器（扬声器和电话屏蔽设备）削弱了这种防御。
In push-to-talk applications, media can be sent from UAC to UAS without user oversight, but no media is sent from the called UAS without user input (the "push" of "push-to-talk"). Consequently, there is no "bug-my-phone" attack opportunity. Further, screening of the UAC by eliminating UAC identities not on some sort of "white list" (often, a buddy list) reduces the threat of "whoopee cushion" attacks (except from one's buddies, of course).
在按键通话应用程序中，媒体可以在没有用户监督的情况下从UAC发送到UAS，但在没有用户输入的情况下，不会从被叫UAS发送媒体（“按键通话”的“按键”）。因此，不存在“bug my phone”攻击机会。此外，通过消除不在某种“白名单”（通常是好友名单）上的UAC身份对UAC进行筛选，可以减少“呼呼缓冲”攻击的威胁（当然，好友除外）。
Similar approaches apply to most applications. Insertion can be controlled (but not eliminated) by combining identity mechanisms with simple authorization policy, and interception can be effectively eliminated by combining strong identity mechanisms with aggressive authorization policy and/or user interaction.
类似的方法适用于大多数应用程序。通过将身份机制与简单授权策略相结合，可以控制（但不能消除）插入，通过将强身份机制与主动授权策略和/或用户交互相结合，可以有效地消除拦截。
The extensions described in this document provide mechanisms by which a UAC can request that a UAS not deploy two of the five defensive mechanisms listed below -- user alerting and user acceptance. In order for this not to produce undue risk of insertion attacks or increased risk of interception attacks, we are therefore forced to rely on the remaining defensive mechanisms. This document defines a minimum threshold for satisfactory security. Certainly more
本文档中描述的扩展提供了一些机制，UAC可以通过这些机制请求UAS不要部署下面列出的五种防御机制中的两种——用户警报和用户接受。因此，为了不产生不必要的插入攻击风险或增加拦截攻击风险，我们不得不依赖剩余的防御机制。本文件规定了令人满意的安全性的最低阈值。当然更多
restrictive policies might reasonably be used, but any policy less restrictive than the approach described below is very likely to result in significant security issues.
可以合理使用限制性策略，但任何比下面描述的方法限制性更小的策略都很可能导致重大安全问题。
From the previous discussion of risks, attacks, and vulnerabilities, we can derive five defensive mechanisms available at the application level:
从前面对风险、攻击和漏洞的讨论中，我们可以得出应用程序级别可用的五种防御机制：
1. Identity -- Know who the request came from.
1. 身份——知道请求来自谁。
2. Alerting -- Let the called user know what's happening. Some applications might use inbound media as an alert.
2. 警报——让被调用的用户知道发生了什么。某些应用程序可能将入站媒体用作警报。
3. Acceptance -- Require called user to make run-time decision. Asking the user to make a run-time decision without alerting the user to the need to make a decision is generally infeasible. This will have implications for possible alerting options that are outside the scope of this document.
3. 接受——要求被调用的用户做出运行时决策。要求用户在运行时做出决策而不提醒用户需要做出决策通常是不可行的。这将对本文档范围之外的可能警报选项产生影响。
4. Limit the Input/Output (I/O) -- Turn off loudspeakers or microphone. This could be used to convert a bidirectional media session (very risky, possible "bug my phone") into a unidirectional, inbound-only (less risky, possible "spam" or "rundown", etc.) session while waiting for user acceptance.
4. 限制输入/输出（I/O）——关闭扬声器或麦克风。这可用于在等待用户接受时将双向媒体会话（非常危险，可能是“bug my phone”）转换为单向、仅入站（风险较小，可能是“垃圾邮件”或“耗尽”等）会话。
5. Policy -- Rules about other factors, such as black- and whitelisting based on identity, disallowing acceptance without alerting, etc.
5. 政策——关于其他因素的规则，比如基于身份的黑名单和白名单，不允许在没有警告的情况下接受，等等。
Since SIP and related work already provide several mechanisms (including SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], and the SIP mechanism for asserted identity within private networks [RFC3325], in networks for which it is suitable) for establishing the identity of the originator of a request, we presume that an appropriately selected mechanism is available for UAs implementing the extensions described in this document. In short, UAs implementing these extensions MUST be equipped with and MUST exercise a request-identity mechanism. The analysis below proceeds from an assumption that the identity of the sender of each request is either known or is known to be unknown, and can therefore be considered in related policy considerations. Failure to meet this identity requirement either opens the door to a wide range of attacks or requires operational policy so tight as to make these extensions useless.
由于SIP和相关工作已经提供了几种机制（包括SIP摘要认证[RFC3261]、SIP身份机制[RFC4474]和专用网络内断言身份的SIP机制[RFC3325]，在其适用的网络中）来建立请求的发起人的身份，我们假设一个适当选择的机制可用于UAs实现本文档中描述的扩展。简言之，实现这些扩展的UAs必须配备并使用请求标识机制。下面的分析基于这样一种假设，即每个请求的发送者的身份要么已知，要么已知未知，因此可以在相关的策略考虑中加以考虑。如果不能满足此身份要求，则可能会导致各种攻击，或者需要严格的操作策略，以使这些扩展无效。
We previously established a class distinction between inbound and outbound media flows, and can model bidirectional flows as "worst case" sums of the risks of the other two classes. Given this distinction, it seems reasonable to provide separate directionality policy classes for:
我们之前在入站和出站媒体流之间建立了一个类别区分，并且可以将双向流建模为其他两个类别风险的“最坏情况”总和。鉴于这一区别，为以下各项提供单独的方向性策略类似乎是合理的：
1. Inbound media flows.
1. 入站媒体流。
2. Outbound media flows.
2. 出站媒体流。
For each directionality policy class, we can divide the set of request identities into three classes:
对于每个方向性策略类，我们可以将请求标识集分为三类：
1. Identities explicitly authorized for the class.
1. 为类显式授权的标识。
2. Identities explicitly denied for the class.
2. 该类的标识被明确拒绝。
3. Identities for which we have no explicit policy and need the user to make a decision.
3. 我们没有明确的策略，需要用户做出决定的身份。
Note that not all combinations of policies possible in this decomposition are generally useful. Specifically, a policy of "inbound media denied, outbound media allowed" equates to a "bug my phone" attack, and is disallowed by the minimal policy of Section 7.4, which as written excludes all cases of "Outbound media explicitly authorized".
请注意，并非此分解中可能的所有策略组合通常都有用。具体而言，“拒绝入站媒体，允许出站媒体”的策略等同于“窃听我的手机”攻击，第7.4节的最低策略不允许该策略，该策略书面排除了所有“明确授权出站媒体”的情况。
User agents implementing this specification SHOULD NOT establish a session providing inbound media without explicit user acceptance where the requesting user is unknown, or is known and has not been granted authorization for such a session. This requirement is intended to prevent "SPAM broadcast" attacks where unexpected and unwanted media is played out at a UAS .
实现本规范的用户代理不应在用户未明确接受的情况下建立提供入站媒体的会话，如果请求用户未知，或已知且未获得此类会话的授权。此要求旨在防止在UAS播放意外和不需要的媒体时发生“垃圾邮件广播”攻击。
User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media sourced from the user agent without explicit user acceptance. Loopback media used for connectivity testing is not constrained by this requirement. This requirement is intended to assure that this extension can not be used to turn a UAS into a remote-controlled microphone (or "bug") without the knowledge of its user. Since SIP allows for a session to be initially established with inbound-only media and then transitioned (via re-INVITE or UPDATE) to an outbound or bidirectional session,
未经用户明确接受，实现本规范的用户代理不得建立提供来自用户代理的出站或双向媒体的会话。用于连接测试的环回介质不受此要求的限制。此要求旨在确保在用户不知情的情况下，不能使用此扩展将UAS转换为遥控话筒（或“bug”）。由于SIP允许最初仅使用入站介质建立会话，然后（通过重新邀请或更新）转换为出站或双向会话，
enforcing this policy requires dialog-stateful inspection in the SIP UAS. In other words, if a session was initiated with automatic answering, the UAS MUST NOT transition to a mode that sends outbound media without explicit acceptance by the user of the UAS.
实施此策略需要在SIP UAS中进行对话状态检查。换言之，如果会话是通过自动应答启动的，则UAS不得转换为在未经UAS用户明确接受的情况下发送出站媒体的模式。
This document defines new SIP header fields named "Answer-Mode" and "Priv-Answer-Mode".
本文档定义了名为“应答模式”和“Priv应答模式”的新SIP头字段。
The following rows have been added to the "Header Fields" section of the SIP parameter registry:
以下行已添加到SIP参数注册表的“标题字段”部分：
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| Answer-Mode | | [RFC5373] |
| Priv-Answer-Mode | | [RFC5373] |
+------------------+--------------+-----------+
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| Answer-Mode | | [RFC5373] |
| Priv-Answer-Mode | | [RFC5373] |
+------------------+--------------+-----------+
This document defines parameters for the header fields defined in the preceding section. The header fields "Answer-Mode" and "Priv-Answer-Mode" can take the values "Manual" or "Auto".
本文档定义了上一节中定义的标题字段的参数。标题字段“应答模式”和“Priv应答模式”可以采用“手动”或“自动”的值。
The following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
以下行已添加到SIP参数注册表的“标题字段参数和参数值”部分：
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode | require | No | [RFC5373] |
| Priv-Answer-Mode | require | No | [RFC5373] |
+------------------+----------------+-------------------+-----------+
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode | require | No | [RFC5373] |
| Priv-Answer-Mode | require | No | [RFC5373] |
+------------------+----------------+-------------------+-----------+
This document defines the SIP option tag "answermode".
本文档定义了SIP选项标签“应答模式”。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the | [RFC5373] |
| | Answer-Mode and Priv-Answer-Mode | |
| | extensions used to negotiate automatic | |
| | or manual answering of a request. | |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the | [RFC5373] |
| | Answer-Mode and Priv-Answer-Mode | |
| | extensions used to negotiate automatic | |
| | or manual answering of a request. | |
+------------+------------------------------------------+-----------+
This document draws requirements and a large part of its methodology from the work of the Open Mobile Alliance, and specifically from a document by Andrew Allen, Jan Holm, and Tom Hallin.
本文档从开放移动联盟（OpenMobile Alliance）的工作中，特别是从Andrew Allen、Jan Holm和Tom Hallin的文档中，提取了需求和大部分方法。
The editor would also like to recognize the contributions of David Oran and others who argued on the SIPPING mailing list and at the OMA ad-hoc meeting at IETF 62 that the underlying ideas of the above document were broadly applicable to the SIP community, and that the concepts of alerting and answering should be clearly delineated. Further, the security review provided by Sandy Murphy and the gen-art review by Suresh Krishnan were very helpful in improving the quality of this document.
编辑还想感谢David Oran和其他人的贡献，他们在SIP邮件列表和IETF 62 OMA特别会议上提出，上述文件的基本思想广泛适用于SIP社区，警报和应答的概念应明确界定。此外，Sandy Murphy提供的安全审查和Suresh Krishnan提供的gen art审查对提高本文件的质量非常有帮助。
[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月。
[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月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[LOOPBACK] Hedayat, K., "An Extension to the Session Description Protocol (SDP) for Media Loopback", Work in Progress, August 2008.
[环回]Hedayat，K.，“媒体环回会话描述协议（SDP）的扩展”，正在进行的工作，2008年8月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
Authors' Addresses
作者地址
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 USA
Dean Willis（编辑）Softarmor Systems 3100 Independence Pkwy#311-164美国德克萨斯州普莱诺75075
EMail: dean.willis@softarmor.com
EMail: dean.willis@softarmor.com
Andrew Allen Research in Motion (RIM) 300 Knightsbridge Parkway, Suite 360 Lincolnshire, Illinois 60069 USA
美国伊利诺伊州林肯郡骑士桥公园路300号360室安德鲁·艾伦动态研究中心（RIM）60069
EMail: aallen@rim.com
EMail: aallen@rim.com