Internet Engineering Task Force (IETF) P. Dawes
Request for Comments: 8497 Vodafone Group
Category: Standards Track C. Arunachalam
ISSN: 2070-1721 Cisco Systems
November 2018
Internet Engineering Task Force (IETF) P. Dawes
Request for Comments: 8497 Vodafone Group
Category: Standards Track C. Arunachalam
ISSN: 2070-1721 Cisco Systems
November 2018
Marking SIP Messages to Be Logged
标记要记录的SIP消息
Abstract
摘要
SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.
SIP网络使用信令监控工具诊断用户报告的问题，并在升级网络或用户代理（UA）软件时执行回归测试。随着网络的增长和互联，包括通过传输网络的连接，预测SIP信令在用户代理之间的路径变得不切实际，因此监控SIP信令端到端变得不切实际。
This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.
本文档描述了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 https://www.rfc-editor.org/info/rfc8497.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8497.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4
3.1. Session-ID "logme" Parameter . . . . . . . . . . . . . . 4
3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 5
3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 6
3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 6
3.4.1. To/From a User Device . . . . . . . . . . . . . . . . 6
3.4.2. To/From an External Network . . . . . . . . . . . . . 6
3.4.3. Across a Non-supporting SIP Intermediary . . . . . . 6
3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6
3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 7
3.7. Marking-Related Dialogs . . . . . . . . . . . . . . . . . 7
3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 13
4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 13
4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 15
4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. "Log Me" Marker Processing by SIP Intermediaries . . . . 17
4.5.1. Stateless Processing . . . . . . . . . . . . . . . . 17
4.5.2. Stateful Processing . . . . . . . . . . . . . . . . . 17
4.5.2.1. "Log Me" Marking Not Supported by Originating UA 18
4.5.2.2. "Log Me" Marking Not Supported by Terminating UA 21
4.5.2.3. "Log Me" Marking Removed by Originating Network . 23
4.5.2.4. "Log Me" Marking Removed by Supporting
Terminating Network . . . . . . . . . . . . . . . 26
4.5.2.5. "Log Me" Marking Passed by Non-supporting
Terminating Network . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4
3.1. Session-ID "logme" Parameter . . . . . . . . . . . . . . 4
3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 5
3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 6
3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 6
3.4.1. To/From a User Device . . . . . . . . . . . . . . . . 6
3.4.2. To/From an External Network . . . . . . . . . . . . . 6
3.4.3. Across a Non-supporting SIP Intermediary . . . . . . 6
3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6
3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 7
3.7. Marking-Related Dialogs . . . . . . . . . . . . . . . . . 7
3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 13
4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 13
4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 15
4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. "Log Me" Marker Processing by SIP Intermediaries . . . . 17
4.5.1. Stateless Processing . . . . . . . . . . . . . . . . 17
4.5.2. Stateful Processing . . . . . . . . . . . . . . . . . 17
4.5.2.1. "Log Me" Marking Not Supported by Originating UA 18
4.5.2.2. "Log Me" Marking Not Supported by Terminating UA 21
4.5.2.3. "Log Me" Marking Removed by Originating Network . 23
4.5.2.4. "Log Me" Marking Removed by Supporting
Terminating Network . . . . . . . . . . . . . . . 26
4.5.2.5. "Log Me" Marking Passed by Non-supporting
Terminating Network . . . . . . . . . . . . . . . 28
5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Error Cases . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Missing "Log Me" Marker Error Case . . . . . . . . . 31
5.1.2. "Log Me" Marker Appears Mid-dialog Error Case . . . . 35
5.2. Non-error Cases . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. Missing "Log Me" Marker Non-error Case . . . . . . . 36
5.2.2. "Log Me" Marker Appears Mid-dialog Non-error Case . . 37
5.2.3. Combining Dialogs Non-error Case . . . . . . . . . . 37
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 38
6. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 39
7.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 39
7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 39
7.4. Data Protection . . . . . . . . . . . . . . . . . . . . . 40
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Personal Identifiers . . . . . . . . . . . . . . . . . . 40
8.2. Data Stored at SIP Intermediaries . . . . . . . . . . . . 41
8.3. Data Visible at Network Elements . . . . . . . . . . . . 41
8.4. Preventing Fingerprinting . . . . . . . . . . . . . . . . 41
8.5. Retaining Logs . . . . . . . . . . . . . . . . . . . . . 42
8.6. User Control of Logging . . . . . . . . . . . . . . . . . 42
8.7. Recommended Defaults . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Registration of the "logme" Parameter . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Error Cases . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Missing "Log Me" Marker Error Case . . . . . . . . . 31
5.1.2. "Log Me" Marker Appears Mid-dialog Error Case . . . . 35
5.2. Non-error Cases . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. Missing "Log Me" Marker Non-error Case . . . . . . . 36
5.2.2. "Log Me" Marker Appears Mid-dialog Non-error Case . . 37
5.2.3. Combining Dialogs Non-error Case . . . . . . . . . . 37
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 38
6. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 39
7.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 39
7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 39
7.4. Data Protection . . . . . . . . . . . . . . . . . . . . . 40
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Personal Identifiers . . . . . . . . . . . . . . . . . . 40
8.2. Data Stored at SIP Intermediaries . . . . . . . . . . . . 41
8.3. Data Visible at Network Elements . . . . . . . . . . . . 41
8.4. Preventing Fingerprinting . . . . . . . . . . . . . . . . 41
8.5. Retaining Logs . . . . . . . . . . . . . . . . . . . . . 42
8.6. User Control of Logging . . . . . . . . . . . . . . . . . 42
8.7. Recommended Defaults . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Registration of the "logme" Parameter . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
When users experience problems with setting up sessions using SIP, enterprise or service provider network operators often have to identify the root cause by examining the SIP signaling. Also, when network or user agent (UA) software or hardware is upgraded, regression testing is needed. Such diagnostics apply to a small proportion of network traffic and can apply end to end, even if signaling crosses several networks possibly belonging to several different network operators. It may not be possible to predict the path through those networks in advance, therefore, a mechanism is needed to mark a session as being of interest so that SIP entities along the signaling path can provide diagnostic logging. [RFC8123] illustrates this motivating scenario. This document describes a solution that meets the requirements for such "log me" marking of SIP signaling also defined in [RFC8123].
当用户在使用SIP设置会话时遇到问题时，企业或服务提供商网络运营商通常必须通过检查SIP信令来确定根本原因。此外，当网络或用户代理（UA）软件或硬件升级时，需要进行回归测试。这种诊断适用于一小部分网络流量，并且可以应用端到端，即使信令跨越可能属于多个不同网络运营商的多个网络。可能无法预先预测通过这些网络的路径，因此，需要一种机制来将会话标记为感兴趣的会话，以便沿着信令路径的SIP实体可以提供诊断日志记录。[RFC8123]说明了这种激励情景。本文件描述了一种解决方案，该解决方案满足[RFC8123]中定义的SIP信令的“log me”标记要求。
This document also defines a new header field parameter, "logme", for the Session-ID header field [RFC7989]. Implementations of this document MUST implement [RFC7989].
本文档还为会话ID头字段[RFC7989]定义了一个新的头字段参数“logme”。本文件的实施必须执行[RFC7989]。
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]所述进行解释。
Logging for diagnostic purposes is most effective when it is applied end to end in a communication session. This ability requires a "log me" marker to be passed through SIP intermediaries. The Session-ID header field defined in [RFC7989] was chosen to carry the "log me" marker as a "logme" parameter since the session identifier is typically passed through SIP Back-to-Back User Agents (B2BUAs) (described in [RFC7092]) or other intermediaries, as per the Session-ID requirement REQ3 in [RFC7206]. The "logme" parameter shown in Figure 1 does not introduce any device-specific or user-specific information and MUST be passed unchanged with the Session-ID header field. There is an exception, however, for the cases specified in Section 3.4.2 where the "log me" marker may be removed at a network boundary.
用于诊断目的的日志记录在通信会话中端到端应用时最为有效。此功能要求通过SIP中介传递“log me”标记。[RFC7989]中定义的会话ID报头字段被选择为携带“log me”标记作为“logme”参数，因为根据[RFC7206]中的会话ID要求REQ3，会话标识符通常通过SIP背靠背用户代理（B2BUA）（如[RFC7092]中所述）或其他中介传递。图1中所示的“logme”参数不引入任何特定于设备或用户的信息，并且必须与会话ID头字段一起传递，保持不变。但是，对于第3.4.2节中规定的情况，有一个例外情况，即“log me”标记可以在网络边界处移除。
Alice Proxy Registrar
u1.example.com p1.example.com r1.example.com
| | |
|(1) INVITE | |
| Session-ID: ab30317f1a784dc48ff824d0d3715d86;
| remote=47755a9de7794ba387653f2099600ef2;logme
|----------------->| |
| | |
Alice Proxy Registrar
u1.example.com p1.example.com r1.example.com
| | |
|(1) INVITE | |
| Session-ID: ab30317f1a784dc48ff824d0d3715d86;
| remote=47755a9de7794ba387653f2099600ef2;logme
|----------------->| |
| | |
Figure 1: "Log Me" Marking Using the "logme" Session-ID Header Field Parameter
图1：使用“logme”会话ID头字段参数进行“logme”标记
If a dialog is to be "log me" marked, then marking MUST start with the SIP request that initiates that dialog (dialog-initiating requests are described in Section 12.1 of [RFC3261]). For the most effective testing and troubleshooting, marking continues for the lifetime of the dialog, applies to each request and response in the dialog, and applies uninterrupted end to end (including user devices). The "log me" marking mechanism described in this document allows for parts of the signaling path to not be marked, e.g, because an endpoint does not support the "log me" marking mechanism (see Section 4.5.2) or because an endpoint or intermediary deliberately removes the "log me" marker (see Section 4.5.2.4). Also, marking errors can terminate marking before the dialog ends (see Section 5.3).
如果要对对话框进行“log me”标记，则标记必须从启动该对话框的SIP请求开始（对话框启动请求在[RFC3261]第12.1节中描述）。为了实现最有效的测试和故障排除，标记将在对话框的生命周期内持续进行，应用于对话框中的每个请求和响应，并应用不间断的端到端（包括用户设备）。本文件中描述的“log me”标记机制允许不标记部分信令路径，例如，因为端点不支持“log me”标记机制（参见第4.5.2节），或者因为端点或中介故意移除“log me”标记（参见第4.5.2.4节）。此外，标记错误可在对话框结束前终止标记（见第5.3节）。
A UA or intermediary adds a "log me" marker in an unmarked request or response in two cases: first, because it is configured to add the marking to a dialog-creating request, or second, because it has received a dialog-creating request that is being "log me" marked causing it to maintain state to ensure that all requests and responses in the dialog are similarly "log me" marked. Once the "log me" marking is started for a dialog, all subsequent requests and responses in this dialog are "log me" marked. Marking is stopped when this dialog and its related dialogs end. It is considered an error (see Section 5.1.2) if "log me" marking is started in a mid-dialog request or response.
UA或中介在两种情况下在未标记的请求或响应中添加“log me”标记：第一种是因为它被配置为将标记添加到对话框创建请求中，第二种是因为它收到了正在“log me”的对话框创建请求标记使其保持状态，以确保对话框中的所有请求和响应都具有类似的“log me”标记。启动对话框的“记录我”标记后，此对话框中的所有后续请求和响应都将被标记为“记录我”。此对话框及其相关对话框结束时，标记停止。如果在mid对话框请求或响应中启动“记录我”标记，则视为错误（见第5.1.2节）。
For the first case, "log me" marking trigger condition configurations that define whether a UA or intermediary can initiate "log me" marking for a given dialog are out of scope of this document. As an example of trigger condition configurations, the UA or intermediary could be configured to add a "log me" marker for all dialogs initiated during a specific time period (e.g., 9:00 am - 10:00 am every day) or for specific dialogs that have a particular "User-Agent" header field value. They could also be configured to add a "log me" marker for a specific set of called party numbers for which users are experiencing call setup failures.
对于第一种情况，定义UA或中介机构是否可以为给定对话框启动“log me”标记的“log me”标记触发条件配置超出了本文档的范围。作为触发条件配置的一个示例，UA或中介可配置为为在特定时间段（例如，每天上午9:00-上午10:00）内启动的所有对话框或具有特定“用户代理”标题字段值的特定对话框添加“log me”标记。它们还可以配置为为用户遇到呼叫设置失败的一组特定被叫方号码添加“log me”标记。
For the second case of a UA or intermediary detecting that a dialog-initiating request is being "log me" marked, the scope of such marking extends to the lifetime of the dialog. In addition, as discussed in Section 3.7, "log me" marked dialogs that create related dialogs (e.g., REFER) may transfer the marking to the related dialogs. In such cases, the entire "session", identified by the Session-ID header field, is "log me" marked.
对于UA或中介检测到发起请求的对话正在被标记为“log me”的第二种情况，这种标记的范围扩展到对话的生存期。此外，如第3.7节所述，创建相关对话框（如REFER）的“记录我”标记对话框可能会将标记转移到相关对话框。在这种情况下，由会话ID头字段标识的整个“会话”被标记为“log me”。
The local Universally Unique Identifier (UUID) portion of the Session-ID header field value [RFC7989] in the initial SIP request of a dialog is used as a random test case identifier (described in REQ 5 in [RFC8123]). This provides the ability to collate all logged SIP requests and responses to the initial SIP request in a dialog or standalone transaction.
对话框初始SIP请求中会话ID头字段值[RFC7989]的本地通用唯一标识符（UUID）部分用作随机测试用例标识符（如[RFC8123]中的REQ 5所述）。这提供了在对话框或独立事务中整理所有记录的SIP请求和对初始SIP请求的响应的能力。
When a user device inserts the "log me" marker, the marker MUST be passed unchanged in the Session-ID header field across an edge proxy or a B2BUA adjacent to the user device.
当用户设备插入“log me”标记时，该标记必须在会话ID头字段中原封不动地通过与用户设备相邻的边缘代理或B2BUA传递。
An external network is a peer network connected at a network boundary as defined in [RFC8123].
外部网络是在[RFC8123]中定义的网络边界处连接的对等网络。
External networks may be connected directly or via a peering network, and such networks often have specific connection agreements. Whether "log me" marking is removed depends on the policy applied at the network-to-network interface. Troubleshooting and testing will be easier if peer networks endeavor to make agreements to pass "log me" marking unchanged. However, since a "log me" marker may cause a SIP entity to log the SIP header and body of a request or response, the "log me" marker MUST be removed at a network boundary if no agreement exists between peer networks.
外部网络可以直接连接或通过对等网络连接，此类网络通常具有特定的连接协议。是否删除“log me”标记取决于网络到网络接口上应用的策略。如果对等网络努力使通过“log me”标记的协议保持不变，则故障排除和测试将更容易。然而，由于“log me”标记可能导致SIP实体记录请求或响应的SIP头和主体，因此如果对等网络之间不存在协议，则必须在网络边界处删除“log me”标记。
"Log me" marking is most effective if passed end to end. However, intermediaries that do not comply with this document might pass the "log me" marker unchanged or even drop it entirely.
“记录我”标记在端到端传递时最有效。但是，不遵守此文档的中介机构可能会原封不动地传递“log me”标记，甚至完全放弃它。
Multiple SIP dialogs can be simultaneously logged by an originating UA, terminating UA, and SIP entities on the signaling path. These dialogs are differentiated by their test case identifier (the local UUID portion of the Session-ID header field value at the originating device).
发起UA、终止UA和信令路径上的SIP实体可以同时记录多个SIP对话框。这些对话框通过它们的测试用例标识符（原始设备上会话ID头字段值的本地UUID部分）来区分。
The entire SIP message (SIP request line, response line, header fields, and message body) SHOULD be logged since troubleshooting might be difficult if information is missing. Logging SHOULD use common standard formats such as SIP Common Log Format (CLF) defined in [RFC6873] and Libpcap as defined in "vnd.tcpdump.pcap" in the Media Types registry [MEDIA-TYPES]. If SIP CLF is used, the entire message is logged using Vendor-ID = 00000000 and Tag = 02 in the <OptionalFields> portion of the SIP CLF record (see Section 4.4 of [RFC6873]). Header fields SHOULD be logged in the form in which they appear in the message; they SHOULD NOT be converted between long and compact forms described in Section 7.3.3 of [RFC3261].
应记录整个SIP消息（SIP请求行、响应行、头字段和消息正文），因为如果信息丢失，则可能很难进行故障排除。日志记录应使用公共标准格式，如[RFC6873]中定义的SIP公共日志格式（CLF）和媒体类型注册表[Media-Types]中“vnd.tcpdump.pcap”中定义的Libpcap。如果使用SIP CLF，则在SIP CLF记录的<OptionalFields>部分（参见[RFC6873]第4.4节），使用供应商ID=00000000和Tag=02记录整个消息。标题字段应以其在消息中出现的形式记录；不得在[RFC3261]第7.3.3节所述的长形和紧凑形之间转换。
"Log me" marking is done per dialog; typically, it begins at dialog creation and ends when the dialog ends. However, dialogs related to a "log me" marked dialog MAY also be "log me" marked for call control features such as call forward, transfer, park, and join. As described in Section 6 of [RFC7989], related dialogs can occur when an endpoint receives a 3xx message, a REFER that directs the endpoint to a different peer, an INVITE request with Replaces that also potentially results in communicating with a new peer, or an INVITE with a Join header field as described in [RFC3911]. An example is the call transfer feature described in Section 6.1 of [RFC5589]. The logged signaling for related dialogs can be correlated using Session-ID header field values as described in Section 10.9 of [RFC7989].
每个对话框都进行“记录我”标记；通常，它在对话框创建时开始，在对话框结束时结束。但是，与标记为“log me”的对话框相关的对话框也可能标记为“log me”，用于呼叫控制功能，如呼叫转接、转接、驻车和加入。如[RFC7989]第6节所述，当端点接收到3xx消息、将端点指向不同对等方的引用、具有替换的INVITE请求（也可能导致与新对等方通信）或具有加入标头字段的INVITE（如[RFC3911]所述）时，可能会出现相关对话框。[RFC5589]第6.1节中描述的呼叫转移功能就是一个例子。可使用[RFC7989]第10.9节中所述的会话ID头字段值关联相关对话框的记录信令。
In the example shown in Figure 2, Alice has reported problems making call transfers. Her terminal is placed in debug mode in preparation for "log me" marked signaling from the network administrator, Bob. Bob's terminal is configured to "log me" mark and log signaling for calls originated during the troubleshooting session (e.g., for a duration of 15 minutes). Bob, who is troubleshooting the problem, arranges to make a call that Alice can attempt to transfer. Bob calls Alice, which creates initial dialog1, and then Alice transfers the call to connect Bob to Carol. Logged signaling is correlated using the test case identifier, which is the local UUID ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of INVITE request F1. Logging by Alice's terminal begins when it receives and echoes the "log me" marker in INVITE F1 and ends when the last request or response in the dialog is sent or received (200 OK F7 of dialog1). Also during dialog1, Alice's terminal logs related REFER dialog2, which it initiates and terminates as part of the call transfer. Alice's terminal inserts a "log me" marker in the REFER request and 200 OK responses to NOTIFY requests in dialog2. Both dialog1 and dialog2 have the same test case identifier.
在图2所示的示例中，Alice报告了呼叫转接时出现的问题。她的终端处于调试模式，以准备网络管理员Bob发出标记为“log me”的信令。Bob的终端配置为“记录我”标记并记录故障排除会话期间发起的呼叫的信令（例如，持续15分钟）。鲍勃正在排除故障，他安排了一个电话，爱丽丝可以尝试转接。Bob调用Alice，Alice创建初始对话框1，然后Alice将调用转移到Bob和Carol之间。记录的信令使用测试用例标识符进行关联，该标识符是INVITE请求F1的会话ID头字段中的本地UUID ab30317f1a784dc48ff824d0d3715d86。Alice的终端在接收并回显INVITE F1中的“log me”标记时开始记录，在发送或接收对话框中的最后一个请求或响应时结束（dialog1的200 OK F7）。同样在dialog1期间，Alice的终端日志引用dialog2，它作为呼叫转移的一部分启动和终止dialog2。Alice的终端在REFER请求和200个OK响应中插入一个“log me”标记，以通知dialog2中的请求。dialog1和dialog2都具有相同的测试用例标识符。
Logging by Bob's terminal begins when it sends INVITE F1, which includes the "log me" marker, and ends when dialog3, initiated by Bob, ends. Logging by Carol's terminal begins when it receives the INVITE F5 with the "log me" marker and ends when dialog3 ends.
Bob的终端在发送INVITE F1（包括“log me”标记）时开始记录，在Bob启动的dialog3结束时结束记录。Carol的终端在收到带有“log me”标记的邀请F5时开始记录，在dialog3结束时结束。
dialog3 is not logged by Alice's terminal; however, the test case identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case identifier (local-uuid) in INVITE F5. Also, the test case identifier of dialog2, which is logged by Alice's terminal, can be linked to dialog1 and dialog3 because the remote-uuid component of dialog2 is the test case identifier ab30317f1a784dc48ff824d0d3715d86.
Alice的终端没有记录dialog3；然而，测试用例标识符ab30317f1a784dc48ff824d0d3715d86也是INVITE F5中的测试用例标识符（本地uuid）。此外，Alice终端记录的dialog2的测试用例标识符可以链接到dialog1和dialog3，因为dialog2的远程uuid组件是测试用例标识符ab30317f1a784dc48ff824d0d3715d86。
Alice Bob Carol
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 200 OK | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK F7 | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|
Alice Bob Carol
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 200 OK | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK F7 | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|
Figure 2: "Log Me" Marking Related Dialogs in Call Transfer
图2：“记录我”标记呼叫转移中的相关对话框
F1: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog1.
F1:Bob的UA在创建dialog1的INVITE请求的会话ID头字段中插入“logme”参数。
F3: Alice's UA inserts the "logme" parameter in the Session-ID header field of the REFER request that creates dialog2, which is related to dialog1.
F3:Alice的UA在创建dialog2的REFER请求的会话ID头字段中插入“logme”参数，该请求与dialog1相关。
F5: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog3, which is related to dialog1.
F5:Bob的UA在创建dialog3（与dialog1相关）的INVITE请求的会话ID头字段中插入“logme”参数。
F1 INVITE Transferee -> Transferor
F1邀请受让人->转让人
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200正常转让人->受让人
SIP/2.0 200 OK
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
SIP/2.0 200 OK
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
F3参见转让人->受让人
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
F4通知受让人->转让人
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
F5 INVITE Transferee -> Transfer Target
F5邀请受让人->转让目标
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
F6通知受让人->转让人
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
A SIP intermediary is required to copy the "log me" marker into forked requests. SIP request forking is discussed in Sections 4 and 16.6 of [RFC3261].
需要SIP中介将“log me”标记复制到分叉请求中。[RFC3261]的第4节和第16.6节讨论了SIP请求分叉。
"Log me" marking is intended to be limited, in time period and number of dialogs marked, to the minimum needed to troubleshoot a particular problem or perform a particular test.
“Log me”标记旨在将标记的对话框的时间段和数量限制在排除特定问题或执行特定测试所需的最低限度。
o SIP entities MUST be configured to "log me" mark only dialogs needed for the current testing purpose, e.g., troubleshooting or regression testing. The mechanisms in this section ensure that "log me" marking begins at dialog creation and, other than cases of marking related dialogs or premature ending, ends when the dialog being "log me" marked ends.
o SIP实体必须配置为“log me”标记当前测试目的所需的对话框，例如故障排除或回归测试。本节中的机制确保“log me”标记从对话框创建时开始，除了标记相关对话框或过早结束外，在标记为“log me”的对话框结束时结束。
o If a dialog is to be marked, the only way to initiate "log me" marking is at the dialog-creating request (e.g., SIP INVITE) sent by an originating endpoint or an intermediary that marks on behalf of the originating endpoint. Marking that appears mid-dialog is an error as described in Section 5.1.2. The final terminating endpoint, or intermediary that marks on behalf of the terminating endpoint, cannot initiate marking, but it takes action as defined in Sections 4.2 and 4.3 if it receives an incoming "log me" marker.
o 如果要标记对话框，启动“log me”标记的唯一方法是在发起端点或代表发起端点进行标记的中介发送的对话框创建请求（例如，SIP INVITE）处。如第5.1.2节所述，在对话框中间出现的标记是一个错误。最终终止端点或代表终止端点进行标记的中介无法启动标记，但如果接收到传入的“log me”标记，它将采取第4.2节和第4.3节中定义的操作。
Note that the error cases described in Section 5.1 cause SIP entities to stop "log me" marking, and the requirements in Section 7 also place requirements on SIP entities, including allowing SIP entities to not log signaling based on local policies (see Section 8.6).
注意，第5.1节中描述的错误情况导致SIP实体停止“记录我”标记，第7节中的要求也对SIP实体提出了要求，包括允许SIP实体不根据本地策略记录信令（参见第8.6节）。
A common scenario is to have both originating and terminating endpoints support "log me" marking with the originating endpoint configured to initiate "log me" marking. In this simplest use case, the originating UA inserts a "log me" marker in the dialog-creating SIP request and all subsequent SIP requests within that dialog. The "log me" marker is passed through the SIP intermediaries and arrives at the terminating UA, which echoes the "log me" marker in the corresponding responses. If the terminating UA sends an in-dialog request on a dialog that is being "log me" marked, it inserts a "log me" marker and the originating UA echoes the "log me" marker in
一种常见的场景是，发起端点和终止端点都支持“log me”标记，发起端点配置为启动“log me”标记。在这个最简单的用例中，发起UA在创建SIP请求和该对话框中所有后续SIP请求的对话框中插入一个“log me”标记。“log me”标记通过SIP中介传递并到达终止UA，该UA在相应响应中回显“log me”标记。如果终止UA在标记为“log me”的对话框上发送in-dialog请求，它将插入一个“log me”标记，并且发起UA将“log me”标记回显in
responses. The terminating UA logs the "log me" marked SIP requests and responses if it is allowed as per policy defined in the terminating network. This basic use case suggests the following rules for originating and terminating UAs.
响应。如果根据终止网络中定义的策略允许，则终止UA记录标记为SIP请求和响应的“log me”。这个基本用例为UAs的发起和终止建议了以下规则。
For originating UAs:
对于始发无人机：
o The originating UA configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests.
o 为“log me”标记配置的原始UA必须将“log me”标记插入创建SIP请求和后续对话内SIP请求的对话框中。
o The originating UA itself logs marked requests and responses.
o 发起UA本身记录标记的请求和响应。
o The originating UA echoes, in responses, the "log me" marker received in in-dialog requests from the terminating side.
o 作为响应，发起UA回显在来自终止端的对话请求中接收的“log me”标记。
o The originating UA logs the SIP responses that it sends in response to received "log me" marked in-dialog requests.
o 发起UA记录其发送的SIP响应，以响应对话框请求中标记的接收到的“log me”。
o The originating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 如第3.7节所述，发起UA还可将这些规则应用于任何后续相关SIP对话框。
For terminating UAs:
对于终止UAs：
o The terminating UA detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request.
o 终止的UA通过在创建SIP请求的传入对话框中存在“log me”标记来检测对日志记录感兴趣的对话框。
o The terminating UA itself logs marked requests and corresponding marked responses if allowed as per policy.
o 如果策略允许，终止UA本身会记录标记的请求和相应的标记响应。
o The terminating UA MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker.
o 终止UA必须回显“log me”标记，以响应包含“log me”标记的SIP请求。
o If the terminating UA has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests that it sends.
o 如果终止UA检测到对话框正在被标记为“log me”，则必须在其发送的任何in-dialog SIP请求中插入“log me”标记。
o The terminating UA itself logs any in-dialog SIP requests that it sends if allowed as per policy.
o 如果策略允许，终止UA本身将记录其发送的任何会话SIP请求。
o The terminating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 终止UA也可将这些规则应用于第3.7节所述的任何后续相关SIP对话框。
A network operator may know that some of the UAs connected to the network do not support "log me" marking. Subject to the authorizations in Section 7.1, a SIP intermediary close to the UA (e.g., edge proxy, B2BUA) on the originating and/or terminating sides inserts the "log me" marker instead in order to test sessions involving such UAs.
网络运营商可能知道，一些连接到网络的UAs不支持“log me”标记。根据第7.1节中的授权，发起和/或终止侧UA附近的SIP中间人（例如边缘代理、B2BUA）插入“log me”标记，以测试涉及此类UAs的会话。
The originating and terminating SIP intermediaries are not identified by protocol means but are designated and explicitly configured by the network administrator to "log me" mark on behalf of endpoints. The intermediaries that are known to be closest to the terminals can be configured to "log me" mark on behalf of terminals that do not support "log me" marking. The originating SIP intermediary is the first one to be traversed by a SIP request sent by the originating endpoint. Similarly, the terminating SIP intermediary is the last intermediary traversed before the terminating endpoint is reached.
发起和终止SIP中介体不通过协议手段识别，而是由网络管理员指定并明确配置为代表端点的“logme”标记。已知最接近终端的中介可以被配置为代表不支持“logme”标记的终端进行“logme”标记。发起SIP中介是由发起端点发送的SIP请求要遍历的第一个中介。类似地，终止SIP中介是到达终止端点之前经过的最后一个中介。
The SIP intermediary at the originating side is configured to insert the "log me" marker on behalf of the originating endpoint. If the terminating UA does not echo the "log me" marker in responses to a marked request, then the SIP intermediary closest to the terminating UA, if configured to mark on behalf of the terminating UA, inserts a "log me" marker in responses to the request. Likewise, if the terminating UA sends an in-dialog request, the SIP intermediary at the terminating side inserts a "log me" marker and the SIP intermediary at the originating side echoes the "log me" marker in responses to that request. Originating and terminating intermediaries that are configured for "log me" marking on behalf of the endpoint must also mark dialog-creating requests that contain Target-Dialog [RFC4538], Join [RFC3911], and Replaces [RFC3891] header fields and corresponding responses. The SIP intermediaries at the originating and terminating sides log the "log me" marked SIP requests and responses if it is allowed as per policy defined in the originating and terminating networks. This scenario suggests the following rules when a SIP intermediary is configured to initiate or handle "log me" marking on behalf of a UA.
发起端的SIP中介被配置为代表发起端点插入“logme”标记。如果终止UA在响应已标记的请求时不回显“log me”标记，则距离终止UA最近的SIP中介（如果配置为代表终止UA进行标记）将在响应请求时插入“log me”标记。类似地，如果终止UA发送in-dialog请求，则终止侧的SIP中介插入“log-me”标记，并且发起侧的SIP中介响应该请求回显“log-me”标记。代表端点配置为“log me”标记的发起和终止中介体还必须标记包含目标对话框[RFC4538]、加入[RFC3911]并替换[RFC3891]头字段和相应响应的对话框创建请求。如果根据发起和终止网络中定义的策略允许，则发起和终止侧的SIP中介将标记为“log me”的SIP请求和响应记录下来。当SIP中介配置为代表UA启动或处理“log me”标记时，此场景建议使用以下规则。
For the originating SIP intermediary:
对于发起SIP中介：
o The originating SIP intermediary configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests.
o 为“log me”标记配置的原始SIP中介必须将“log me”标记插入到创建SIP请求和后续对话内SIP请求的对话框中。
o The originating SIP intermediary itself logs marked requests and responses.
o 发起SIP中介本身记录标记的请求和响应。
o The originating SIP intermediary detects the "log me" marker received in in-dialog requests and echoes the "log me" marker in the corresponding SIP responses.
o 发起SIP中介检测对话请求中接收到的“log me”标记，并在相应的SIP响应中回显“log me”标记。
o The originating SIP intermediary logs the SIP responses that it sends in response to "log me" marked in-dialog requests.
o 发起的SIP中介记录它发送的SIP响应，以响应对话框请求中标记的“log me”。
o The originating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 如第3.7节所述，发起SIP中介还可将这些规则应用于任何后续相关SIP对话框。
For the terminating SIP intermediary:
对于终止SIP中介：
o The terminating SIP intermediary detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request.
o 终止SIP中介通过在创建SIP请求的传入对话框中存在“log me”标记来检测对日志记录感兴趣的对话框。
o The terminating SIP intermediary itself logs marked requests and corresponding responses if allowed as per policy.
o 如果策略允许，终止SIP中介本身会记录标记的请求和相应的响应。
o The terminating SIP intermediary MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker.
o 终止SIP中介必须回显“log me”标记，以响应包含“log me”标记的SIP请求。
o If the terminating SIP intermediary has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests from the terminating UA.
o 如果终止的SIP中介检测到一个对话框正在被“log me”标记，它必须在来自终止UA的任何对话内SIP请求中插入一个“log me”标记。
o The terminating SIP intermediary itself logs any in-dialog SIP requests that it sends if allowed as per policy.
o 如果策略允许，终止SIP中介本身会记录它发送的任何对话SIP请求。
o The terminating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7.
o 终止SIP中介还可以将这些规则应用于第3.7节所述的任何后续相关SIP对话框。
B2BUA "log me" behavior is specified based on its different signaling plane roles described in [RFC7092].
B2BUA“log me”行为是根据[RFC7092]中描述的不同信令平面角色指定的。
A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses from its terminating side to the originating side without needing explicit configuration to do so.
代理B2BUA应该将请求和响应中的“log me”标记从其终止端复制到发起端，而无需进行显式配置。
A dialog on one "side" of the B2BUA may or may not be coupled to a related dialog on the other "side" for "log me" purposes. To allow end-to-end troubleshooting of user problems and regression testing, a signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] SHOULD couple related dialogs for "log me" marking purposes and pass on the received "log me" parameter from the originating side to the terminating side and vice versa. For example, a SIP B2BUA handling
出于“记录我”的目的，B2BUA的一个“侧”上的对话框可以或可以不耦合到另一个“侧”上的相关对话框。为了允许对用户问题和回归测试进行端到端故障排除，仅信令和SDP修改仅信令B2BUA[RFC7092]应耦合相关对话框以进行“日志我”标记，并将接收到的“日志我”参数从发起端传递到终止端，反之亦然。例如，SIP B2BUA处理
an end-to-end session between an external caller and an agent in a contact center environment can couple the dialog between itself and an agent with the dialog between itself and the external caller. It can pass on the "log me" marking from the originating side to the terminating side to enable end-to-end logging of specific sessions of interest.
在呼叫中心环境中，外部呼叫方和代理之间的端到端会话可以将自身和代理之间的对话与自身和外部呼叫方之间的对话耦合起来。它可以将“log me”标记从发起端传递到终止端，以实现感兴趣的特定会话的端到端日志记录。
For dialogs that are being "log me" marked, all B2BUAs MUST "log me" mark in-dialog SIP requests that they generate on their own, without needing explicit configuration to do so. This rule applies to both the originating and terminating sides of a B2BUA.
对于标记为“log me”的对话框，所有B2BUA都必须在自己生成的对话框SIP请求中标记为“log me”，而无需显式配置。本规则适用于B2BUA的始发侧和终止侧。
Typically, "log me" marking will be done by an originating UA and echoed by a terminating UA. SIP intermediaries on the signaling path between these UAs that do not perform the tasks described in Sections 4.3 or 4.4 MUST simply log any request or response that contains a "log me" marker in a stateless manner, if it is allowed per local policy.
通常，“记录我”标记将由发起UA完成，并由终止UA进行回音。不执行第4.3节或第4.4节中所述任务的这些UAs之间的信令路径上的SIP中介必须以无状态方式记录包含“log me”标记的任何请求或响应（如果本地策略允许）。
The originating and terminating SIP intermediaries that "log me" mark on behalf of endpoints and SIP intermediaries that remove "log me" marking at the network boundary must maintain state to enable "log me" marking. Applicable scenarios are as follows:
代表端点进行“log me”标记的发起和终止SIP中介体以及在网络边界移除“log me”标记的SIP中介体必须保持启用“log me”标记的状态。适用场景如下：
o The originating UA does not support "log me" marking. This scenario was described in Section 4.3 and requires support by the originating SIP intermediary. "Log me" marker processing is illustrated in Section 4.5.2.1.
o 发起UA不支持“记录me”标记。该场景在第4.3节中描述，需要原始SIP中介的支持。“记录me”标记处理如第4.5.2.1节所示。
o The terminating UA does not support "log me" marking. This scenario was described in Section 4.3 and requires support by the terminating SIP intermediary. "Log me" marker processing is illustrated in Section 4.5.2.2.
o 终止UA不支持“记录me”标记。该场景在第4.3节中描述，需要终止SIP中介的支持。第4.5.2.2节说明了“记录me”标记处理。
o The originating network ensures that it does not pass marking outside its boundaries in order to not impact any external networks. The originating network removes "log me" marking from SIP requests and responses before forwarding them from its network boundary to external networks, but it adds marking back to any incoming SIP requests and responses belonging to any "log me"
o 发起网络确保不会通过其边界外的标记，以免影响任何外部网络。在将SIP请求和响应从其网络边界转发到外部网络之前，发起网络将从SIP请求和响应中删除“log me”标记，但它将标记添加回属于任何“log me”的任何传入SIP请求和响应
marked dialog. This scenario requires support by the SIP intermediary at the originating network boundary. "Log me" marker processing is illustrated in Section 4.5.2.3.
标记的对话框。此场景需要SIP中介在原始网络边界处提供支持。“记录me”标记处理如第4.5.2.3节所示。
o The terminating network ensures that it does not allow "log me" marking from external networks to pass through its boundary to its internal entities. The terminating network removes "log me" marking from SIP requests and responses before forwarding them internally, but it adds marking back to any outgoing SIP requests and responses belonging to any "log me" marked dialog. This scenario requires support by the SIP intermediary at the terminating network boundary. "Log me" marker processing is illustrated in Section 4.5.2.4.
o 端接网络确保不允许外部网络的“log me”标记通过其边界到达其内部实体。在内部转发SIP请求和响应之前，终止网络将从SIP请求和响应中删除“log me”标记，但它将标记添加回属于任何“log me”标记对话框的任何传出SIP请求和响应。此场景需要终端网络边界处的SIP中介支持。“记录me”标记处理如第4.5.2.4节所示。
o The terminating network does not support "log me" marking and does not echo marking that it receives. The originating network adds marking back to any incoming SIP requests and responses belonging to the "log me" marked dialog. This scenario requires support by the SIP intermediary at the originating network boundary and "log me" marker processing is illustrated in Section 4.5.2.5.
o 终端网络不支持“log me”标记，也不回显它接收到的标记。发起网络将标记添加回属于标记为“log me”的对话框的任何传入SIP请求和响应。该场景需要SIP中介在发起网络边界处提供支持，“log me”标记处理如第4.5.2.5节所示。
SIP intermediary behavior in these scenarios is illustrated using [RFC3665] example call flow "Session Establishment Through Two Proxies".
这些场景中的SIP中介行为使用[RFC3665]示例调用流“通过两个代理建立会话”进行说明。
Alice's UA does not support "log me" marking; hence, Proxy 1, which is the SIP intermediary closest to Alice, is configured to act on behalf of Alice's UA to "log me" mark specific dialogs of interest that are created by Alice for troubleshooting purposes.
Alice的UA不支持“记录我”标记；因此，最接近Alice的SIP中介代理1被配置为代表Alice的UA“记录我”标记Alice为故障排除目的创建的感兴趣的特定对话框。
In Figure 3, Proxy 1 in the originating network maintains state of which dialogs are being logged in order to "log me" mark all SIP requests and responses that it receives from Alice's UA before forwarding them to Proxy 2.
在图3中，发起网络中的代理1维护正在记录对话框的状态，以便在将它们转发到代理2之前“记录我”标记它从Alice的UA收到的所有SIP请求和响应。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | INVITE F4 |
| (logme) | | (logme) |
|<---------------| 100 F5 |--------------->|
| | (logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (logme) |
| | 180 F7 |<---------------|
| | (logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (logme) |
| | 200 F10 |<---------------|
| | (logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (no logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | INVITE F4 |
| (logme) | | (logme) |
|<---------------| 100 F5 |--------------->|
| | (logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (logme) |
| | 180 F7 |<---------------|
| | (logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (logme) |
| | 200 F10 |<---------------|
| | (logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (no logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (logme) |
| | BYE F16 |<---------------|
| | (logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (no logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (logme) |
| | |--------------->|
| | | |
| | | BYE F15 |
| | | (logme) |
| | BYE F16 |<---------------|
| | (logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (no logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (logme) |
| | |--------------->|
| | | |
Figure 3: The Originating UA Does Not Support "Log Me" Marking
图3：发起UA不支持“Log Me”标记
F1: Alice's UA does not insert a "log me" marker in the dialog-creating INVITE request F1. Nevertheless, Proxy 1 is configured to initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 and maintains state that this dialog is being logged.
F1:Alice的UA不会在创建邀请请求F1的对话框中插入“log me”标记。然而，代理1被配置为代表Alice启动日志记录。代理1记录INVITE请求F1并保持此对话框正在记录的状态。
F2: Proxy 1 inserts a "log me" marker in INVITE request F2 before forwarding it to Proxy 2. Proxy 1 logs this request.
F2：代理1在将其转发到代理2之前，在邀请请求F2中插入“log me”标记。代理1记录此请求。
F3: Proxy 1 inserts a "log me" marker in 100 response F3 before forwarding it to Alice's UA since this is a response sent on a dialog that is being "log me" marked. Proxy 1 logs this response.
F3:Proxy 1在100响应F3中插入“log me”标记，然后将其转发给Alice的UA，因为这是在标记为“log me”的对话框上发送的响应。代理1记录此响应。
F4: "Bob's UA detects the "log me" marker and logs the INVITE request F4 if allowed as per policy.
F4:“Bob的UA检测到“log me”标记，并根据策略记录邀请请求F4（如果允许）。
F6: Bob's UA echoes the "log me" marker in INVITE request F4 into 180 response F6. It logs this response if allowed as per policy.
F6:Bob的UA将INVITE请求F4中的“log me”标记回显到180响应F6中。如果策略允许，它将记录此响应。
F7 and F8: Proxy 1 logs the received "180" response F7 and passes the "log me" marker to Alice's UA in F8.
F7和F8:Proxy 1记录收到的“180”响应F7，并在F8中将“log me”标记传递给Alice的UA。
F12: Proxy 1 receives ACK with no "log me" marker. It doesn't consider this an error since it is configured to "log me" mark on behalf of Alice's UA.
F12:代理1接收没有“log me”标记的ACK。它不认为这是一个错误，因为它被配置为“登录我”代表爱丽丝的UA标记。
F13: Proxy 1 inserts a "log me" marker in ACK request F13 before forwarding it to Proxy 2. Proxy 1 logs this request.
F13:代理1在ACK请求F13中插入“log me”标记，然后将其转发给代理2。代理1记录此请求。
F15: Bob's UA inserts a "log me" marker in the in-dialog BYE request and this "log me" marker is carried back to Alice's UA in F16 and F17. Bob's UA logs this request if allowed as per policy.
F15:Bob的UA在in对话框BYE请求中插入一个“log me”标记，该“log me”标记在F16和F17中带回Alice的UA。如果政策允许，Bob的UA将记录此请求。
F18: Alice's UA does not echo the "log me" marker from BYE request F17 into 200 response F18.
F18:Alice的UA不会将BYE请求F17中的“log me”标记回显到200响应F18中。
F19: Proxy 1 inserts a "log me" marker in 200 response F19 before forwarding it to Proxy 2. Proxy 1 logs this response.
F19:代理1在200响应F19中插入“log me”标记，然后将其转发给代理2。代理1记录此响应。
In Figure 4, Bob's UA does not support "log me" marking, so Proxy 2 in the terminating network maintains state to ensure "log me" marking of SIP requests and responses from Bob's UA.
在图4中，Bob的UA不支持“log me”标记，因此终止网络中的代理2保持状态，以确保对来自Bob的UA的SIP请求和响应进行“log me”标记。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | | |
| | | |
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | | |
| | | |
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
Figure 4: The Terminating UA Does Not Support "Log Me" Marking.
图4：终止UA不支持“Log Me”标记。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1.
F1:Alice的UA在创建邀请请求F1的对话框中插入“log me”标记。
F2: INVITE F2 is "log me" marked; therefore, Proxy 2 maintains state that this dialog is to be logged. Proxy 2 logs the request and responses of this dialog if allowed per policy.
F2:INVITE F2标记为“记录我”；因此，代理2保持该对话框将被记录的状态。如果每个策略允许，代理2将记录此对话框的请求和响应。
F5: Proxy 2 inserts a "log me" marker in the 100 response it sends to Proxy 1.
F5:代理2在发送给代理1的100响应中插入“log me”标记。
F6: Bob's UA does not support "log me" marking; therefore, the 180 response to the INVITE request doesn't have a "log me" marker.
F6:Bob的UA不支持“记录我”标记；因此，对INVITE请求的180响应没有“log me”标记。
F7: Proxy 2 inserts a "log me" marker in the 180 response on behalf of Bob's UA before forwarding it. The same applies to response F10 and the BYE request in F16.
F7:Proxy 2在转发前代表Bob的UA在180响应中插入“log me”标记。这同样适用于F10响应和F16中的BYE请求。
If network A in Figure 5 is performing testing independently of network B, then network A removes "log me" marking from SIP requests and responses forwarded to network B to prevent triggering unintended logging in network B. Proxy 1 removes "log me" marking from requests and responses that it forwards to Proxy 2 and maintains state of which dialogs are being "log me" marked in order to "log me" mark requests and responses that it forwards from Proxy 2 to Alice's UA. For troubleshooting purposes, Proxy 1 MAY also log the requests and responses sent to or received from Proxy 2 even though it removed "log me" marker prior to forwarding the messages to Proxy 2.
如果图5中的网络A独立于网络B执行测试，则网络A从转发到网络B的SIP请求和响应中删除“log me”标记，以防止触发网络B中的意外登录。代理1删除“log me”标记从请求和响应转发到代理2，并保持对话框被标记为“log me”的状态，以便“log me”标记从代理2转发到Alice UA的请求和响应。出于故障排除目的，代理1还可以记录发送到代理2或从代理2接收到的请求和响应，即使它在将消息转发到代理2之前删除了“log me”标记。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (logme) | | INVITE F4 |
| | | (no logme) |
|<---------------| 100 F5 |--------------->|
| | (no logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (no logme) |
| | 180 F7 |<---------------|
| | (no logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (no logme) |
| | 200 F10 |<---------------|
| | (no logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (no logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (logme) | | INVITE F4 |
| | | (no logme) |
|<---------------| 100 F5 |--------------->|
| | (no logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (no logme) |
| | 180 F7 |<---------------|
| | (no logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (no logme) |
| | 200 F10 |<---------------|
| | (no logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (no logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no logme) |
| | BYE F16 |<---------------|
| | (no logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (no logme) |
| | |--------------->|
| | | |
| | | BYE F15 |
| | | (no logme) |
| | BYE F16 |<---------------|
| | (no logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (no logme) |
| | |--------------->|
| | | |
Figure 5: The Originating Network Removes "Log Me" Marking from Outgoing SIP Messages at its Network Edge.
图5：发起网络从其网络边缘的传出SIP消息中删除“Log Me”标记。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request, and Proxy 1 therefore maintains state that this dialog is to be logged.
F1:Alice的UA在创建INVITE请求的对话框中插入一个“log me”标记，因此代理1保持该对话框将被记录的状态。
F2: Proxy 1 removes "log me" marking from INVITE request before forwarding it to Proxy 2. Proxy 1 logs INVITE request F2.
F2:在将邀请请求转发到代理2之前，代理1会从邀请请求中删除“log me”标记。代理1记录邀请请求F2。
F3: Proxy 1 inserts a "log me" marker in the 100 response sent to Alice's UA. Proxy 1 logs this response.
F3:Proxy 1在发送给Alice的UA的100响应中插入“log me”标记。代理1记录此响应。
F8: Proxy 1 inserts a "log me" marker in the 180 response before forwarding it to Alice's UA. Proxy 1 logs this response. The same applies to responses F11 and F17.
F8:Proxy 1在180响应中插入“log me”标记，然后将其转发给Alice的UA。代理1记录此响应。这同样适用于回答F11和F17。
F13: Proxy 1 removes "log me" marking from the ACK request. Proxy 1 logs this request before forwarding it to Proxy 2.
F13:代理1从ACK请求中删除“log me”标记。代理1记录此请求，然后将其转发给代理2。
F19: Proxy 1 removes "log me" marking from the 200 response of the BYE request. Proxy 1 logs this response before forwarding it to Proxy 2.
F19:代理1从BYE请求的200响应中删除“log me”标记。代理1在将此响应转发到代理2之前记录此响应。
In Figure 6, Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. However, Proxy 2 supports maintaining the marking state of the dialog and "log me" marks requests and responses that it sends towards Proxy 1. For troubleshooting purposes, Proxy 2 MAY also log the requests and responses received from or sent to Bob even though it removed the "log me" marker prior to forwarding the messages to Bob. This scenario might be used for troubleshooting a signaling path between two enterprise or carrier networks, or across a transit network, with minimal logging (i.e., only at the network boundaries).
在图6中，代理2从所有进入网络B的SIP请求和响应中删除“log me”标记。但是，代理2支持维护对话框的标记状态，并且“log me”标记它发送到代理1的请求和响应。出于故障排除目的，代理2还可以记录从Bob接收或发送到Bob的请求和响应，即使它在将消息转发给Bob之前删除了“log me”标记。此场景可用于故障排除两个企业或运营商网络之间的信令路径，或跨传输网络的信令路径，且日志记录最少（即，仅在网络边界处）。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (no log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (no log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (no log me) |
| | |--------------->|
| | | |
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (no log me) |
| | |--------------->|
| | | |
Figure 6: The terminating network removes "log me" marking from incoming SIP messages at its network edge.
图6：终止网络从其网络边缘的传入SIP消息中删除“log me”标记。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1. Proxy 1 detects the "log me" marker, logs the request, and maintains state that this dialog is to be logged.
F1:Alice的UA在创建邀请请求F1的对话框中插入“log me”标记。代理1检测“log me”标记，记录请求，并保持此对话框将被记录的状态。
F2: Proxy 2 removes the "log me" marker in the INVITE request F2 before forwarding it as F4. The same applies to responses F13 and F19.
F2：代理2在将其作为F4转发之前，删除邀请请求F2中的“log me”标记。这同样适用于回答F13和F19。
F6: Proxy 2 inserts a "log me" marker in the 180 response to the INVITE request and logs the request before forwarding it as F7. The same applies to response F9 and the BYE request in F15.
F6:Proxy 2在对INVITE请求的180响应中插入“log me”标记，并在将请求作为F7转发之前记录该请求。这同样适用于响应F9和F15中的BYE请求。
In Figure 6, Proxy 2 is not "log me" aware and therefore passes marking in all SIP requests and responses entering network B according to the rules in Sections 16.6 and 16.7 of [RFC3261]. Proxy 2 does not log requests and responses in the dialog. Proxy 1 supports maintaining the marking state of the dialog. When Proxy 1 observes that requests and responses received from Proxy 2 are not marked, it adds the marking.
在图6中，代理2不知道“log me”，因此根据[RFC3261]第16.6节和第16.7节中的规则，在进入网络B的所有SIP请求和响应中通过标记。代理2不会在对话框中记录请求和响应。代理1支持维护对话框的标记状态。当代理1发现从代理2接收的请求和响应没有标记时，它会添加标记。
For troubleshooting purposes, Proxy 1 MAY also log the requests and responses received from or sent to Proxy 2 even though Proxy 2 didn't add "log me" to messages sent to Proxy 1.
出于故障排除的目的，代理1还可以记录从代理2接收或发送到代理2的请求和响应，即使代理2没有将“log me”添加到发送到代理1的消息中。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (no log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (no log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (no log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (no log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (no log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (no log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (no log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (no log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
Figure 7: The Terminating Network Removes "Log Me" Marking from Incoming SIP Messages at its Network Edge.
图7：终止网络从其网络边缘的传入SIP消息中删除“Log Me”标记。
F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request F1. Proxy 1 detects the "log me" marker, logs the request, and maintains state that this dialog is to be logged.
F1:Alice的UA在创建邀请请求F1的对话框中插入“log me”标记。代理1检测“log me”标记，记录请求，并保持此对话框将被记录的状态。
F2: Proxy 2 passes the "log me" marker in the INVITE request F2 before forwarding it as F4. The same applies to request F13 and response F19.
F2：代理2在作为F4转发之前，先在INVITE请求F2中传递“log me”标记。这同样适用于请求F13和响应F19。
F6: Bob's UA does not support "log me" marking and does not echo the "log me" marker in response F6. The same applies to response F9 and the BYE request F15.
F6:Bob的UA不支持“记录我”标记，并且不响应F6中的“记录我”标记。这同样适用于响应F9和BYE请求F15。
F7: Proxy 1 inserts a "log me" marker in the 180 response of the INVITE request before forwarding it as F8. The same applies to response F10 and the BYE request F16.
F7:代理1在INVITE请求的180响应中插入“log me”标记，然后将其作为F8转发。这同样适用于响应F10和BYE请求F16。
The following error cases are possible for "log me" marking:
“记录我”标记可能出现以下错误情况：
1. A "log me" marker is unexpectedly missing from a dialog that is being logged.
1. 正在记录的对话框中意外缺少“log me”标记。
2. A "log me" marker unexpectedly appears in a dialog that is not being logged.
2. “记录我”标记意外出现在未记录的对话框中。
3. A "log me" marker unexpectedly disappears and then reappears in a dialog being logged. This is treated in the same way as case 1.
3. “log me”标记意外消失，然后重新出现在正在记录的对话框中。这与案例1的处理方式相同。
4. A "log me" marker is unexpectedly missing from a retransmission in a dialog being logged. This is treated in the same way as case 1.
4. “log me”标记在正在记录的对话框中的重新传输中意外丢失。这与案例1的处理方式相同。
These cases apply to any request or response sent by any entity and in any direction in a dialog being "log me" marked. Detection of these error cases is described in this section.
这些情况适用于任何实体在标记为“log me”的对话框中以任何方向发送的任何请求或响应。本节介绍了这些错误情况的检测。
Since "log me" marking is per-dialog, if a dialog is being marked and marking is missing from a request or response then this is an error.
由于“log me”标记是针对每个对话框的，如果正在标记对话框，并且请求或响应中缺少标记，则这是一个错误。
However, detecting such errors is not as simple as checking for missing markers because of cases such as non-supporting terminals where it is normal that marking is not done.
然而，检测此类错误并不像检查缺失标记那样简单，因为在非支持终端等情况下，通常不进行标记。
Detecting errors must be evaluated separately for each neighbor. It is an error if a particular neighbor has previously sent "log me" in the dialog and then stops, independently of what has been happening with other neighbors.
必须为每个邻居单独评估检测错误。如果某个特定的邻居之前在对话框中发送了“log me”，然后停止，这是一个错误，与其他邻居的情况无关。
UAs and intermediaries that are stateless with respect to "log me" marking are not able detect such errors. User agents and intermediaries that are stateful with respect to "log me" marking are able to detect that a marker is missing from a dialog that has previously been "log me" marked. Error cases are illustrated in this section, and non-error cases in Section 5.2.1.
在“log me”标记方面无状态的UAs和中介无法检测到此类错误。对于“log me”标记而言是有状态的用户代理和中介能够检测到以前标记为“log me”的对话框中缺少标记。本节说明了错误情况，第5.2.1节说明了非错误情况。
The following figures illustrate missing "log me" marker errors.
下图说明了丢失的“log me”标记错误。
Figure 8 shows an error detected at Proxy 1, where an expected "log me" marker is missing.
图8显示了在代理1上检测到的错误，其中缺少预期的“log me”标记。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | INVITE F2 | |
|--------------->| (log me) | INVITE F3 |
| |--------------->| (log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (log me) |
| 200 F6 | (log me) |<---------------|
| (log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (no log me) |
| | |--------------->|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | INVITE F2 | |
|--------------->| (log me) | INVITE F3 |
| |--------------->| (log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (log me) |
| 200 F6 | (log me) |<---------------|
| (log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (no log me) |
| | |--------------->|
Figure 8: Error Case: Missing "Log Me" Marker
图8：错误案例：缺少“LogMe”标记
F1: Proxy 1 detects the "log me" marker and maintains state that this dialog is to be logged.
F1:Proxy 1检测“log me”标记并保持此对话框将被记录的状态。
F7: Proxy 1 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F7:代理1检测到预期的“log me”标记丢失，将其视为错误，并在此对话框的后续请求和响应中停止“log me”标记。
Figure 9 shows an error detected at both Proxy 2 and Bob's UA.
图9显示了在Proxy 2和Bob的UA上检测到的错误。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (no log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (no log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
Figure 9: Error Case: Missing "Log Me" Marker
图9：错误案例：缺少“LogMe”标记
F2: Proxy 2 detects the "log me" marker and maintains state that this dialog is to be logged.
F2：代理2检测“log me”标记并保持该对话框将被记录的状态。
F4: Bob's UA detects the "log me" marker and maintains state that this dialog is to be logged.
F4:Bob的UA检测到“log me”标记，并保持该对话框将被记录的状态。
F12: Proxy 1 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog. Hence, it does not insert a "log me" marker in F13.
F12:代理1检测到预期的“log me”标记丢失，将其视为错误，并在此对话框中停止后续请求和响应中的“log me”标记。因此，它不会在F13中插入“log me”标记。
F13: Proxy 2 detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F13:代理2检测到预期的“log me”标记丢失，将其视为错误，并在此对话框中停止后续请求和响应中的“log me”标记。
F14: Proxy 2 does not insert a "log me" marker because it has stopped "log me" marking due to an error observed in F13. Bob's UA detects that the expected "log me" marker is missing, considers it to be an error, and stops "log me" marking in subsequent requests and responses in this dialog.
F14:代理2未插入“log me”标记，因为由于在F13中观察到错误，它已停止“log me”标记。Bob的UA检测到预期的“log me”标记丢失，将其视为错误，并在此对话框中停止后续请求和响应中的“log me”标记。
SIP endpoints, intermediaries acting on behalf of endpoints, and B2BUAs that can perform "log me" marking are stateful. Such entities will expect a "log me" marker only for dialogs where the initial dialog-creating request was "log me" marked, either by themselves or by an upstream entity. "Log me" marking that subsequently begins mid-dialog is an error.
SIP端点、代表端点的中介以及可以执行“log me”标记的B2BUA都是有状态的。此类实体将仅在初始对话框创建请求被自己或上游实体标记为“log me”的对话框中使用“log me”标记。随后在对话框中间开始的“记录我”标记是错误的。
Figure 10 illustrates a "log me" marking error observed in the middle of a dialog. Alice's UA supports "log me" marking but the call is not initially marked for logging, i.e., INVITE F1 is not "log me" marked. But Alice's UA starts to "log me" mark at the ACK request F7. Proxy 1 supports "log me" marking at the originating network boundary and therefore detects the error, does not log signaling, and removes the "log me" marker before forwarding the ACK request F8.
图10示出了在对话框中间观察到的“log me”标记错误。Alice的UA支持“log me”标记，但呼叫最初没有标记为记录，即INVITE F1没有标记为“log me”。但是Alice的UA在ACK请求F7处开始“记录我”标记。代理1支持原始网络边界处的“log me”标记，因此检测错误，不记录信令，并在转发ACK请求F8之前删除“log me”标记。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no log me) | INVITE F2 | |
|--------------->| (no log me) | INVITE F3 |
| |--------------->| (no log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (no log me) |
| 200 F6 | (no log me) |<---------------|
| (no log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (log me) |
| | |--------------->|
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no log me) | INVITE F2 | |
|--------------->| (no log me) | INVITE F3 |
| |--------------->| (no log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (no log me) |
| 200 F6 | (no log me) |<---------------|
| (no log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (log me) |
| | |--------------->|
Figure 10: Error Case: "Log Me" Marker Begins Mid-dialog
图10：错误案例：“LogMe”标记在对话框中开始
The following figure illustrates a non-error case.
下图说明了一种非错误情况。
Figure 11 shows Proxy 2 receiving a response with no "log me" marker that is not an error case. Proxy 2 is configured by network B to perform "log me" marking on behalf of Bob's UA, which does not support "log me" marking. Proxy 2 does not therefore expect responses from Bob to include a "log me" marker.
图11显示了代理2接收不带“log me”标记的响应，这不是错误情况。代理2由网络B配置为代表Bob的UA执行“log me”标记，该UA不支持“log me”标记。因此，Proxy 2不希望Bob的响应包含“log me”标记。
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| 180 F8 | | |
| (log me) | | |
|<---------------| | |
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| 180 F8 | | |
| (log me) | | |
|<---------------| | |
Figure 11: Non-error Case: Missing "Log Me" Marker
图11：无错误情况：缺少“LogMe”标记
F2: Proxy 2 detects the "log me" marker and maintains state that this dialog is to be logged. Proxy 2 inserts "log me" markers on behalf of Bob's user agent, such as in F7.
F2：代理2检测“log me”标记并保持该对话框将被记录的状态。Proxy 2代表Bob的用户代理插入“log me”标记，如F7。
F6: Proxy 2 detects that the "log me" marker is missing from the response but considers "log me" marking to be ongoing as a marker was not expected.
F6:代理2检测到响应中缺少“log me”标记，但认为“log me”标记正在进行中，因为没有预期标记。
F7: Proxy 2 continues to "log me" mark requests and responses on behalf of Bob's UA.
F7:代理2代表Bob的UA继续“记录我”标记请求和响应。
A SIP intermediary that can perform "log me" marking on behalf of an endpoint MAY optionally mark a request or response towards a non-supporting endpoint, such as the 100 response F3 in Figure 3. In this case, the endpoint will receive a "log me" marker mid-dialog, and this is not considered an error.
可以代表端点执行“log me”标记的SIP中介可以选择性地标记指向非支持端点的请求或响应，如图3中的100响应F3。在这种情况下，端点将收到一个“logme”标记mid对话框，这不被视为错误。
Another use case is a network in which some (but not all) endpoints support "log me" marking and that wants to avoid treating endpoints differently by always managing "log me" marking at a SIP intermediary. In this case, the endpoint that supports "log me" is not configured to mark a dialog; instead, the SIP intermediary is configured to perform "log me" marking on behalf of that endpoint. This case still requires authorization as described in Section 7.1. This SIP intermediary MAY optionally mark a request or response towards the endpoint, such as the 100 response F3 in Figure 3. The endpoint will receive a "log me" marker mid-dialog, which is not considered an error.
另一个用例是一个网络，其中一些（但不是所有）端点支持“log me”标记，并且希望通过始终在SIP中介处管理“log me”标记来避免以不同的方式对待端点。在这种情况下，支持“log me”的端点未配置为标记对话框；相反，SIP中介被配置为代表该端点执行“log me”标记。这种情况仍然需要第7.1节所述的授权。该SIP中介可以选择性地标记指向端点的请求或响应，如图3中的100响应F3。端点将收到一个“log me”标记mid对话框，该对话框不被视为错误。
When troubleshooting call flows that involve the SIP Join header field specified in [RFC3911], the ideal scenario is to have "log me" marking enabled on all UAs and intermediaries participating in the end-to-end session. If the ideal scenario is not feasible, the following rules apply:
当对涉及[RFC3911]中指定的SIP Join header字段的呼叫流进行故障排除时，理想情况是在参与端到端会话的所有UAs和中介上启用“log me”标记。如果理想方案不可行，则适用以下规则：
o If an endpoint or an intermediary that is "log me" aware and is already "log me" marking a dialog receives a SIP INVITE with a Join header field and without a "log me" marker, it MUST NOT "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE.
o 如果端点或具有“日志我”意识且已在“日志我”标记对话框的中介接收到带有连接头字段且没有“日志我”标记的SIP INVITE，则其不得“日志我”标记由于处理SIP INVITE而建立的新对话框内交换的响应和请求。
o If an endpoint or an intermediary that is "log me" aware and is not "log me" marking a dialog receives a SIP INVITE with a Join header field and with a "log me" marker, it MUST "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE as per Section 4 of this document.
o 如果端点或知道“日志我”且未“日志我”标记对话的中介接收到带有连接头字段和“日志我”标记的SIP INVITE，则它必须“日志我”标记在根据本文档第4节处理SIP INVITE后建立的新对话内交换的响应和请求。
The two error types that SIP entities must handle are defined in Section 5.1: a missing marker error and an error of "log me" marking that begins mid-dialog. Section 5.2 gives exceptions that have marking that begins mid-dialog or a missing marker but are not errors.
SIP实体必须处理的两种错误类型在第5.1节中进行了定义：缺少标记错误和从对话框中间开始的“log me”标记错误。第5.2节给出了一些例外情况，这些例外情况具有从对话框中间开始的标记或缺少标记，但不是错误。
If a missing marker error is detected by a UA, SIP intermediary, or B2BUA, it SHOULD consider this to be an error condition in the "log me" functionality. It MUST NOT mark subsequent requests and responses, and it MUST stop logging messages in the same dialog. Any previously logged messages SHOULD be retained, for the time period defined in Section 8.5, and not deleted.
如果UA、SIP中介或B2BUA检测到缺失的标记错误，则应该认为这是“Log-ME”功能中的错误条件。它不能标记后续请求和响应，并且必须停止在同一对话框中记录消息。应在第8.5节规定的时间段内保留以前记录的任何消息，不得删除。
If a "log me" marking that begins mid-dialog error is detected by a UA, SIP intermediary, or B2BUA, it SHOULD consider this to be an error condition in the "log me" functionality. It MUST NOT forward the "log me" marker, and it MUST NOT log the message. It MUST NOT mark subsequent requests and responses, and it MUST NOT log subsequent messages in the same dialog.
如果由UA、SIP中介或B2BUA检测到开始中间对话错误的“Log-ME”标记，则应该认为这是“LogME”功能中的错误条件。它不能转发“log me”标记，也不能记录消息。它不能标记后续请求和响应，也不能在同一对话框中记录后续消息。
"Log me" marking errors can be detected and handled only by supporting UAs or B2BUAs. A SIP proxy as defined in [RFC3261] cannot detect or handle marking errors and will simply forward any "log me" marker it receives.
“Log me”标记错误只能通过支持UAs或B2BUAs来检测和处理。[RFC3261]中定义的SIP代理无法检测或处理标记错误，只会转发它接收到的任何“log me”标记。
ABNF is described in [RFC5234]. This document introduces a new "logme" parameter for the Session-ID header field defined in Section 5 of [RFC7989].
[RFC5234]中描述了ABNF。本文档为[RFC7989]第5节中定义的会话ID头字段引入了一个新的“logme”参数。
sess-id-param =/ logme-param
sess id param=/logme param
logme-param = "logme"
logme-param = "logme"
Figure 12: Augmented BNF for the "logme" Parameter
图12：“logme”参数的扩充BNF
"Log me" marking MUST be disabled by default both at the endpoints and intermediaries and MUST be enabled only by authorized users. For example, an end user or network administrator must give permission for a terminal that supports "log me" marking in order to initiate marking. Similarly, a network administrator must enable a configuration at the SIP intermediary to perform "log me" marking on behalf of a terminal that does not support "log me" marking. The permission MUST be limited to only specific calls of interest that are originated in a given time duration.
默认情况下，必须在端点和中介处禁用“Log me”标记，并且必须仅由授权用户启用。例如，最终用户或网络管理员必须为支持“log me”标记的终端授予权限才能启动标记。类似地，网络管理员必须启用SIP中介处的配置，以代表不支持“log me”标记的终端执行“log me”标记。权限必须仅限于在给定的持续时间内发起的特定感兴趣的调用。
Activating a debug mode affects the operation of a terminal; therefore, the debugging configuration MUST be supplied by an authorized party to an authorized terminal through a secure communication channel.
激活调试模式会影响终端的操作；因此，调试配置必须由授权方通过安全通信通道提供给授权终端。
The "log me" marker is not sensitive information, though it will sometimes be inserted because a particular device is experiencing problems.
“log me”标记不是敏感信息，但有时会因为特定设备出现问题而插入。
The presence of a "log me" marker will cause some SIP entities to log signaling messages. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted, such as appearing mid-dialog in a dialog that was not being logged or outside the configured start and stop of logging.
“log me”标记的存在将导致一些SIP实体记录信令消息。因此，如果该标记被错误地插入，例如在未记录的对话框中出现在对话框中间或在配置的开始和停止记录之外，则必须尽早删除该标记。
If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking is removed as mandated in Section 3.4.2. This behavior applies to incoming and outgoing requests and responses.
如果SIP请求和响应与外部网络交换，且没有通过“log me”标记的协议，则按照第3.4.2节的规定删除“log me”标记。此行为适用于传入和传出的请求和响应。
Maliciously configuring a large number of terminals to simultaneously mark dialogs with a "log me" marker will cause high processor load on SIP entities that are logging signaling. Since "log me" marking is for the small number of dialogs subject to troubleshooting or regression testing, the number of dialogs that can be simultaneously logged can be statically limited without adversely affecting the usefulness of "log me" marking. Also, the SIP intermediary closest to the terminal and SIP intermediary at network edge (e.g., Session Border Controllers) can be configured to screen-out "log me" markers when troubleshooting or regression testing is not in progress.
恶意地将大量终端配置为同时使用“log me”标记标记对话框将导致记录信令的SIP实体上的高处理器负载。由于“log me”标记适用于少数需要进行故障排除或回归测试的对话框，因此可以静态限制可同时记录的对话框数量，而不会对“log me”标记的有用性产生不利影响。此外，最靠近终端的SIP中间层和网络边缘的SIP中间层（例如，会话边界控制器）可以配置为在故障排除或回归测试未进行时屏蔽“log me”标记。
A SIP entity that has logged information MUST protect the logs. Storage of the log files are subject to the security considerations specified in [RFC6872].
具有日志信息的SIP实体必须保护日志。日志文件的存储应遵守[RFC6872]中规定的安全注意事项。
Logging includes all SIP header fields. The SIP privacy mechanisms defined in [RFC3323] can be used to ensure that logs do not divulge personal identity information in the core SIP header fields specified in [RFC3261].
日志记录包括所有SIP头字段。[RFC3323]中定义的SIP隐私机制可用于确保日志不会泄露[RFC3261]中指定的核心SIP头字段中的个人身份信息。
Privacy mechanisms might also need to be applied to header fields defined by SIP extensions and for managing the confidentiality of the Request-URI and SIP header fields and bodies.
隐私机制可能还需要应用于SIP扩展定义的头字段，并用于管理请求URI和SIP头字段和主体的机密性。
"Log me" marking is defined for the SIP protocol, and SIP has header fields such as From, Contact, and P-Asserted-Identity that can carry personal identifiers. Different protocol interactions can be correlated using the Session-ID and Call-ID header fields, but such correlation is limited to a single end-to-end session.
“Log me”标记是为SIP协议定义的，SIP具有头字段，例如可以携带个人标识符的From、Contact和P-Asserted-Identity。可以使用会话ID和调用ID头字段关联不同的协议交互，但这种关联仅限于单个端到端会话。
In order to protect user privacy during logging, privacy settings can be enabled or requested by the terminal used by the end user. [RFC3323] suggests two mechanisms:
为了在登录期间保护用户隐私，终端用户使用的终端可以启用或请求隐私设置。[RFC3323]提出了两种机制：
o By using the value "anonymous" in the From header field
o 通过在From头字段中使用值“anonymous”
o By requesting header-level and session-level privacy from SIP intermediaries using the Privacy header
o 通过使用隐私报头从SIP中介机构请求报头级和会话级隐私
Endpoints that support Globally Routable User Agent URIs (GRUUs) can use a temporary GRUU (see Section 3.1.2 of [RFC5627]) assigned by the Registrar in order to protect user privacy as discussed in Section 10.3 of [RFC5627].
如[RFC5627]第10.3节所述，支持全局可路由用户代理URI（GRUs）的端点可以使用注册商分配的临时GRUU（见[RFC5627]第3.1.2节），以保护用户隐私。
Intermediaries that perform "log me" marking on behalf of the endpoints (see Section 4.3) may also be configured to apply privacy (as defined in Section 3.3 of [RFC3323]) on messages that belong to a dialog that is "log me" marked.
代表端点（参见第4.3节）执行“记录我”标记的中介体也可以配置为对属于标记为“记录我”的对话框的消息应用隐私（如[RFC3323]第3.3节中的定义）。
Complete anonymization (e.g., the Request-URI and the "username" field in the "o=" parameter of an SDP body) may not be possible in all circumstances; therefore, administrators of the originating and
完全匿名化（例如，请求URI和SDP正文“o=”参数中的“username”字段）在所有情况下都不可能实现；因此，发起和
terminating networks should consider how privacy will be ensured when providing consent for "log me" marking.
终端网络应该考虑如何在提供“Log-ME”标记的同意时确保隐私。
"Log me" marking is typically used for troubleshooting and regression testing; in some cases, a service-provider-owned device with a dummy account can be used instead of a customer device. In such cases, no personal identifiers are included in the logged signaling messages.
“Log me”标记通常用于故障排除和回归测试；在某些情况下，可以使用具有虚拟帐户的服务提供商拥有的设备来代替客户设备。在这种情况下，记录的信令消息中不包括个人标识符。
SIP endpoints and intermediaries that honor the "log me" request store all the SIP messages that are exchanged within a given dialog. SIP messages can contain the personal identifiers listed in Section 8.1 and additionally a user identity, calling party number, IP address, hostname, and other user-related or device-related items. The SIP message bodies describe the kind of session being set up by the identified end user and device.
接受“log me”请求的SIP端点和中介存储在给定对话框中交换的所有SIP消息。SIP消息可以包含第8.1节中列出的个人标识符，以及用户标识、主叫方号码、IP地址、主机名和其他与用户相关或与设备相关的项目。SIP消息体描述由识别的最终用户和设备建立的会话类型。
"Log me" marking does not introduce any additional user or device data to SIP but might indicate that a specific user is experiencing a problem.
“Log me”标记不会向SIP引入任何其他用户或设备数据，但可能表示特定用户遇到问题。
If the SIP SDP parameters [SDP-PARAMETERS] contain sensitive security information (e.g., encryption keys) such as "crypto" [RFC4568], 3GPP-Integrity-Key, or 3GPP-SRTP-Config [RFC6064] attributes, then the attribute value MUST be masked with a dummy value prior to storing the message in a log file. For example, the attribute value can be replaced with a string of special characters like "X", "*", and "#" as shown in the example below.
如果SIP SDP参数[SDP-parameters]包含诸如“crypto”[RFC4568]、3GPP完整性密钥或3GPP SRTP Config[RFC6064]属性等敏感安全信息（例如，加密密钥），则在将消息存储在日志文件中之前，必须使用伪值屏蔽该属性值。例如，属性值可以替换为特殊字符字符串，如“X”、“*”和“#”，如下例所示。
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX
a=密码：XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SIP messages that are logged due to "log me" requests are stored only by the SIP initiators, intermediaries, and recipients. Enablers as defined in Section 3.1 of [RFC6973], such as firewalls and DNS servers, do not log messages due to the "log me" marking.
由于“log me”请求而记录的SIP消息仅由SIP启动器、中介和收件人存储。[RFC6973]第3.1节中定义的启用码，如防火墙和DNS服务器，由于“log me”标记，不会记录消息。
"Log me" functionality is typically used to troubleshoot a given problem and, hence, can be used as a method to identify users and devices that are experiencing issues. The best way to prevent fingerprinting of users is to enable or request SIP privacy for the logged dialog.
“Log me”功能通常用于对给定问题进行故障排除，因此可以用作识别遇到问题的用户和设备的方法。防止用户指纹识别的最佳方法是为记录的对话框启用或请求SIP隐私。
The lifetime of "log me" marking is equivalent to the lifetime of the dialog that initiated the "log me" request. When "log me" is extended to related dialogs, the lifetime is extended until there is no remaining related dialog for the end-to-end session.
“log me”标记的生存期相当于启动“log me”请求的对话框的生存期。当“log me”扩展到相关对话框时，生存期将延长，直到端到端会话没有剩余的相关对话框为止。
"Log me" automatically expires at the end of the dialog, and there is no explicit mechanism to turn off logging within a dialog.
“Log me”在对话框结束时自动过期，并且没有明确的机制来关闭对话框中的日志记录。
The scope of "log me" marking is limited, i.e., a user or the network administrator has to enable it on a per-session basis or for a specific time period. This minimizes the risk of exposing user data for an indefinite time.
“log me”标记的范围是有限的，即用户或网络管理员必须在每个会话或特定时间段内启用它。这将无限期公开用户数据的风险降至最低。
The retention time period for logged messages SHOULD be the minimum needed for each particular troubleshooting or testing case. The retention period is configured based on the data-retention policies of service providers and enterprises.
记录消息的保留时间应为每个特定故障排除或测试用例所需的最小时间。根据服务提供商和企业的数据保留策略配置保留期。
Consent to turn on "log me" marking for a given session MUST be provided by the end user or by the network administrator. It is handled outside of the protocol through user interface or application programming interfaces at the endpoint, call control elements, and network management systems.
最终用户或网络管理员必须同意打开给定会话的“log me”标记。它在协议之外通过端点处的用户界面或应用程序编程界面、呼叫控制元素和网络管理系统进行处理。
Originating and terminating endpoints that are "log me" aware and have a user interface MUST indicate (using text, icon, etc.) to the user that a session is being logged.
具有“log me”意识并具有用户界面的发起和终止端点必须向用户指示（使用文本、图标等）正在记录会话。
SIP entities across the communication path MAY be configured to pass through the "log me" marking but not honor the request, i.e., not log the data based on local policies.
跨通信路径的SIP实体可被配置为通过“logme”标记，但不接受请求，即不基于本地策略记录数据。
The recommended defaults for "log me" marking are:
“记录我”标记的建议默认值为：
o Turn on SIP privacy as described in Section 8 or use a device that is service provider owned with a dummy user identity for test calls.
o 如第8节所述打开SIP隐私，或使用服务提供商拥有的具有虚拟用户身份的设备进行测试呼叫。
o Use the local UUID portion of the Session-ID header field value at the originating device as the test case identifier as described in Section 3.3.
o 如第3.3节所述，使用原始设备上会话ID报头字段值的本地UUID部分作为测试用例标识符。
The following parameter has been added to the "Header Field Parameters and Parameter Values" section of the "Session Initiation Protocol (SIP) Parameters" registry:
以下参数已添加到“会话启动协议（SIP）参数”注册表的“标头字段参数和参数值”部分：
+-------------+---------------+-------------------------+-----------+
| Header | Parameter | Predefined Values | Reference |
| Field | Name | | |
+-------------+---------------+-------------------------+-----------+
| Session-ID | logme | No (no values are | [RFC8497] |
| | | allowed) | |
+-------------+---------------+-------------------------+-----------+
+-------------+---------------+-------------------------+-----------+
| Header | Parameter | Predefined Values | Reference |
| Field | Name | | |
+-------------+---------------+-------------------------+-----------+
| Session-ID | logme | No (no values are | [RFC8497] |
| | | allowed) | |
+-------------+---------------+-------------------------+-----------+
Table 1
表1
[MEDIA-TYPES] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.
[媒体类型]IANA，“媒体类型”<https://www.iana.org/assignments/media-types/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc3261>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<https://www.rfc-editor.org/info/rfc3323>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://www.rfc-editor.org/info/rfc3891>.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 3891，DOI 10.17487/RFC3891，2004年9月<https://www.rfc-editor.org/info/rfc3891>.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, DOI 10.17487/RFC3911, October 2004, <https://www.rfc-editor.org/info/rfc3911>.
[RFC3911]Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，DOI 10.17487/RFC3911，2004年10月<https://www.rfc-editor.org/info/rfc3911>.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006, <https://www.rfc-editor.org/info/rfc4538>.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，DOI 10.17487/RFC4538，2006年6月<https://www.rfc-editor.org/info/rfc4538>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，DOI 10.17487/RFC4568，2006年7月<https://www.rfc-editor.org/info/rfc4568>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <https://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<https://www.rfc-editor.org/info/rfc5627>.
[RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service", RFC 6064, DOI 10.17487/RFC6064, January 2011, <https://www.rfc-editor.org/info/rfc6064>.
[RFC6064]Westerlund，M.和P.Frojdh，“为3GPP分组交换流媒体服务和多媒体广播/多播服务定义的SDP和RTSP扩展”，RFC 6064，DOI 10.17487/RFC6064，2011年1月<https://www.rfc-editor.org/info/rfc6064>.
[RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, DOI 10.17487/RFC6872, February 2013, <https://www.rfc-editor.org/info/rfc6872>.
[RFC6872]Gurbani，V.，Ed.，Burger，E.，Ed.，Anjali，T.，Abdelnur，H.，和O.Festor，“会话启动协议（SIP）的通用日志格式（CLF）：框架和信息模型”，RFC 6872，DOI 10.17487/RFC6872，2013年2月<https://www.rfc-editor.org/info/rfc6872>.
[RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, <https://www.rfc-editor.org/info/rfc6873>.
[RFC6873]Salgueiro，G.，Gurbani，V.，和A.Roach，“会话启动协议（SIP）通用日志格式（CLF）的格式”，RFC 6873，DOI 10.17487/RFC6873，2013年2月<https://www.rfc-editor.org/info/rfc6873>.
[RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7989, DOI 10.17487/RFC7989, October 2016, <https://www.rfc-editor.org/info/rfc7989>.
[RFC7989]Jones，P.，Salgueiro，G.，Pearce，C.，和P.Giralt，“基于IP的多媒体通信网络中的端到端会话识别”，RFC 7989，DOI 10.17487/RFC7989，2016年10月<https://www.rfc-editor.org/info/rfc7989>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[SDP-PARAMETERS] IANA, "Session Description Protocol (SDP) Parameters", <https://www.iana.org/assignments/sdp-parameters/>.
[SDP-PARAMETERS]IANA，“会话描述协议（SDP）参数”<https://www.iana.org/assignments/sdp-parameters/>.
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC3665]Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话启动协议（SIP）基本呼叫流示例”，BCP 75，RFC 3665，DOI 10.17487/RFC3665，2003年12月<https://www.rfc-editor.org/info/rfc3665>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, <https://www.rfc-editor.org/info/rfc5589>.
[RFC5589]Sparks，R.，Johnston，A.，Ed.，和D.Petrie，“会话启动协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，DOI 10.17487/RFC5589，2009年6月<https://www.rfc-editor.org/info/rfc5589>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<https://www.rfc-editor.org/info/rfc7092>.
[RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. Kaplan, "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, <https://www.rfc-editor.org/info/rfc7206>.
[RFC7206]Jones，P.，Salgueiro，G.，Polk，J.，Liess，L.，和H.Kaplan，“基于IP的多媒体通信网络中端到端会话识别的要求”，RFC 7206，DOI 10.17487/RFC7206，2014年5月<https://www.rfc-editor.org/info/rfc7206>.
[RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking SIP Messages to be Logged", RFC 8123, DOI 10.17487/RFC8123, March 2017, <https://www.rfc-editor.org/info/rfc8123>.
[RFC8123]Dawes，P.和C.Arunachalam，“标记待记录SIP消息的要求”，RFC 8123，DOI 10.17487/RFC81232017年3月<https://www.rfc-editor.org/info/rfc8123>.
Acknowledgments
致谢
The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, Christer Holmberg, Vijay Gurbani, Ben Campbell, Gonzalo Salgueiro, Francesca Palombini, Adam Roach, Mirja Kuhlewind, Benjamin Kaduk, Eric Rescorla, Alissa Cooper, Warren Kumari, and Alexey Melnikov for their constructive review comments and guidance while developing this document.
作者希望感谢Paul Giralt、Paul Kyzivat、Jorgen Axell、Christer Holmberg、Vijay Gurbani、Ben Campbell、Gonzalo Salgueiro、Francesca Palombini、Adam Roach、Mirja Kuhlewind、Benjamin Kaduk、Eric Rescorla、Alissa Cooper、Warren Kumari和Alexey Melnikov在编制本文件时提出的建设性审查意见和指导。
Authors' Addresses
作者地址
Peter Dawes Vodafone Group The Connection Newbury, Berkshire RG14 2FN United Kingdom
彼得·道斯·沃达丰集团英国伯克希尔郡纽伯里RG14 2FN
Phone: +44 7717 275009
Email: peter.dawes@vodafone.com
Phone: +44 7717 275009
Email: peter.dawes@vodafone.com
Chidambaram Arunachalam Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Chidambaram Arunachalam思科系统7200-12美国北卡罗来纳州Kit Creek路研究三角公园27709
Email: carunach@cisco.com
Email: carunach@cisco.com