Internet Engineering Task Force (IETF) P. Dawes
Request for Comments: 8123 Vodafone Group
Category: Informational C. Arunachalam
ISSN: 2070-1721 Cisco Systems
March 2017
Internet Engineering Task Force (IETF) P. Dawes
Request for Comments: 8123 Vodafone Group
Category: Informational C. Arunachalam
ISSN: 2070-1721 Cisco Systems
March 2017
Requirements for Marking SIP Messages to be Logged
标记要记录的SIP消息的要求
Abstract
摘要
SIP networks use signaling monitoring tools to debug customer-reported problems and for regression testing if network or client 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 clients and, therefore, impractical to monitor SIP signaling end-to-end.
SIP网络使用信令监控工具调试客户报告的问题，并在网络或客户端软件升级时进行回归测试。随着网络的增长和互联，包括通过传输网络的连接，预测SIP信令在客户端之间的路径变得不切实际，因此，端到端监控SIP信令变得不切实际。
This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.
本文档描述了向SIP协议数据单元（PDU）添加指示器或将PDU标记为日志候选的SIP消息的要求。这种标记通常作为网络运营商控制的网络测试的一部分应用，而不是在常规客户端信令中使用。然而，即使会话在不同的网络中发起和终止，也可以端到端地携带这样的标记，包括SIP终端。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8123.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8123.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Network Boundary . . . . . . . . . . . . . . . . . . . . 3
3.2. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Intermediary . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Example Network Arrangement . . . . . . . . . . . . . . . 5
4.3. Example Debugging Procedure . . . . . . . . . . . . . . . 6
5. "Log Me" Marking Requirements . . . . . . . . . . . . . . . . 6
5.1. Message Logs . . . . . . . . . . . . . . . . . . . . . . 6
5.2. "Log Me" Marking . . . . . . . . . . . . . . . . . . . . 7
5.3. Processing the "Log Me" Marker . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Security Threats . . . . . . . . . . . . . . . . . . . . 9
6.2.1. "Log Me" Marking . . . . . . . . . . . . . . . . . . 9
6.2.2. Logged Information . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Network Boundary . . . . . . . . . . . . . . . . . . . . 3
3.2. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Intermediary . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Example Network Arrangement . . . . . . . . . . . . . . . 5
4.3. Example Debugging Procedure . . . . . . . . . . . . . . . 6
5. "Log Me" Marking Requirements . . . . . . . . . . . . . . . . 6
5.1. Message Logs . . . . . . . . . . . . . . . . . . . . . . 6
5.2. "Log Me" Marking . . . . . . . . . . . . . . . . . . . . 7
5.3. Processing the "Log Me" Marker . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Security Threats . . . . . . . . . . . . . . . . . . . . 9
6.2.1. "Log Me" Marking . . . . . . . . . . . . . . . . . . 9
6.2.2. Logged Information . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Service providers, enterprises, and others who operate networks that use SIP (see [RFC3261]) need the ability to debug problems reported by end users and also to run regression tests if SIP client software/ hardware is upgraded. Such debugging and testing might be confined to a single service provider or network, or they may occur between the administrative domains of different network operators, including domains in different countries that are interconnected through networks belonging to one or more third parties.
服务提供商、企业和其他运营使用SIP的网络的人（请参见[RFC3261]）需要能够调试最终用户报告的问题，并在升级SIP客户端软件/硬件时运行回归测试。此类调试和测试可能仅限于单个服务提供商或网络，也可能发生在不同网络运营商的管理域之间，包括通过属于一个或多个第三方的网络互连的不同国家的域。
A mechanism is needed to mark particular SIP sessions, i.e., those related to debugging or regression testing, as candidates for logging; this marking must be carried within the candidate SIP messages as they are routed across networks (and geographies) to enable logging at each SIP entity without having to know in advance the list of SIP entities through which the SIP signaling messages will traverse. Such marking must take into account that SIP messages might traverse different network operators, different countries, regions with different privacy requirements, and different trust domains. This document describes the requirements for such a "log me" marker for SIP signaling.
需要一种机制将特定SIP会话（即与调试或回归测试相关的会话）标记为日志记录的候选会话；当候选SIP消息在网络（和地理位置）上路由时，必须在候选SIP消息中进行此标记，以便能够在每个SIP实体上进行日志记录，而无需事先知道SIP信令消息将通过的SIP实体列表。这种标记必须考虑到SIP消息可能会穿越不同的网络运营商、不同的国家、具有不同隐私要求的地区以及不同的信任域。本文档描述了用于SIP信令的“log me”标记的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], except that rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log me" marker solution.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的描述进行解释，但它们不是描述互操作性要求，而是用于描述“日志me”标记解决方案要满足的要求。
A network boundary is the part of a signaling path where messages pass between entities that are under different administrative control. Figure 2 in [RFC5853] shows a network boundary between the originating gateway GW-A1 in operator A's network and the Session Border Controller (SBC) in operator B's network. A network boundary is significant in this document because manipulation of signaling at the boundary could prevent end-to-end testing or troubleshooting.
网络边界是信令路径的一部分，消息在不同管理控制下的实体之间传递。[RFC5853]中的图2显示了运营商a网络中的发起网关GW-A1和运营商B网络中的会话边界控制器（SBC）之间的网络边界。在本文档中，网络边界非常重要，因为在边界处操纵信令可能会阻止端到端测试或故障排除。
Topology hiding and protocol repair (see [RFC5853]) are two common functions that manipulate signaling at the network boundary. These functions are performed by SIP device types (see [RFC7092]) such as a Session Border Controller and Interconnection Border Control Function (IBCF).
拓扑隐藏和协议修复（参见[RFC5853]）是在网络边界处操纵信令的两个常见功能。这些功能由SIP设备类型（参见[RFC7092]）执行，例如会话边界控制器和互连边界控制功能（IBCF）。
In this document, a trust domain is the set of entities that have been identified by prior agreement as the participating elements in logging, typically for the purpose of debugging or regression testing. A trust domain contains all SIP entities under configuration control of the network operator who is performing regression testing plus all SIP entities that are under configuration control of peer network operators who have agreed to participate in that regression testing. The purpose of trust domain requirements is to prevent network operators from inadvertently triggering logging in networks that are not part of any testing or troubleshooting.
在本文档中，信任域是一组实体，这些实体通过事先协议被标识为日志记录中的参与元素，通常用于调试或回归测试。信任域包含执行回归测试的网络运营商配置控制下的所有SIP实体，以及同意参与该回归测试的对等网络运营商配置控制下的所有SIP实体。信任域要求的目的是防止网络运营商无意中触发不属于任何测试或故障排除一部分的网络登录。
The term "intermediary" is defined in Section 2 of [RFC7989]; it refers to any entity along the call signaling path.
[RFC7989]第2节定义了术语“中间人”；它是指沿着呼叫信令路径的任何实体。
Signaling for SIP session setup can cross several networks; these networks may not have common ownership and may also be in different countries. If a single operator wishes to perform regression testing or fault debugging end-to-end, the separate ownership of networks that carry the signaling and the explosion in the number of possible signaling paths through SIP entities from the originating to the terminating user make it impractical to preconfigure logging end-to-end SIP signaling of a session of interest.
SIP会话设置的信令可以跨多个网络；这些网络可能没有共同所有权，也可能位于不同的国家。如果单个操作员希望端到端执行回归测试或故障调试，承载信令的网络的单独所有权以及通过SIP实体从发起用户到终端用户的可能信令路径的数量的爆炸性增长使得预先配置感兴趣会话的端到端SIP信令日志是不切实际的。
The figure below gives an example of a signaling path through multiple networks.
下图给出了通过多个网络的信令路径示例。
+------------------+ +------------------+
| COUNTRY W | | COUNTRY X |
| Operator A | | Operator A |
| | | |
| SIP Phones | | SIP Phones |
| | //| |
+------------------+ // +------------------+
| //
| //
,'```', // +------------------+
.`',.' `..'``',<==// | COUNTRY X |
,' Operator A `', | Operator A |
; Backbone Network ..'--| |
', ,., .'` | PSTN phones |
'.,.`'.,,,.` `''` | |
|| +------------------+
||
\/
+------------------+
| |
| Transit Network |
| |
| |\\
+------------------+ \\
| \\
| \\
+------------------+ \\ +------------------+
| COUNTRY Z | \\ | COUNTRY Y |
| Operator C | \\=>| Operator B |
| | | |
| SIP Phones | | SIP Phones |
| | | |
+------------------+ +------------------+
+------------------+ +------------------+
| COUNTRY W | | COUNTRY X |
| Operator A | | Operator A |
| | | |
| SIP Phones | | SIP Phones |
| | //| |
+------------------+ // +------------------+
| //
| //
,'```', // +------------------+
.`',.' `..'``',<==// | COUNTRY X |
,' Operator A `', | Operator A |
; Backbone Network ..'--| |
', ,., .'` | PSTN phones |
'.,.`'.,,,.` `''` | |
|| +------------------+
||
\/
+------------------+
| |
| Transit Network |
| |
| |\\
+------------------+ \\
| \\
| \\
+------------------+ \\ +------------------+
| COUNTRY Z | \\ | COUNTRY Y |
| Operator C | \\=>| Operator B |
| | | |
| SIP Phones | | SIP Phones |
| | | |
+------------------+ +------------------+
Figure 1: Example Signaling Path through Multiple Networks
图1：通过多个网络的信令路径示例
One possible set of steps is outlined below to illustrate the debugging procedure.
下面概述了一组可能的步骤来说明调试过程。
o The user's terminal is placed in debug mode. The terminal logs its own signaling and inserts a "log me" marker into SIP requests for session setup.
o 用户终端处于调试模式。终端记录自己的信令，并在会话设置的SIP请求中插入“log me”标记。
o All SIP entities that the signaling traverses, from the first proxy the terminal connects to at the edge of the network to the destination client terminal, detect that the "log me" marker is present and then log SIP requests and responses that contain the marker if configured to do so.
o 从终端在网络边缘连接到的第一个代理到目标客户端终端，信令所经过的所有SIP实体都检测到存在“log me”标记，然后记录包含该标记的SIP请求和响应（如果配置为这样做）。
o Subsequent responses and requests in the same dialog are also marked with a "log me" marker. For some scenarios, such as call transfer, related dialogs may also be marked with "log me" marker.
o 同一对话框中的后续响应和请求也用“log me”标记。对于某些场景，例如呼叫转移，相关对话框也可能被标记为“log me”标记。
o Logging stops, either because the dialog has ended or because a "stop event", typically expiry of a certain amount of time, occurred.
o 日志记录停止，原因可能是对话框已结束，也可能是发生了“停止事件”（通常在一定时间内过期）。
o Logs are retrieved, for example, by logging on to the SIP entity or entities that contain the logs.
o 例如，通过登录到SIP实体或包含日志的实体来检索日志。
REQ1 If a SIP message is logged, then the entire SIP message (SIP headers and message body) MUST be logged using a standard logging format such as SIP Common Log Format (CLF) defined in [RFC6873].
REQ1如果记录了SIP消息，则必须使用标准记录格式（如[RFC6873]中定义的SIP通用日志格式（CLF））记录整个SIP消息（SIP头和消息体）。
REQ2 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 as described in [RFC3261], Section 7.3.3.
REQ2标题字段应以其在消息中出现的形式记录；不得在[RFC3261]第7.3.3节所述的长型和紧凑型之间转换。
When and how signaling logs are retrieved is out of scope of this document. Logs might be retrieved by logging on to the SIP entity that contains the logs, by sending logs to a central server that is coordinating debugging, by storing them on removable media for later manual collection, or by some other method. All log retrieval mechanisms MUST adhere to the authorization and privacy protection policies set forth by the network administrator.
何时以及如何检索信令日志超出了本文档的范围。可以通过登录到包含日志的SIP实体、将日志发送到正在协调调试的中央服务器、将日志存储在可移动媒体上以供以后手动收集或通过其他方法来检索日志。所有日志检索机制必须遵守网络管理员制定的授权和隐私保护策略。
REQ3: It MUST be possible to mark a SIP request or response to be considered for logging by inserting a "log me" marker. This is known as "log me" marking.
REQ3：必须可以通过插入“log me”标记来标记要考虑记录的SIP请求或响应。这就是所谓的“记录我”标记。
REQ4: It MUST be possible for a "log me" marker to cross network boundaries.
REQ4：“log me”标记必须能够跨越网络边界。
REQ5: A "log me" marker MAY include an identifier that indicates the test case that caused it to be inserted, known as a "test case identifier". The test case identifier does not have any impact on session setup; it is used to collate all logged SIP requests and responses to the initial SIP request in a dialog or standalone transaction. The local Universally Unique Identifier (UUID) portion of the Session-ID described in [RFC7206] and [RFC7989] could be used as a random test case identifier.
REQ5：“log me”标记可能包括一个标识符，该标识符指示导致插入它的测试用例，称为“测试用例标识符”。测试用例标识符对会话设置没有任何影响；它用于在对话框或独立事务中整理所有记录的SIP请求和对初始SIP请求的响应。[RFC7206]和[RFC7989]中描述的会话ID的本地通用唯一标识符（UUID）部分可用作随机测试用例标识符。
REQ6: A "log me" marker is most effective if all networks on the signaling path agree to pass it end-to-end. However, source networks should behave responsibly and not leave it to a downstream network to detect and remove a marker that it is not expecting.
REQ6：如果信令路径上的所有网络都同意端到端传递，“log me”标记最有效。然而，源网络应该表现出负责任的行为，而不是将其留给下游网络来检测和移除它不期望的标记。
REQ7: The presence of a "log me" marker indicates that a request or response is part of debugging or regression testing.
REQ7：“log me”标记表示请求或响应是调试或回归测试的一部分。
REQ8: It MUST be possible to insert a "log me" marker in SIP responses that correspond to SIP requests with a "log me" marker in order to ensure that the complete SIP transaction is logged. This requirement applies to endpoints, SIP/Public Switched Telephone Network (PSTN) gateways, and back-to-back user agents (B2BUAs).
REQ8：必须能够在SIP响应中插入一个“log me”标记，该标记对应具有“log me”标记的SIP请求，以确保记录完整的SIP事务。此要求适用于端点、SIP/公共交换电话网（PSTN）网关和背靠背用户代理（B2BUA）。
REQ9: The "log me" marker mechanism SHOULD allow a SIP intermediary to request logging SIP requests and responses on behalf of the originating endpoint. The typical use case for this requirement is for compatibility with User Agents (UAs) that have not implemented "log me" marking, i.e., when a UA has not marked a request or when responses received on a dialog of interest for logging do not contain an echoed "log me" marker. Another use case is when the session origination UA that inserted the "log me" marker is no longer participating in the
REQ9：“log me”标记机制应允许SIP中介代表发起端点请求记录SIP请求和响应。此要求的典型用例是与未实现“log me”标记的用户代理（UA）的兼容性，即当UA未标记请求时，或当在感兴趣的日志对话框上收到的响应不包含回显的“log me”标记时。另一个用例是插入“log me”标记的会话发起UA不再参与
session (e.g., call transfer scenarios) and the intermediary adds a "log me" marker in related sessions to enable end-to-end signaling analysis.
会话（例如，呼叫转移场景）和中介在相关会话中添加“log me”标记，以启用端到端信令分析。
REQ10: The mechanism MUST allow stateless processing of SIP requests that contain a "log me" marker by SIP intermediaries. This requirement enables the SIP intermediaries to base the decision to log a SIP request or response solely on the presence of the "log me" marker.
REQ10：该机制必须允许SIP中介对包含“log me”标记的SIP请求进行无状态处理。此要求使SIP中介机构能够仅根据“log me”标记的存在来决定记录SIP请求或响应。
REQ11: The scope of a SIP message logging request includes all requests and responses within a given dialog. The scope can be extended to related dialogs that correspond to an end-to-end session for scenarios discussed in REQ9. The "log me" request MUST be indicated at the beginning of the dialog of interest and SHOULD continue to the dialog end without any stop and restart during the duration of the dialog.
REQ11:SIP消息日志记录请求的范围包括给定对话框中的所有请求和响应。该范围可以扩展到与REQ9中讨论的场景的端到端会话相对应的相关对话框。“log me”请求必须在感兴趣的对话框开始处指示，并且应在对话框持续期间继续到对话框结束，不停止并重新启动。
REQ12: The presence of a "log me" marker might cause some SIP entities to log signaling. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted (e.g., mid-dialog or outside the configured start and stop of "log me" marking).
REQ12：“log me”标记的存在可能会导致一些SIP实体记录信令。因此，如果该标记插入错误，则必须尽早将其删除（例如，在对话框中间或配置的“log me”标记的开始和停止之外）。
The definition of types of events that cause logging to stop and the configuration of SIP entities to detect such "stop events" is outside the scope of this document.
导致日志停止的事件类型的定义以及检测此类“停止事件”的SIP实体的配置超出了本文档的范围。
In order to prevent any security implications of a "log me" marker, the marker itself MUST NOT contain any sensitive information, detecting its presence or absence MUST NOT reveal sensitive information, and maliciously adding a "log me" marker MUST NOT adversely affect a network. This section analyzes how to meet these requirements.
为了防止“log me”标记的任何安全影响，标记本身不得包含任何敏感信息，检测其存在或不存在不得泄露敏感信息，恶意添加“log me”标记不得对网络产生不利影响。本节分析如何满足这些要求。
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 trust domain boundary. If a prior agreement to log sessions exists with the next hop network, then the "log me" marker SHOULD NOT be removed.
由于“log me”标记可能导致SIP实体记录请求或响应的SIP头和主体，因此必须在信任域边界处删除“log me”标记。如果与下一跳网络存在日志会话的事先协议，则不应删除“log me”标记。
The "log me" marker MUST NOT convey any sensitive information, although the "log me" marker will sometimes be inserted because a particular device is experiencing problems. The "log me" marker MUST NOT reveal any information related to any SIP user or device.
“log me”标记不能传递任何敏感信息，尽管“log me”标记有时会因为特定设备出现问题而插入。“log me”标记不得显示与任何SIP用户或设备相关的任何信息。
The insertion of the "log me" marker at the endpoint MUST be approved by the end user or by the network administrator. Similarly, network administrator authorization is required for a SIP intermediary to insert a "log me" marker on behalf of a UA that does not support "log me" marking.
在端点插入“log me”标记必须得到最终用户或网络管理员的批准。类似地，SIP中介体需要网络管理员授权才能代表不支持“log me”标记的UA插入“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.
激活调试模式会影响终端的操作；因此，调试配置必须由授权方通过安全通信通道提供给授权终端。
Logged signaling is privacy-sensitive data; therefore, signaling logs MUST NOT be readable by an unauthorized third party.
记录的信令是隐私敏感数据；因此，未经授权的第三方不能读取信令日志。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc6873>.
[RFC6873]Salgueiro，G.，Gurbani，V.，和A.Roach，“会话启动协议（SIP）通用日志格式（CLF）的格式”，RFC 6873，DOI 10.17487/RFC6873，2013年2月<http://www.rfc-editor.org/info/rfc6873>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, <http://www.rfc-editor.org/info/rfc5853>.
[RFC5853]Hautakorpi，J.，Ed.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 5853，DOI 10.17487/RFC5853，2010年4月<http://www.rfc-editor.org/info/rfc5853>.
[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, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc7206>.
[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, <http://www.rfc-editor.org/info/rfc7989>.
[RFC7989]Jones，P.，Salgueiro，G.，Pearce，C.，和P.Giralt，“基于IP的多媒体通信网络中的端到端会话识别”，RFC 7989，DOI 10.17487/RFC7989，2016年10月<http://www.rfc-editor.org/info/rfc7989>.
Acknowledgments
致谢
The authors wish to thank Jorgen Axell, Ben Campbell, Keith Drage, Vijay Gurbani, Christer Holmberg, Hadriel Kaplan, Paul Kyzivat, James Polk, Gonzalo Salgueiro, Alberto Llamas, Brett Tate, Paul Giralt, Stewart Bryant, Sean Turner, and Dan Romascanu for their constructive comments and guidance while developing this document.
作者希望感谢Jorgen Axell、Ben Campbell、Keith Drage、Vijay Gurbani、Christer Holmberg、Hadriel Kaplan、Paul Kyzivat、James Polk、Gonzalo Salgueiro、Alberto Llamas、Brett Tate、Paul Giralt、Stewart Bryant、Sean Turner和Dan Romascanu在编写本文件时提出的建设性意见和指导。
Authors' Addresses
作者地址
Peter Dawes Vodafone Group The Connection Newbury, Berkshire RG14 2FN United Kingdom
彼得·道斯·沃达丰集团英国伯克希尔郡纽伯里RG14 2FN
Email: peter.dawes@vodafone.com
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