Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7206 G. Salgueiro
Category: Informational J. Polk
ISSN: 2070-1721 Cisco Systems
L. Liess
Deutsche Telekom
H. Kaplan
Oracle
May 2014
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7206 G. Salgueiro
Category: Informational J. Polk
ISSN: 2070-1721 Cisco Systems
L. Liess
Deutsche Telekom
H. Kaplan
Oracle
May 2014
Requirements for an End-to-End Session Identifier in IP-Based Multimedia Communication Networks
基于IP的多媒体通信网络中对端到端会话标识符的要求
Abstract
摘要
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.
本文件规定了基于IP的多媒体通信网络中端到端会话标识符的要求。该标识符将使端点、中间设备以及管理和监视系统能够跨多个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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7206.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7206.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 .....................................................4
3.1. What Does the Session Identifier Identify? .................4
3.2. Communication Session ......................................5
3.3. End-to-End .................................................6
4. Session Identifier Use Cases ....................................6
4.1. End-to-End Identification of a Communication Session .......6
4.2. Protocol Interworking ......................................6
4.3. Traffic Monitoring .........................................7
4.4. Tracking Transferred Sessions ..............................7
4.5. Session Signal Logging .....................................8
4.6. Identifier Syntax ..........................................8
4.7. 3PCC Use Case ..............................................9
5. Requirements for the End-to-End Session Identifier ..............9
6. Related Work in Other Standards Organizations ..................10
6.1. Coordination with the ITU-T ...............................10
6.2. Requirements within 3GPP ..................................11
7. Security Considerations ........................................11
8. Acknowledgments ................................................12
9. Contributors ...................................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................4
3.1. What Does the Session Identifier Identify? .................4
3.2. Communication Session ......................................5
3.3. End-to-End .................................................6
4. Session Identifier Use Cases ....................................6
4.1. End-to-End Identification of a Communication Session .......6
4.2. Protocol Interworking ......................................6
4.3. Traffic Monitoring .........................................7
4.4. Tracking Transferred Sessions ..............................7
4.5. Session Signal Logging .....................................8
4.6. Identifier Syntax ..........................................8
4.7. 3PCC Use Case ..............................................9
5. Requirements for the End-to-End Session Identifier ..............9
6. Related Work in Other Standards Organizations ..................10
6.1. Coordination with the ITU-T ...............................10
6.2. Requirements within 3GPP ..................................11
7. Security Considerations ........................................11
8. Acknowledgments ................................................12
9. Contributors ...................................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
IP-based multimedia communication systems like SIP [1] and H.323 [2] have the concept of a "call identifier" that is globally unique. The identifier is intended to represent an end-to-end communication session from the originating device to the terminating device. Such an identifier is useful for troubleshooting, session tracking, and so forth.
基于IP的多媒体通信系统，如SIP[1]和H.323[2]具有全局唯一的“呼叫标识符”概念。该标识符旨在表示从发起设备到终止设备的端到端通信会话。这样的标识符对于故障排除、会话跟踪等非常有用。
Unfortunately, there are a number of factors that mean that the current call identifiers defined in SIP and H.323 are not suitable for end-to-end session identification. Perhaps most significant is the fact that the syntax for the call identifier in SIP and H.323 is different between the two protocols. This important fact makes it impossible for call identifiers to be exchanged end-to-end when a network uses both of these session protocols.
不幸的是，有许多因素意味着SIP和H.323中定义的当前呼叫标识符不适合于端到端会话识别。也许最重要的是SIP和H.323中呼叫标识符的语法在这两个协议之间是不同的。这一重要事实使得当网络同时使用这两种会话协议时，呼叫标识符不可能端到端地交换。
Another reason why the current call identifiers are not suitable to identify the session end-to-end is that in real-world deployments, devices like Back-to-Back User Agents (B2BUAs) often change the values as the session signaling passes through. This is true even when a single session protocol is employed and is not a byproduct of protocol interworking.
当前呼叫标识符不适合识别端到端会话的另一个原因是，在实际部署中，像背靠背用户代理（B2BUA）这样的设备经常在会话信令通过时更改值。即使使用单个会话协议，这也是正确的，并且不是协议互通的副产品。
Lastly, identifiers that might have been used to identify a session end-to-end fail to meet that need when sessions are manipulated through supplementary service interactions. For example, when a session is transferred or if a private branch exchange (PBX) joins or merges two communication sessions together locally, the end-to-end properties of currently defined identifiers are lost.
最后，当通过补充服务交互操作会话时，可能用于识别端到端会话的标识符无法满足这一需求。例如，当会话被传输时，或者如果专用分支交换机（PBX）在本地将两个通信会话连接或合并在一起，则当前定义的标识符的端到端属性将丢失。
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.
本文件规定了基于IP的多媒体通信网络中端到端会话标识符的要求。该标识符将使端点、中间设备以及管理和监视系统能够跨多个SIP设备、跃点和管理域端到端地识别会话。
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 RFC 2119 [3] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”在所有大写字母中出现时，应按照RFC 2119[3]中的说明进行解释。这些单词也可以在本文件中以小写形式出现，作为普通英语单词，没有其规范意义。
The identifier on which this document places requirements, the session identifier, identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.
本文档放置需求的标识符（会话标识符）标识了一组与两个端点关联的信令消息，从每个端点的角度来看，这两个端点与通信应用程序的单个调用相关。
How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined.
端点如何确定哪些信令消息共享给定的标识符（即，构成通信应用程序的单个调用的内容）的定义故意不严格。
The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer as a single "call".
术语“呼叫”通常用作语音和视频通信调用的示例，但不同的协议和部署以不同的方式定义“呼叫”的范围。例如，一些系统会将涉及转移的所有三方之间的所有活动关联为一个“呼叫”。
Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media-level interaction. A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC 3550 [4], and possibly even multiple concurrent sessions.
类似地，术语“会话”通常被用作此类调用的示例，但该术语被重载以描述信令和媒体级交互。如上所述，通信应用程序的单个调用可能涉及RFC 3550[4]所述的多个RTP“会话”，甚至可能涉及多个并发会话。
In this document, unless otherwise qualified, the term "communication session", or simply "session", will refer only to the set of signaling messages identified by the common session identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.
在本文件中，除非另有限定，否则术语“通信会话”或简称“会话”将仅指由公共会话标识符标识的信令消息集。也就是说，“会话”是一组与两个端点关联的信令消息，从每个端点的角度来看，这两个端点与通信应用程序的单个调用相关。
The requirements in this document put some constraints on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined.
本文档中的要求对端点将考虑相同或不同的通信会话调用提出了一些限制。它们还确保相关会话（正如本文档使用的术语）可以仅使用每个会话的会话标识符进行关联。同样，故意对构成“相关”会话的内容进行松散定义。
The definition considers messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoint's behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it.
该定义考虑与两个端点关联的消息，而不是在两个端点之间发送的消息，以允许中介代表端点创建消息。端点可能看不到会话中与其关联的所有消息（因为本文档使用的是术语）。
This definition, along with the constraints imposed by the requirements in this document, facilitates specifying an identifier that allows the two endpoints to use two entirely different protocols (and hence to potentially have different ideas of what a single invocation means) or use two applications that have a different idea of what a single invocation means.
此定义以及本文档中需求施加的约束有助于指定一个标识符，该标识符允许两个端点使用两个完全不同的协议（因此可能对单个调用的含义有不同的理解）或者使用两个对单个调用的含义有不同理解的应用程序。
A communication session may exist between two SIP User Agents (UAs) and may pass through one or more intermediary devices, including B2BUAs or SIP proxies. For example:
通信会话可以存在于两个SIP用户代理（ua）之间，并且可以通过一个或多个中间设备，包括B2BUAs或SIP代理。例如：
UA A Middlebox(es) UA B
UA A中间箱（es）UA B
SIP message(s) -------[]---[]-------> SIP message(s)
SIP message(s) <-----[]---[]------- SIP message(s)
SIP message(s) -------[]---[]-------> SIP message(s)
SIP message(s) <-----[]---[]------- SIP message(s)
Figure 1: Communication Session through Middlebox(es)
图1：通过中间箱（es）的通信会话
The following are examples of acceptable communication sessions as described in Section 3.1 and are not exhaustive:
以下是第3.1节所述的可接受沟通会话的示例，并非详尽无遗：
o A call directly between two user agents
o 两个用户代理之间的直接调用
o A call between two user agents with one or more SIP middleboxes in the signaling path
o 在信令路径中具有一个或多个SIP中间盒的两个用户代理之间的呼叫
o A call between two user agents that was initiated using third-party call control (3PCC) [5]
o 使用第三方呼叫控制（3PCC）发起的两个用户代理之间的呼叫[5]
o A call between two user agents (e.g., between Alice and Carol) that results from a different communication session (e.g., Alice and Bob) wherein one of those user agents (Alice) is transferred to another user agent (Carol) using a REFER request or a re-INVITE request
o 两个用户代理（例如Alice和Carol）之间的一种呼叫，由不同的通信会话（例如Alice和Bob）产生，其中一个用户代理（Alice）使用REFER请求或REINVITE请求被转移到另一个用户代理（Carol）
The following are not considered communication sessions:
以下内容不被视为通信会话：
o A call between any two user agents wherein two or more user agents are engaged in a conference call via a conference focus:
o 任何两个用户代理之间的呼叫，其中两个或多个用户代理通过会议焦点参与会议呼叫：
- each call between the user agent and the conference focus would be a communication session, and
- 用户代理和会议焦点之间的每个呼叫都是一个通信会话，并且
- each of these is a distinct communication session.
- 每一个都是不同的通信会话。
o A call between three user agents (e.g., Alice, Bob, and Carol) wherein the first user agent (Alice) ad hoc conferences the other two user agents (Bob and Carol):
o 三个用户代理（如Alice、Bob和Carol）之间的一种呼叫，其中第一个用户代理（Alice）与其他两个用户代理（Bob和Carol）进行临时会议：
- The call between Alice and Bob would be one communication session.
- Alice和Bob之间的通话将是一次通信会话。
- The call between Alice and Carol would be a different communication session.
- Alice和Carol之间的通话将是一个不同的通信会话。
The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the end-to-end session identifier. Since such an endpoint will not create a session identifier, an intermediary device that supports this identifier can inject an identifier into the session signaling.
本文件中的术语“端到端”是指从起始点经过任意数量的中介机构到最终终止点的通信会话。可以认识到，遗留设备可能不支持端到端会话标识符。由于这样的端点不会创建会话标识符，因此支持该标识符的中间设备可以将标识符注入会话信令。
For SIP messaging that either does not involve SIP servers or only involves SIP proxies, the Call-ID header field value sufficiently identifies each SIP message within a transaction (see Section 17 of [1]) or dialog (see Section 12 of [1]). This is not the case when either B2BUAs or Session Border Controllers (SBCs) [6] are in the signaling path between User Agents (UAs). Therefore, we need the ability to identify each communication session through a single SIP header field, regardless of which types of SIP servers are in the signaling path between UAs. For messages that create a dialog, each message within the same dialog MUST use the same session identifier.
对于不涉及SIP服务器或仅涉及SIP代理的SIP消息传递，Call ID header字段值充分标识事务（参见[1]第17节）或对话框（参见[1]第12节）中的每个SIP消息。当B2BUA或会话边界控制器（SBC）[6]位于用户代理（UAs）之间的信令路径中时，情况并非如此。因此，我们需要能够通过单个SIP头字段识别每个通信会话，而不管UAs之间的信令路径中有哪些类型的SIP服务器。对于创建对话框的消息，同一对话框中的每条消息都必须使用相同的会话标识符。
Derived Requirements: All Requirements in Section 5.
衍生需求：第5节中的所有需求。
A communication session might originate on an H.323 [2] endpoint and pass through an SBC before ultimately reaching a terminating SIP user agent. Likewise, a call might originate on a SIP user agent and terminate on an H.323 endpoint. It MUST be possible to identify such sessions end-to-end across the plurality of devices, networks, or administrative domains.
通信会话可能起源于H.323[2]端点，并在最终到达终止的SIP用户代理之前通过SBC。同样，呼叫可能在SIP用户代理上发起，并在H.323端点上终止。必须能够跨多个设备、网络或管理域端到端地识别这样的会话。
It is anticipated that the ITU-T will define protocol elements for H.323 to make the end-to-end signaling possible.
预计ITU-T将为H.323定义协议元素，以使端到端信令成为可能。
Derived Requirements: REQ5, REQ7 (Section 5).
衍生需求：需求5、需求7（第5节）。
UA A and UA B communicate using SIP messaging with a SIP B2BUA acting as a middlebox that belongs to a SIP service provider. For privacy reasons, the B2BUA changes the SIP header fields that reveal information related to the SIP users, devices, or domain identities. The service provider uses an external device to monitor and log all SIP traffic coming to and from the B2BUA. In the case of failures reported by the customer or when security issues arise (e.g., theft of service), the service provider has to analyze the logs from the past several days or weeks and then correlates those messages that were messages for a single end-to-end SIP session.
UA A和UA B使用SIP消息传递与充当属于SIP服务提供商的中间盒的SIP B2BUA进行通信。出于隐私原因，B2BUA更改SIP头字段，以显示与SIP用户、设备或域身份相关的信息。服务提供商使用外部设备监控和记录所有进出B2BUA的SIP流量。如果客户报告了故障或出现了安全问题（例如，服务被盗），服务提供商必须分析过去几天或几周的日志，然后关联那些作为单个端到端SIP会话的消息。
For this scenario, we must consider three particular use cases:
对于这种情况，我们必须考虑三个特定的用例：
a) UAs A and B support the end-to-end session identifier.
a) UAs A和B支持端到端会话标识符。
Derived Requirements: REQ1, REQ3, REQ4, REQ6.
衍生需求：需求1、需求3、需求4、需求6。
b) Only UA A supports the end-to-end session identifier; UA B does not.
b) 只有UA A支持端到端会话标识符；UA B没有。
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.
衍生需求：需求1、需求3、需求4、需求5、需求6。
c) UAs A and B do not support the end-to-end session identifier.
c) UAs A和B不支持端到端会话标识符。
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.
衍生需求：需求1、需求3、需求4、需求5、需求6。
It is difficult to track which SIP messages were involved in the same call across transactions, especially when invoking supplementary services such as call transfer or call join. There exists a need for the ability to track communication sessions as they are transferred, one side at a time, until completion of the session (i.e., until a BYE is sent).
很难跨事务跟踪同一呼叫中涉及到哪些SIP消息，特别是在调用补充服务（如呼叫转移或呼叫加入）时。需要能够在通信会话传输时跟踪通信会话，每次一方，直到会话完成（即，直到发送BYE）。
Derived Requirements: REQ1, REQ2, REQ9.
衍生需求：需求1、需求2、需求9。
An after-the-fact search of SIP messages to determine which messages were part of the same transaction or call is difficult when B2BUAs and SBCs are involved in the signaling between UAs. Mapping more than one Call-ID together can be challenging because all of the values in SIP header fields on one side of the B2BUA or SBC will likely be different than those on the other side. If multiple B2BUAs and/or SBCs are in the signaling path, more than two sets of header field values will exist, creating more of a challenge. Creating a common header field value through all SIP entities will greatly reduce any challenge for the purposes of debugging, communication tracking (such as for security purposes in case of theft of service), etc.
当UAs之间的信令涉及B2BUA和SBC时，很难对SIP消息进行事后搜索，以确定哪些消息属于同一事务或呼叫。将多个呼叫ID映射在一起可能是一个挑战，因为B2BUA或SBC一侧的SIP头字段中的所有值可能与另一侧的值不同。如果信令路径中有多个B2BUA和/或SBC，则将存在两组以上的报头字段值，从而产生更多的挑战。通过所有SIP实体创建一个公共头字段值将大大减少调试、通信跟踪（例如在服务被盗的情况下出于安全目的）等方面的任何挑战。
Derived Requirements: REQ1, REQ3, REQ5, REQ6.
衍生需求：需求1、需求3、需求5、需求6。
A syntax that is too lax (e.g., one that allows special characters or a very long identifier) would make it difficult to encode the identifier in other protocols. Therefore, the syntax of the identifier should be reasonably constrained.
过于宽松的语法（例如，允许使用特殊字符或非常长的标识符的语法）将导致难以在其他协议中对标识符进行编码。因此，标识符的语法应该受到合理的约束。
Derived Requirement: REQ8.
衍生需求：需求8。
Third-party call control refers to the ability of an entity to create a call in which communication is actually between two or more parties other than the one setting up the call. For example, a B2BUA acting as a third-party controller could establish a call between two SIP UAs using 3PCC procedures as described in Section 4.1 of RFC 3725 [5], the flow for which is reproduced below.
第三方呼叫控制是指实体创建呼叫的能力，其中通信实际上是在两个或更多方之间进行的，而不是建立呼叫的一方。例如，作为第三方控制器的B2BUA可以使用RFC 3725[5]第4.1节所述的3PCC过程在两个SIP UAs之间建立呼叫，其流程如下所述。
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Figure 2: Session Identifier 3PCC Scenario
图2：会话标识符3PCC场景
Such a flow must result in a single session identifier being used for the communication session between UA A and UA B. This use case does not extend to three SIP UAs.
这样的流必须导致UA a和UA B之间的通信会话使用单个会话标识符。此用例不扩展到三个SIP UA。
Derived Requirement: REQ9.
衍生需求：需求9。
The following requirements are derived from the use cases and additional constraints regarding the construction of the identifier.
以下需求源自用例和关于标识符构造的附加约束。
REQ1: It MUST be possible for an administrator or an external device that monitors the SIP traffic to use the identifier to identify those dialogs, transactions, and messages that were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call).
要求1：管理员或监控SIP流量的外部设备必须能够使用标识符来识别那些在某个时间点是单个端到端SIP会话组件（例如，同一呼叫的一部分）的对话框、事务和消息。
REQ2: It MUST be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX).
REQ2：当一个会话被传输时，或者如果两个不同的会话通过中间层（例如PBX）连接在一起，则必须能够关联两个端到端会话。
REQ3: The solution MUST require that the identifier, if present, pass unchanged through SIP B2BUAs or other intermediaries.
需求3：解决方案必须要求标识符（如果存在）不变地通过SIP B2BUAs或其他中介传递。
REQ4: The identifier MUST NOT reveal any information related to any SIP user, device, or domain identity. Additionally, it MUST NOT be possible to correlate a set of session identifiers produced over a period of time with one another, or with a particular user or device. This includes any IP address, port, hostname, domain name, username, Address-of-Record, Media Access Control (MAC) address, IP address family, transport type, subscriber ID, Call-ID, tags, or other SIP header field or body parts.
要求4：标识符不得透露任何与SIP用户、设备或域标识相关的信息。此外，不能将一段时间内产生的一组会话标识符彼此关联，或与特定用户或设备关联。这包括任何IP地址、端口、主机名、域名、用户名、记录地址、媒体访问控制（MAC）地址、IP地址系列、传输类型、订户ID、呼叫ID、标签或其他SIP头字段或正文部分。
REQ5: It MUST be possible to identify SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling.
REQ5：必须能够使用端到端会话标识符来识别来自和到不支持此新标识符的端设备的SIP通信量，例如允许中介将标识符注入会话信令。
REQ6: The identifier SHOULD be unique in time and space, similar to the Call-ID.
REQ6：标识符在时间和空间上应该是唯一的，类似于Call-ID。
REQ7: The identifier SHOULD be constructed in such a way as to make it suitable for transmission in SIP [1] and H.323 [2].
要求7：标识符的构造方式应使其适合在SIP[1]和H.323[2]中传输。
REQ8: The identifier SHOULD use a restricted syntax and length so as to allow the identifier to be used in other protocols.
REQ8：标识符应使用受限的语法和长度，以便允许在其他协议中使用标识符。
REQ9: It MUST be possible to correlate two end-to-end sessions when the sessions are created by a third-party controller using 3PCC procedures as shown in Figure 1 of RFC 3725 [5].
REQ9：当会话由第三方控制器使用RFC 3725[5]图1所示的3PCC程序创建时，必须能够关联两个端到端会话。
IP multimedia networks are often comprised of a mix of session protocols like SIP [1] and H.323 [2]. A benefit of the session identifier is that it uniquely identifies a communication session end-to-end across session protocol boundaries. Therefore, the need for coordinated standardization activities across Standards Development Organizations (SDOs) is imperative.
IP多媒体网络通常由SIP[1]和H.323[2]等会话协议组成。会话标识符的一个好处是，它唯一地标识跨会话协议边界的端到端通信会话。因此，跨标准开发组织（SDO）协调标准化活动的需求势在必行。
To facilitate this, a parallel effort is underway in the ITU-T to introduce the session identifier for H.323 in such a way as to be interoperable with the procedures defined by the IETF.
为了促进这一点，ITU-T正在进行一项并行工作，以引入H.323的会话标识符，使其能够与IETF定义的程序进行互操作。
The Third Generation Partnership Project (3GPP) identified in their Release 9 the need for a session identifier for operation and maintenance purposes to correlate flows in an end-to-end communication session. 3GPP TS24.229 [7] points to the fact that the session identifier can be used to correlate SIP messages belonging to the same session. In the case where signaling passes through SIP entities like B2BUAs, the end-to-end session identifier indicates that these dialogs belong to the same end-to-end SIP communication session.
第三代合作伙伴关系项目（3GPP）在其第9版中确定，出于操作和维护目的，需要会话标识符来关联端到端通信会话中的流。3GPP TS24.229[7]指出，会话标识符可用于关联属于同一会话的SIP消息。在信令通过诸如B2BUAs的SIP实体的情况下，端到端会话标识符指示这些对话框属于相同的端到端SIP通信会话。
The security vulnerabilities, attacks, and threat models affecting other similar SIP identifiers are well documented in RFC 3261 [1] and are equally applicable to the end-to-end session identifier and subject to the same mitigating security best practices. Further, storage of the session identifier in a log file is also subject to the security considerations specified in RFC 6872 [8].
RFC 3261[1]中详细记录了影响其他类似SIP标识符的安全漏洞、攻击和威胁模型，这些漏洞、攻击和威胁模型同样适用于端到端会话标识符，并遵循相同的缓解安全最佳实践。此外，会话标识符在日志文件中的存储也受到RFC 6872[8]中规定的安全注意事项的影响。
An end-to-end identifier, if not properly constructed, could provide confidential information that would allow one to identify the individual, device, or domain initiating or terminating a communication session. In adhering to REQ4, the solution produced in accordance with these requirements MUST take appropriate measures to properly secure and obfuscate sensitive or private information that might allow one to identify a person, device, or domain. This means that the end-to-end session identifier MUST NOT reveal information elements such as the MAC address or IP address. It is outside the scope of this document to specify the implementation details of such security and privacy measures. Those details may vary with the specific construction mechanism selected for the end-to-end session identifier and therefore will be discussed in the document specifying the actual end-to-end identifier.
端到端标识符如果构造不当，可能会提供机密信息，使人们能够识别发起或终止通信会话的个人、设备或域。在遵守REQ4的过程中，根据这些要求生产的解决方案必须采取适当的措施，以正确保护和混淆敏感或私人信息，从而使人能够识别个人、设备或域。这意味着端到端会话标识符不得显示诸如MAC地址或IP地址之类的信息元素。详细说明此类安全和隐私措施的实施细节不在本文件范围内。这些细节可能因为端到端会话标识符选择的特定构造机制而异，因此将在指定实际端到端标识符的文档中讨论。
A key security consideration is to ensure that an attacker cannot surreptitiously spoof the identifier and effectively render it useless to diagnostic equipment that cannot properly correlate signaling messages due to the duplicate session identifiers that exist in the same space and time. In accordance with REQ6, this end-to-end identifier MUST be sufficiently long and random to prevent it from being guessable as well as avoid collision with another identifier. The secure transport of the identifier, need for authentication, encryption, etc. should be appropriately evaluated based on the network infrastructure, transport domain, and usage scenarios for the end-to-end session identifier.
一个关键的安全考虑是确保攻击者不能秘密欺骗标识符，并有效地使其对诊断设备无效，因为相同空间和时间中存在重复的会话标识符，因此无法正确关联信令消息。根据REQ6，该端到端标识符必须足够长且随机，以防止其被猜测，并避免与另一个标识符发生冲突。应根据网络基础设施、传输域和端到端会话标识符的使用场景，适当评估标识符的安全传输、身份验证、加密等需求。
The authors would like to acknowledge Paul Kyzivat, Christer Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, and Chris Pearce for their contribution and collaboration in developing this document.
作者感谢Paul Kyzivat、Christer Holmberg、Charles Eckel、Andy Hutton、Salvatore Loreto、Keith Drage和Chris Pearce在编写本文件过程中所做的贡献和合作。
Roland Jesske and Parthasarathi Ravindran provided substantial contributions to this document during its initial creation.
罗兰·杰西克（Roland Jesske）和帕塔萨拉西·拉文德兰（Parthasarathi Ravindran）在本文件的最初创建过程中为本文件做出了重大贡献。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Recommendation ITU-T H.323, "Packet-based multimedia communications systems", December 2009.
[2] 建议ITU-T H.323，“基于分组的多媒体通信系统”，2009年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[5] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[5] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[6] 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, April 2010.
[6] Hautakorpi，J.，Ed.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[7] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[7] 3GPP TS 24.229，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”。
[8] 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, February 2013.
[8] Gurbani，V.，Ed.，Burger，E.，Ed.，Anjali，T.，Abdelnur，H.，和O.Festor，“会话启动协议（SIP）的通用日志格式（CLF）：框架和信息模型”，RFC 6872，2013年2月。
Authors' Addresses
作者地址
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Paul E.Jones Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编：27709
Phone: +1 919 476 2048
EMail: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
Phone: +1 919 476 2048
EMail: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编27709
Phone: +1 919 392 3266
EMail: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
Phone: +1 919 392 3266
EMail: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
James Polk Cisco Systems, Inc. 3913 Treemont Circle Colleyville, TX USA
James Polk Cisco Systems，Inc.美国得克萨斯州特雷蒙特圆科利维尔3913号
Phone: +1 817 271 3552
EMail: jmpolk@cisco.com
IM: xmpp:jmpolk@cisco.com
Phone: +1 817 271 3552
EMail: jmpolk@cisco.com
IM: xmpp:jmpolk@cisco.com
Laura Liess Deutsche Telekom NP 64295 Darmstadt Heinrich-Hertz-Str. 3-7 Germany
Laura Liess Deutsche Telekom NP 64295 Darmstadt Heinrich-Hertz-Str.3-7德国
Phone: +49 6151 268 2761
EMail: laura.liess.dt@gmail.com
Phone: +49 6151 268 2761
EMail: laura.liess.dt@gmail.com
Hadriel Kaplan Oracle 71 Third Ave. Burlington, MA 01803 USA
美国马萨诸塞州伯灵顿第三大道71号哈德丽尔·卡普兰甲骨文公司01803
EMail: hadriel.kaplan@oracle.com
EMail: hadriel.kaplan@oracle.com