Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7989 G. Salgueiro
Obsoletes: 7329 C. Pearce
Category: Standards Track P. Giralt
ISSN: 2070-1721 Cisco Systems, Inc.
October 2016
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7989 G. Salgueiro
Obsoletes: 7329 C. Pearce
Category: Standards Track P. Giralt
ISSN: 2070-1721 Cisco Systems, Inc.
October 2016
End-to-End Session Identification in IP-Based Multimedia Communication Networks
基于IP的多媒体通信网络中的端到端会话识别
Abstract
摘要
This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).
本文档描述了在基于IP的多媒体通信系统中使用的端到端会话标识符，该标识符使端点、中间设备和管理系统能够识别端到端会话，将多个端点与给定的多点会议关联，在重定向通信会话时跟踪通信会话，以及将一个或多个媒体流与给定通信会话相关联。虽然标识符旨在跨多个协议工作，但本文档描述了它在会话启动协议（SIP）中的用法。
This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.
本文档还描述了现有会话标识符实现（RFC 7329）的向后兼容性机制，该机制与本文档中定义的过程完全不同。
This document obsoletes RFC 7329.
本文件淘汰了RFC 7329。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7989.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7989.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
2. Conventions Used in This Document ...............................5
3. Session Identifier Definitions, Requirements, and Use Cases .....5
4. Constructing and Conveying the Session Identifier ...............5
4.1. Constructing the Session Identifier ........................5
4.2. Conveying the Session Identifier ...........................6
5. The Session-ID Header Field .....................................8
6. Endpoint Behavior ...............................................9
7. Processing by Intermediaries ...................................11
8. Handling of Remote UUID Changes ................................14
9. Associating Endpoints in a Multipoint Conference ...............16
10. Examples of Various Call Flow Operations ......................17
10.1. Basic Call with Two UUIDs ................................18
10.2. Basic Call Transfer Using REFER ..........................22
10.3. Basic Call Transfer Using Re-INVITE ......................24
10.4. Single Focus Conferencing ................................26
10.5. Single Focus Conferencing Using a Web-Based
Conference Service .......................................28
10.6. Cascading Conference Bridges .............................30
10.6.1. Establishing a Cascaded Conference ................30
10.6.2. Calling Into Cascaded Conference Bridges ..........31
10.7. Basic 3PCC for Two UAs ...................................33
10.8. Handling in 100 Trying SIP Response and CANCEL Request ...33
10.8.1. Handling in a 100 Trying SIP Response .............34
10.8.2. Handling a CANCEL SIP Request .....................35
10.9. Out-of-Dialog REFER Transaction ..........................36
11. Compatibility with a Previous Implementation ..................37
12. Security and Privacy Considerations ...........................39
13. IANA Considerations ...........................................40
13.1. Registration of the "Session-ID" Header Field ............40
13.2. Registration of the "remote" Parameter ...................40
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
Acknowledgements ..................................................44
Dedication ........................................................44
Authors' Addresses ................................................45
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Session Identifier Definitions, Requirements, and Use Cases .....5
4. Constructing and Conveying the Session Identifier ...............5
4.1. Constructing the Session Identifier ........................5
4.2. Conveying the Session Identifier ...........................6
5. The Session-ID Header Field .....................................8
6. Endpoint Behavior ...............................................9
7. Processing by Intermediaries ...................................11
8. Handling of Remote UUID Changes ................................14
9. Associating Endpoints in a Multipoint Conference ...............16
10. Examples of Various Call Flow Operations ......................17
10.1. Basic Call with Two UUIDs ................................18
10.2. Basic Call Transfer Using REFER ..........................22
10.3. Basic Call Transfer Using Re-INVITE ......................24
10.4. Single Focus Conferencing ................................26
10.5. Single Focus Conferencing Using a Web-Based
Conference Service .......................................28
10.6. Cascading Conference Bridges .............................30
10.6.1. Establishing a Cascaded Conference ................30
10.6.2. Calling Into Cascaded Conference Bridges ..........31
10.7. Basic 3PCC for Two UAs ...................................33
10.8. Handling in 100 Trying SIP Response and CANCEL Request ...33
10.8.1. Handling in a 100 Trying SIP Response .............34
10.8.2. Handling a CANCEL SIP Request .....................35
10.9. Out-of-Dialog REFER Transaction ..........................36
11. Compatibility with a Previous Implementation ..................37
12. Security and Privacy Considerations ...........................39
13. IANA Considerations ...........................................40
13.1. Registration of the "Session-ID" Header Field ............40
13.2. Registration of the "remote" Parameter ...................40
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
Acknowledgements ..................................................44
Dedication ........................................................44
Authors' Addresses ................................................45
IP-based multimedia communication systems, such as Session Initiation Protocol (SIP) [RFC3261] and [H.323], 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）[RFC3261]和[H.323]，具有全局唯一的“呼叫标识符”的概念。该标识符旨在表示从发起设备到终止设备的端到端通信会话。这样的标识符对于故障排除、会话跟踪等非常有用。
For several reasons, however, the current call identifiers defined in SIP and H.323 are not suitable for end-to-end session identification. A fundamental issue in protocol interworking is the fact that the syntax for the call identifier in SIP and H.323 is different. Thus, if both protocols are used in a call, it is impossible to exchange the call identifier end-to-end.
然而，由于若干原因，SIP和H.323中定义的当前呼叫标识符不适合于端到端会话识别。协议互通中的一个基本问题是SIP和H.323中呼叫标识符的语法不同。因此，如果在呼叫中使用两种协议，则不可能端到端交换呼叫标识符。
Another reason why the current call identifiers are not suitable to identify a session end-to-end is that, in real-world deployments, devices such as session border controllers [RFC7092] often change the session signaling, including the value of the call identifier, as it passes through the device. While this is deliberate and useful, it makes it very difficult to track a session end-to-end.
当前呼叫标识符不适合端到端标识会话的另一个原因是，在实际部署中，诸如会话边界控制器[RFC7092]之类的设备在通过设备时经常更改会话信令，包括呼叫标识符的值。虽然这是经过深思熟虑和有用的，但它使得端到端跟踪会话非常困难。
This document defines a new identifier, referred to as the "session identifier", that is intended to overcome the issues that exist with the currently defined call identifiers used in SIP and other IP-based communication systems. The identifier defined here has been adopted by the ITU ([H.460.27]) for use in H.323-based systems, allowing for the ability to trace a session end-to-end for sessions traversing both SIP and H.323-based systems. This document defines its use in SIP.
本文档定义了一个新的标识符，称为“会话标识符”，旨在克服SIP和其他基于IP的通信系统中使用的当前定义的呼叫标识符存在的问题。此处定义的标识符已被ITU（[H.460.27]）采用，用于基于H.323的系统中，允许对穿越SIP和基于H.323的系统的会话进行端到端跟踪。本文档定义了它在SIP中的使用。
The procedures specified in this document attempt to comply with the requirements specified in [RFC7206]. The procedures also specify capabilities not mentioned in [RFC7206], shown in the call flows in Section 10. Additionally, this specification attempts to account for a previous, pre-standard version of a SIP session identifier header [RFC7329], specifying a backwards-compatibility approach in Section 11.
本文件中规定的程序试图符合[RFC7206]中规定的要求。这些过程还指定了[RFC7206]中未提及的功能，如第10节中的调用流所示。此外，本规范试图解释SIP会话标识符头[RFC7329]的早期标准版本，在第11节中指定了向后兼容性方法。
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] when they appear in ALL CAPS. These words may also appear in this document in lowercase, absent their normative meanings.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。这些词语也可能以小写形式出现在本文件中，没有其规范意义。
The term "session identifier" refers to the value of the identifier, whereas "Session-ID" refers to the header field used to convey the identifier. The session identifier is a set of two Universally Unique Identifiers (UUIDs) and each element of that set is simply referred to herein as a "UUID".
术语“会话标识符”是指标识符的值，而“会话ID”是指用于传递标识符的头字段。会话标识符是两个通用唯一标识符（UUID）的集合，该集合的每个元素在本文中被简单地称为“UUID”。
Throughout this document, the term "endpoint" refers to a SIP User Agent (UA) that either initiates or terminates a SIP session, such as a user's mobile phone or a conference server, but excludes entities such as Back-to-Back User Agents (B2BUAs) that are generally located along the call-signaling path between endpoints. The term "intermediary" refers to any entity along the call-signaling path between the aforementioned endpoints, including B2BUAs and SIP proxies. In certain scenarios, intermediaries are allowed to originate and terminate SIP messages without an endpoint being part of the session or transaction. An intermediary may be performing interworking between different protocols (e.g., SIP and H.323) that support the session identifier defined in this document.
在本文档中，术语“端点”是指发起或终止SIP会话（例如用户的移动电话或会议服务器）的SIP用户代理（UA），但不包括通常位于端点之间的呼叫信令路径上的诸如背靠背用户代理（b2bua）的实体。术语“中介”是指在前述端点之间沿着呼叫信令路径的任何实体，包括B2BUAs和SIP代理。在某些场景中，允许中介发起和终止SIP消息，而不需要端点作为会话或事务的一部分。中介可以在支持本文档中定义的会话标识符的不同协议（例如，SIP和H.323）之间执行互通。
Requirements and use cases for the end-to-end session identifier, along with the definition of "session identifier", "communication session", and "end-to-end" can be found in [RFC7206]. Throughout this document, the term "session" refers to a "communication session" as defined in [RFC7206].
端到端会话标识符的要求和用例以及“会话标识符”、“通信会话”和“端到端”的定义见[RFC7206]。在本文件中，术语“会话”指的是[RFC7206]中定义的“通信会话”。
As mentioned in Section 6.1 of [RFC7206], the ITU-T undertook a parallel effort to define compatible procedures for an H.323 session identifier. They are documented in [H.460.27].
如[RFC7206]第6.1节所述，ITU-T同时致力于定义H.323会话标识符的兼容程序。它们记录在[H.460.27]中。
The session identifier comprises two UUIDs [RFC4122], with each UUID representing one of the endpoints participating in the session.
会话标识符包括两个UUID[RFC4122]，每个UUID表示参与会话的一个端点。
The version number in the UUID indicates the manner in which the UUID is generated, such as using random values or using the Media Access Control (MAC) address of the endpoint. To satisfy the requirement that no user or device information be conveyed, endpoints MUST generate version 4 (random) or version 5 (SHA-1) UUIDs to address privacy concerns related to the use of MAC addresses in UUIDs.
UUID中的版本号表示生成UUID的方式，例如使用随机值或使用端点的媒体访问控制（MAC）地址。为了满足不传输用户或设备信息的要求，端点必须生成版本4（随机）或版本5（SHA-1）UUID，以解决与UUID中MAC地址使用相关的隐私问题。
When generating a version 5 UUID, endpoints or intermediaries MUST utilize the procedures defined in Section 4.3 of [RFC4122] and employ the following "namespace ID":
生成版本5 UUID时，端点或中介必须使用[RFC4122]第4.3节中定义的过程，并使用以下“命名空间ID”：
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
};
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
};
Further, the "name" to utilize for version 5 UUIDs is the concatenation of the Call-ID header-value and the "tag" parameter that appears on the "From" or "To" line associated with the device for which the UUID is created. Once an endpoint generates a UUID for a session, the UUID never changes, even if values originally used as input into its construction change over time.
此外，用于版本5 UUID的“名称”是调用ID头值和“标记”参数的串联，该参数出现在与为其创建UUID的设备相关联的“From”或“to”行上。一旦端点为会话生成UUID，即使最初用作其构造输入的值随时间而改变，UUID也不会改变。
Stateless intermediaries that insert a Session-ID header field into a SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to ensure that UUIDs for the communication session are consistently generated. If a stateless intermediary does not know the tag value for the endpoint (e.g., a new INVITE request without a To: tag value or an older SIP implementation [RFC2543] that did not include a "tag" parameter), the intermediary MUST NOT attempt to generate a UUID for that endpoint. Note that, if an intermediary is stateless and the endpoint on one end of the call is replaced with another endpoint due to some service interaction, the values used to create the UUID should change and, if so, the intermediary will compute a different UUID.
代表端点将会话ID头字段插入SIP消息的无状态中介体必须使用版本5 UUID，以确保一致生成通信会话的UUID。如果无状态中介不知道端点的标记值（例如，没有To:tag值的新INVITE请求或不包含“tag”参数的旧SIP实现[RFC2543]），则中介不得尝试为该端点生成UUID。请注意，如果中介是无状态的，并且由于某些服务交互，调用一端的端点被另一个端点替换，则用于创建UUID的值应该更改，如果是，中介将计算不同的UUID。
The SIP User Agent (UA) initiating a new session by transmitting a SIP request ("Alice"), i.e., a User Agent Client (UAC), MUST create a new, previously unused UUID and transmit that to the ultimate destination UA ("Bob"). Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS), MUST create a new, previously unused UUID and transmit that to the first UA ("Alice"). These two distinct UUIDs form what is referred to as the "session identifier" and is
SIP用户代理（UA）通过传输SIP请求（“Alice”）启动新会话，即用户代理客户端（UAC），必须创建一个新的、以前未使用的UUID，并将其传输到最终目的地UA（“Bob”）。同样，目标UA（“Bob”），即用户代理服务器（UAS），必须创建一个新的、以前未使用的UUID，并将其传输给第一个UA（“Alice”）。这两个不同的UUID构成所谓的“会话标识符”，并且是
represented in this document in set notation of the form {A,B}, where "A" is UUID value created by UA "Alice" and "B" is the UUID value created by UA "Bob". The session identifier {A,B} is equal to the session identifier {B,A}. Section 6 describes how the UUIDs selected by the source and destination UAs persist for the duration of the session.
在本文件中以{A，B}形式的集合表示法表示，其中“A”是UA“Alice”创建的UUID值，“B”是UA“Bob”创建的UUID值。会话标识符{A，B}等于会话标识符{B，A}。第6节描述了源UAs和目标UAs选择的UUID如何在会话期间保持不变。
In the case where only one UUID is known, such as when a UA first initiates a potentially dialog-initiating SIP request, the session identifier would be {A,N}, where "A" represents the UUID value transmitted by the UA "Alice", and "N" is what is referred to as the "nil UUID" [RFC4122] (see Section 5 of this document).
在仅知道一个UUID的情况下，例如当UA第一次发起潜在的发起SIP请求的对话时，会话标识符将是{a，N}，其中“a”表示由UA“Alice”发送的UUID值，“N”是所谓的“nil UUID”[RFC4122]（参见本文档第5节）。
Since SIP sessions are subject to any number of service interactions, SIP INVITE requests might be forked as sessions are established, and since conferences might be established or expanded with endpoints calling in or the conference focus calling out, the construction of the session identifier as a set of UUIDs is important.
由于SIP会话受到任意数量的服务交互的影响，SIP INVITE请求可能会随着会话的建立而分叉，并且由于会议可能会随着端点的传入或会议焦点的传出而建立或扩展，因此将会话标识符构建为一组UUID是很重要的。
To understand this better, consider that an endpoint participating in a communication session might be replaced with another, such as the case where two "legs" of a call are joined together by a Private Branch Exchange (PBX). Suppose "Alice" and "Bob" both call UA "C" ("Carol"). There would be two distinctly identifiable session identifiers, namely {A,C} and {B,C}. Then, suppose that "Carol" uses a local PBX function to join the call between herself and "Alice" with the call between herself and "Bob", resulting in a single remaining call between "Alice" and "Bob". This merged call can be identified using two UUID values assigned by each entity in the communication session, namely {A,B} in this example.
为了更好地理解这一点，考虑一个参与通信会话的端点可能被另一个会话替换，例如，一个调用的两个“腿”由一个专用分支交换机（PBX）连接在一起。假设“爱丽丝”和“鲍勃”都叫UA“C”（“卡罗尔”）。将有两个明显可识别的会话标识符，即{A，C}和{B，C}。然后，假设“Carol”使用本地PBX函数将她自己和“Alice”之间的调用与她自己和“Bob”之间的调用连接起来，从而在“Alice”和“Bob”之间生成一个剩余的调用。可以使用通信会话中每个实体分配的两个UUID值来识别这个合并调用，在本例中，这两个UUID值就是{A，B}。
In the case of forking, "Alice" might send an INVITE request that gets forked to several different endpoints. A means of identifying each of these separate communication sessions is needed; since each of the destination UAs will create its own UUID, each communication session would be uniquely identified by the values {A, B1}, {A, B2}, {A, B3}, and so on, where each of the Bn values refers to the UUID created by the different UAs to which the SIP session is forked.
在分叉的情况下，“Alice”可能会发送一个INVITE请求，该请求被分叉到多个不同的端点。需要识别这些单独通信会话中的每个会话的方法；由于每个目的地ua将创建其自己的UUID，因此每个通信会话将由值{A，B1}，{A，B2}，{A，B3}等唯一地标识，其中每个Bn值都指由SIP会话分叉到的不同ua创建的UUID。
For conferencing scenarios, it is also useful to have a two-part session identifier where the conference focus specifies the same UUID for each conference participant. This allows for correlation among the participants in a single conference. For example, in a conference with three participants, the session identifiers might be {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference focus. Only a conference focus will purposely utilize the same UUID for more than one SIP session and, even then, such reuse MUST be restricted to the participants in the same conference.
对于会议场景，具有由两部分组成的会话标识符也很有用，其中会议焦点为每个会议参与者指定相同的UUID。这使得单个会议的参与者之间能够相互关联。例如，在有三名与会者的会议中，会话标识符可能是{a，M}、{B，M}和{C，M}，其中“M”由会议焦点指定。只有会议焦点才会有目的地将同一UUID用于多个SIP会话，即使如此，这种重用也必须限制在同一会议中的参与者。
How a device acting on session identifiers processes or utilizes the session identifier is outside the scope of this document. However, devices storing a session identifier in a log file SHOULD follow the security considerations outlined in [RFC6872]. Note that the primary intent of a session identifier is for troubleshooting; therefore, it should be included in logs at rest that will be used for troubleshooting purposes.
作用于会话标识符的设备如何处理或利用会话标识符超出了本文档的范围。但是，在日志文件中存储会话标识符的设备应遵循[RFC6872]中概述的安全注意事项。请注意，会话标识符的主要目的是用于故障排除；因此，它应该包含在静态日志中，用于故障排除。
This document replaces the definition of the "Session-ID" token that was added to the definition of the element "message-header" in the SIP message grammar by [RFC7329]. The Session-ID header is a single-instance header.
本文档用[RFC7329]替换了添加到SIP消息语法中“消息头”元素定义中的“会话ID”标记的定义。会话ID标头是单个实例标头。
Each endpoint participating in a communication session has a distinct, preferably locally generated UUID associated with it. The endpoint's UUID value remains unchanged throughout the duration of the communication session. Multipoint conferences can bridge sessions from multiple endpoints and impose unique requirements defined in Section 9. An intermediary MAY generate a UUID on behalf of an endpoint that did not include a UUID of its own.
参与通信会话的每个端点都具有与之相关联的独特的、优选本地生成的UUID。端点的UUID值在整个通信会话期间保持不变。多点会议可以桥接来自多个端点的会话，并施加第9节中定义的独特要求。中介可以代表不包含自己的UUID的端点生成UUID。
The UUID values for each endpoint are inserted into the Session-ID header field of all transmitted SIP messages. The Session-ID header field has the following ABNF [RFC5234] syntax:
每个端点的UUID值插入到所有传输的SIP消息的会话ID头字段中。会话ID标头字段具有以下ABNF[RFC5234]语法：
session-id = "Session-ID" HCOLON session-id-value
会话id=“会话id”HCOLON会话id值
session-id-value = local-uuid *(SEMI sess-id-param)
会话id值=本地uuid*（半sess id参数）
local-uuid = sess-uuid / nil
local-uuid = sess-uuid / nil
remote-uuid = sess-uuid / nil
remote-uuid = sess-uuid / nil
sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]
sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]
sess-id-param = remote-param / generic-param
sess-id-param = remote-param / generic-param
remote-param = "remote" EQUAL remote-uuid
远程参数=“远程”等于远程uuid
nil = 32("0")
零=32（“0”）
The productions "SEMI", "EQUAL", and "generic-param" are defined in [RFC3261]. The production DIGIT is defined in [RFC5234].
[RFC3261]中定义了产品“半”、“相等”和“通用参数”。生产数字在[RFC5234]中定义。
The Session-ID header field MUST NOT have more than one "remote" parameter. In the case where an entity compliant with this specification is interworking with an entity that implemented a session identifier as defined in [RFC7329], the "remote" parameter may be absent; otherwise, the "remote" parameter MUST be present. The details under which those conditions apply are described in Section 11. Except for backwards compatibility with [RFC7329], the "remote" parameter MUST be present.
会话ID标头字段不能有多个“远程”参数。如果符合本规范的实体与实现[RFC7329]中定义的会话标识符的实体互通，“远程”参数可能不存在；否则，“远程”参数必须存在。第11节描述了适用这些条件的细节。除了与[RFC7329]向后兼容外，“remote”参数必须存在。
A special nil UUID value composed of 32 zeros is required in certain situations. A nil UUID is expected as the "remote-uuid" of every initial standard SIP request since the initiating endpoint would not initially know the UUID value of the remote endpoint. This nil value will get replaced by the ultimate destination UAS when that UAS generates a response message. One caveat is explained in Section 11 for a possible backwards-compatibility case. A nil UUID value is also returned by some intermediary devices that send provisional or other responses as the "local-uuid" component of the Session-ID header field value, as described in Section 7.
在某些情况下，需要由32个零组成的特殊nil UUID值。nil UUID预期为每个初始标准SIP请求的“远程UUID”，因为发起端点最初不知道远程端点的UUID值。当最终目标UAS生成响应消息时，该nil值将被该UAS替换。第11节解释了一个可能的向后兼容性情况的警告。nil UUID值也由一些中间设备返回，这些设备发送临时或其他响应作为会话ID头字段值的“本地UUID”组件，如第7节所述。
The "local-uuid" in the Session-ID header field represents the UUID value of the endpoint transmitting a message and the "remote-uuid" in the Session-ID header field represents the UUID of the endpoint's peer. For example, a Session-ID header field might appear like this:
会话ID头字段中的“本地uuid”表示发送消息的端点的uuid值，会话ID头字段中的“远程uuid”表示端点对等方的uuid。例如，会话ID标头字段可能如下所示：
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2
While this is the general form of the Session-ID header field, exceptions to syntax and procedures are detailed in subsequent sections.
虽然这是会话ID头字段的一般形式，但语法和过程的例外情况将在后续章节中详细介绍。
The UUID values are presented as strings of lowercase hexadecimal characters, with the most significant octet of the UUID appearing first.
UUID值以小写十六进制字符的字符串表示，UUID最重要的八位字节首先出现。
To comply with this specification, endpoints (non-intermediaries) MUST include a Session-ID header field value in all SIP messages transmitted as a part of a communication session. The locally generated UUID of the transmitter of the message MUST appear in the "local-uuid" portion of the Session-ID header field value. The UUID of the peer device, if known, MUST appear as the "remote" parameter following the transmitter's UUID. The nil UUID value MUST be used if the peer device's UUID is not known.
为了符合此规范，端点（非中介）必须在作为通信会话一部分传输的所有SIP消息中包含会话ID头字段值。消息发送器本地生成的UUID必须出现在会话ID头字段值的“本地UUID”部分。对等设备的UUID（如果已知）必须显示为发射机UUID后的“远程”参数。如果对等设备的UUID未知，则必须使用nil UUID值。
Once an endpoint allocates a UUID value for a communication session, the endpoint originating the request MUST NOT change that UUID value for the duration of the session, including when:
一旦端点为通信会话分配UUID值，发起请求的端点在会话期间不得更改该UUID值，包括：
o communication attempts are retried due to receipt of 4xx messages or request timeouts;
o 由于收到4xx消息或请求超时，重试通信尝试；
o the session is redirected in response to a 3xx message;
o 会话被重定向以响应3xx消息；
o a session is transferred via a REFER message [RFC3515]; or
o 通过REFER消息[RFC3515]传输会话；或
o a SIP dialog is replaced via an INVITE request with Replaces [RFC3891].
o SIP对话框通过INVITE请求替换为Replaces[RFC3891]。
An endpoint that receives a Session-ID header field MUST take note of any non-nil "local-uuid" value that it receives and assume that is the UUID of the peer endpoint within that communication session. Endpoints MUST include this received UUID value as the "remote" parameter when transmitting subsequent messages, making sure not to change this UUID value in the process of moving the value internally from the "local-uuid" field to the "remote-uuid" field.
接收会话ID头字段的端点必须注意它接收到的任何非nil“local uuid”值，并假定该值是该通信会话中对等端点的uuid。端点在传输后续消息时必须将此接收到的UUID值包含为“远程”参数，确保在将值从“本地UUID”字段内部移动到“远程UUID”字段的过程中不更改此UUID值。
If an endpoint receives a 3xx message, a REFER that directs the endpoint to a different peer, or an INVITE request with Replaces that also potentially results in communicating with a new peer, the endpoint MUST complete any message exchanges with its current peer using the existing session identifier, but it MUST NOT use the current peer's UUID value when sending the first message to what it believes may be a new peer endpoint (even if the exchange results in communicating with the same physical or logical entity). The endpoint MUST retain its own UUID value, however, as described above.
如果端点接收到3xx消息、将端点指向其他对等方的引用，或者接收到可能导致与新对等方通信的INVITE请求，则该端点必须使用现有会话标识符与其当前对等方完成任何消息交换，但在将第一条消息发送到它认为可能是新的对等端点时（即使交换导致与同一物理或逻辑实体通信），它也不能使用当前对等方的UUID值。但是，端点必须保留自己的UUID值，如上所述。
It should be noted that messages received by an endpoint might contain a "local-uuid" value that does not match what the endpoint expected its peer's UUID to be. It is also possible for an endpoint to receive a "remote-uuid" value that does not match its generated UUID for the session. Either might happen as a result of service interactions by intermediaries and MUST NOT affect how the endpoint processes the session; however, the endpoint may log this event for troubleshooting purposes.
应该注意，端点接收的消息可能包含“本地uuid”值，该值与端点期望其对等方的uuid不匹配。端点也可能接收到与其为会话生成的uuid不匹配的“远程uuid”值。这两种情况都可能是中介服务交互的结果，并且不得影响端点处理会话的方式；但是，端点可能会记录此事件以进行故障排除。
An endpoint MUST assume that the UUID value of the peer endpoint may change at any time due to service interactions. Section 8 discusses how endpoints must handle remote UUID changes.
端点必须假定对等端点的UUID值可能由于服务交互而随时发生变化。第8节讨论端点必须如何处理远程UUID更改。
It is also important to note that if an intermediary in the network forks a session, the endpoint initiating a session may receive multiple responses back from different endpoints, each of which
还需要注意的是，如果网络中的中介机构分叉会话，则发起会话的端点可能会收到来自不同端点的多个响应，每个响应
contains a different UUID ("local-uuid") value. Endpoints MUST ensure that the correct UUID value is returned in the "remote" parameter when interacting with each endpoint. The one exception is when the endpoint sends a CANCEL request, in which case the Session-ID header field value MUST be identical to the Session-ID header field value sent in the original request.
包含不同的UUID（“本地UUID”）值。端点必须确保在与每个端点交互时在“remote”参数中返回正确的UUID值。一个例外是端点发送取消请求时，在这种情况下，会话ID头字段值必须与原始请求中发送的会话ID头字段值相同。
If an endpoint receives a message that does not contain a Session-ID header field, that message must have no effect on what the endpoint believes is the UUID value of the remote endpoint. That is, the endpoint MUST NOT change the internally maintained "remote-uuid" value for the peer.
如果端点接收到不包含会话ID头字段的消息，则该消息必须对端点认为是远程端点的UUID值的内容没有影响。也就是说，端点不得更改对等方的内部维护的“远程uuid”值。
If an endpoint receives a SIP response with a non-nil "local-uuid" that is not 32 octets long, this response comes from a misbehaving implementation, and its Session-ID header field MUST be discarded. That said, the response might still be valid according to the rules within SIP [RFC3261], and it SHOULD be checked further.
如果端点接收到具有非nil“local uuid”（长度不超过32个八位字节）的SIP响应，则此响应来自行为不当的实现，并且必须丢弃其会话ID头字段。也就是说，根据SIP[RFC3261]中的规则，响应可能仍然有效，应该进一步检查。
A Multipoint Control Unit (MCU) is a special type of conferencing endpoint and is discussed in Section 9.
多点控制单元（MCU）是一种特殊类型的会议端点，将在第9节中讨论。
The following applies only to an intermediary that wishes to comply with this specification and does not impose a conformance requirement on intermediaries that elect not to provide any special treatment for the Session-ID header field. Intermediaries that do not comply with this specification might pass the header unchanged or drop it entirely.
以下内容仅适用于希望遵守本规范的中介机构，并且不会对选择不对会话ID头字段提供任何特殊处理的中介机构施加一致性要求。不符合此规范的中介可能会原封不动地传递标头或完全删除标头。
The Call-ID often reveals personal, device, domain, or other sensitive information associated with a user, which is one reason why intermediaries, such as session border controllers, sometimes alter the Call-ID. In order to ensure the integrity of the end-to-end session identifier, it is constructed in a way that does not reveal such information, removing the need for intermediaries to alter it.
呼叫ID通常会显示与用户相关的个人、设备、域或其他敏感信息，这也是中间人（如会话边界控制器）有时更改呼叫ID的原因之一。为了确保端到端会话标识符的完整性，以不显示此类信息的方式构造呼叫ID，不再需要中介机构对其进行修改。
When an intermediary receives messages from one endpoint in a communication session that causes the transmission of one or more messages toward the second endpoint in a communication session, the intermediary MUST include the Session-ID header field in the transmitted messages with the same UUID values found in the received message, except as outlined in this section and in Section 8.
当中介体在通信会话中从一个端点接收消息，导致在通信会话中向第二个端点传输一个或多个消息时，中介体必须在传输的消息中包含会话ID头字段，该字段具有在接收的消息中找到的相同UUID值，本节和第8节中概述的情况除外。
If the intermediary aggregates several responses from different endpoints, as described in Section 16.7 of [RFC3261], the intermediary MUST set the local-uuid field to the nil UUID value when
如[RFC3261]第16.7节所述，如果中介体聚合了来自不同端点的多个响应，则中介体必须在以下情况下将本地uuid字段设置为nil uuid值：
forwarding the aggregated response to the endpoint since the true UUID value of the peer is undetermined at that point. Note that an intermediary that does not implement this specification might forward a non-nil value, resulting in the originating endpoint receiving different UUID values in the responses. It is possible for this to result in the endpoint temporarily using the wrong remote UUID. Subsequent messages in the dialog should resolve the temporary mismatch as long as the endpoint follows the rules outlined in Section 8 dealing with the handling of remote UUID changes.
将聚合响应转发到端点，因为在该点未确定对等方的真实UUID值。请注意，未实现此规范的中介可能会转发非nil值，从而导致发起端点在响应中接收不同的UUID值。这可能会导致端点临时使用错误的远程UUID。只要端点遵循第8节中关于处理远程UUID更改的规则，对话框中的后续消息就应该解决临时不匹配问题。
Intermediary devices that transfer a call, such as by joining together two different "call legs", MUST properly construct a Session-ID header field that contains the UUID values associated with the endpoints involved in the joined session and correct placement of those values. As described in Section 6, the endpoint receiving a message transmitted by the intermediary will assume that the first UUID value belongs to its peer endpoint.
传输呼叫的中间设备（例如通过将两个不同的“呼叫分支”连接在一起）必须正确构造会话ID头字段，该字段包含与连接会话中涉及的端点相关联的UUID值，并正确放置这些值。如第6节所述，接收中介发送的消息的端点将假定第一个UUID值属于其对等端点。
If an intermediary receives a SIP message without a Session-ID header field or valid header field value from an endpoint for which the intermediary is not storing a "remote-uuid" value, the intermediary MAY assign a "local-uuid" value to represent that endpoint and, having done so, MUST insert that assigned value into all signaling messages on behalf of the endpoint for that dialog. In effect, the intermediary becomes dialog-stateful, and it MUST follow the endpoint procedures in Section 6 with respect to Session-ID header field value treatment with itself acting as the endpoint (for the purposes of the Session-ID header field) for which it inserted a component into the Session-ID header field value. If the intermediary is aware of the UUID value that identifies the endpoint to which a message is directed, it MUST insert that UUID value into the Session-ID header field value as the "remote-uuid" value. If the intermediary is unaware of the UUID value that identifies the receiving endpoint, it MUST use the nil UUID value as the "remote-uuid" value.
如果中介从没有存储“远程uuid”值的端点接收到没有会话ID头字段或有效头字段值的SIP消息，则中介可以分配“本地uuid”值来表示该端点，并且在这样做之后，必须代表该对话框的端点将分配的值插入到所有信令消息中。实际上，中介体变为对话状态，它必须遵循第6节中关于会话ID头字段值处理的端点过程，并将自身作为端点（出于会话ID头字段的目的），为其在会话ID头字段值中插入组件。如果中介体知道标识消息指向的端点的UUID值，则它必须将该UUID值作为“远程UUID”值插入会话ID头字段值中。如果中介不知道标识接收端点的UUID值，则它必须使用nil UUID值作为“远程UUID”值。
If an intermediary receives a SIP message without a Session-ID header field or a valid Session-ID header field value from an endpoint for which the intermediary has previously received a Session-ID and is storing a "remote-uuid" value for that endpoint, the lack of a Session-ID must have no effect on what the intermediary believes is the UUID value of the endpoint. That is, the intermediary MUST NOT change the internally maintained "remote-uuid" value for the peer.
如果中介从某个端点接收到SIP消息，而该端点之前已接收到会话ID，并且正在为该端点存储“远程uuid”值，但该端点没有会话ID头字段或有效的会话ID头字段值，缺少会话ID对中介认为端点的UUID值没有影响。也就是说，中介不得更改对等方的内部维护的“远程uuid”值。
When an intermediary originates a response, such as a provisional response or a response to a CANCEL request, the "remote-uuid" field will contain the UUID value of the receiving endpoint. When the UUID of the peer endpoint is known, the intermediary MUST insert the UUID of the peer endpoint in the "local-uuid" field of the header value.
当中介体发起响应（例如临时响应或对取消请求的响应）时，“远程uuid”字段将包含接收端点的uuid值。当对等端点的UUID已知时，中介体必须将对等端点的UUID插入头值的“本地UUID”字段中。
Otherwise, the intermediary MAY set the "local-uuid" field of the header value to the "nil" UUID value.
否则，中介可以将报头值的“local uuid”字段设置为“nil”uuid值。
When an intermediary originates a request message without first having received a SIP message that triggered the transmission of the message (e.g., sending a BYE message to terminate a call for policy reasons), the intermediary MUST, if it has knowledge of the UUID values for the two communicating endpoints, insert a Session-ID header field with the "remote-uuid" field of the header value set to the UUID value of the receiving endpoint and the "local-uuid" field of the header value set to the UUID value of the other endpoint. When the intermediary does not have knowledge of the UUID value of an endpoint in the communication session, the intermediary SHOULD set the unknown UUID value(s) to the "nil" UUID value. (If both are unknown, the Session-ID header value SHOULD NOT be included at all, since it would have no practical value.)
当中介体在没有首先收到触发消息传输的SIP消息的情况下发起请求消息时（例如，出于策略原因发送BYE消息以终止呼叫），如果中介体知道两个通信端点的UUID值，插入会话ID标头字段，其中标头值的“远程uuid”字段设置为接收端点的uuid值，标头值的“本地uuid”字段设置为其他端点的uuid值。当中介不知道通信会话中端点的UUID值时，中介应将未知UUID值设置为“nil”UUID值。（如果两者都未知，则根本不应包括会话ID标头值，因为它没有实际价值。）
With respect to the previous two paragraphs, note that if an intermediary transmits a "nil" UUID value, the receiving endpoint might use that value in subsequent messages it sends. This effectively violates the requirement of maintaining an end-to-end session identifier value for the communication session if a UUID for the peer endpoint had been previously conveyed. Therefore, an intermediary MUST only send the "nil" UUID when the intermediary has not communicated with the peer endpoint to learn its UUID. This means that intermediaries SHOULD maintain state related to the UUID values for both ends of a communication session if it intends to originate messages (versus merely conveying messages). An intermediary that does not maintain this state and that originates a message as described in the previous two paragraphs MUST NOT insert a Session-ID header field in order to avoid unintended, incorrect reassignment of a UUID value.
关于前两段，请注意，如果中介发送“nil”UUID值，则接收端点可能在其发送的后续消息中使用该值。这实际上违反了在对等端点的UUID之前已被传输的情况下为通信会话维护端到端会话标识符值的要求。因此，当中介没有与对等端点通信以了解其UUID时，中介必须只发送“nil”UUID。这意味着，如果中介机构打算发起消息（而不仅仅是传递消息），那么它应该为通信会话的两端维护与UUID值相关的状态。不保持此状态且如前两段所述发起消息的中介体不得插入会话ID头字段，以避免意外错误地重新分配UUID值。
The Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding request being cancelled.
取消请求中包含的会话ID标头字段值必须与被取消的相应请求中包含的会话ID标头字段值相同。
If a SIP intermediary initiates a dialog between two endpoints in a third-party call control (3PCC [RFC3725]) scenario, the initial INVITE request will have a non-nil, locally fabricated "local-uuid" value; call this temporary UUID "X". The request will still have a nil "remote-uuid" value; call this value "N". The SIP server MUST be transaction-stateful. The UUID pair in the INVITE request will be {X,N}. A 1xx or 2xx response will have a UUID pair {A,X}. This transaction-stateful, dialog-initiating SIP server MUST replace its own UUID, i.e.,"X", with a nil UUID (i.e., {A,N}) in the INVITE request sent towards the other UAS as expected (see Section 10.7 for an example).
如果SIP中介在第三方呼叫控制（3PCC[RFC3725]）场景中启动两个端点之间的对话，则初始INVITE请求将具有非零的本地制造的“本地uuid”值；将此临时UUID称为“X”。请求仍将具有nil“remote uuid”值；将该值称为“N”。SIP服务器必须是事务状态的。INVITE请求中的UUID对将是{X，N}。1xx或2xx响应将具有UUID对{A，X}。此事务有状态对话启动SIP服务器必须在发送到其他UAS的INVITE请求中使用nil UUID（即，{a，N}）替换其自身的UUID，即“X”（示例请参见第10.7节）。
Intermediaries that manipulate messages containing a Session-ID header field SHOULD be aware of what UUID values it last sent towards an endpoint and, following any kind of service interaction initiated or affected by the intermediary, what UUID values the receiving endpoint should have knowledge of to ensure that both endpoints in the session have the correct and same UUID values. If an intermediary can determine that an endpoint might not have received a current, correct Session-ID field, the intermediary SHOULD attempt to provide the correct Session-ID header field to the endpoint such as by sending a re-INVITE request. Failure to take such measures may make troubleshooting more difficult because of the mismatched identifiers; therefore, it is strongly advised that intermediaries attempt to provide the correct session identifier if able to do so.
操纵包含会话ID头字段的消息的中介体应该知道它最后向端点发送的UUID值，并且在中介体发起或影响的任何类型的服务交互之后，接收端点应该知道哪些UUID值，以确保会话中的两个端点具有正确且相同的UUID值。如果中介可以确定端点可能没有收到当前正确的会话ID字段，则中介应该尝试向端点提供正确的会话ID头字段，例如发送重新邀请请求。由于标识符不匹配，未能采取此类措施可能使故障排除更加困难；因此，强烈建议中介机构尝试提供正确的会话标识符（如果能够）。
If an intermediary receives a SIP response with a non-nil "local-uuid" that is not 32 octets long, this response comes from a misbehaving implementation, and its Session-ID header field MUST be discarded. That said, the response might still be valid according to the rules within SIP [RFC3261], and it SHOULD be checked further.
如果中介接收到具有非nil“local uuid”（长度不超过32个八位字节）的SIP响应，则此响应来自行为不当的实现，并且必须丢弃其会话ID头字段。也就是说，根据SIP[RFC3261]中的规则，响应可能仍然有效，应该进一步检查。
An intermediary MUST assume that the UUID value of session peers may change at any time due to service interactions and MAY itself change UUID values for sessions under its control to ensure that end-to-end session identifiers are consistent for all participants in a session. Section 8 discusses how intermediaries must handle remote UUID changes if they maintain state of the session identifier.
中介体必须假设会话对等体的UUID值可能由于服务交互而在任何时候发生更改，并且中介体本身可能会更改其控制下会话的UUID值，以确保会话中所有参与者的端到端会话标识符是一致的。第8节讨论了中介体在维护会话标识符的状态时必须如何处理远程UUID更改。
An intermediary may perform protocol interworking between different IP-based communications systems, e.g., interworking between H.323 and SIP. If the intermediary supports the session identifier for both protocols for which it is interworking, it SHOULD pass the identifier between the two call legs to maintain an end-to-end identifier, regardless of protocol.
中介可以在不同的基于IP的通信系统之间执行协议互通，例如，H.323和SIP之间的互通。如果中介体支持它正在互通的两个协议的会话标识符，那么它应该在两个调用分支之间传递该标识符，以保持端到端标识符，而不管协议如何。
It is desirable to have all endpoints and intermediaries involved in a session agree upon the current session identifier when these changes occur. Due to race conditions or certain interworking scenarios, it is not always possible to guarantee session identifier consistency; however, in an attempt to ensure the highest likelihood of consistency, all endpoints and intermediaries involved in a session MUST accept a peer's new UUID under the following conditions:
当发生这些更改时，希望会话中涉及的所有端点和中介都同意当前会话标识符。由于竞争条件或某些互通场景，并不总是能够保证会话标识符的一致性；但是，为了确保一致性的最大可能性，会话中涉及的所有端点和中介体必须在以下条件下接受对等方的新UUID：
o When an endpoint or intermediary receives a mid-dialog request containing a new UUID from a peer, all responses to that request MUST contain the new UUID value as the "remote" parameter unless a subsequent successful transaction (for example, an UPDATE) contains a different UUID, in which case, the newest UUID MUST be used.
o 当端点或中介从对等方接收到包含新UUID的mid对话请求时，对该请求的所有响应必须包含新的UUID值作为“远程”参数，除非后续成功事务（例如，更新）包含不同的UUID，在这种情况下，必须使用最新的UUID。
o If an endpoint or intermediary sends a successful (2xx) or redirection (3xx) response to the request containing the new UUID value, the endpoint or intermediary MUST accept the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages unless the UUID from a subsequent transaction has already been accepted. The one exception is a CANCEL request, as outlined below.
o 如果端点或中介对包含新UUID值的请求发送成功（2xx）或重定向（3xx）响应，则端点或中介必须接受对等方的UUID，并将此新UUID作为任何后续消息的“远程”参数，除非已接受后续事务的UUID。一个例外是取消请求，如下所述。
o If the endpoint or intermediary sends a failure (4xx, 5xx, or 6xx) response, it MUST NOT accept the new UUID value and any subsequent messages MUST contain the previously stored UUID value in the "remote" parameter for any subsequent message. Note that the failure response itself will contain the new UUID value from the request in the "remote" parameter.
o 如果端点或中介发送失败（4xx、5xx或6xx）响应，则它不得接受新的UUID值，并且任何后续消息必须在任何后续消息的“remote”参数中包含先前存储的UUID值。请注意，故障响应本身将在“remote”参数中包含来自请求的新UUID值。
o When an endpoint or intermediary receives an ACK for a successful (2xx) or redirection (3xx) response with a new UUID value, it MUST accept the peer's new UUID value and include this new UUID as the "remote" parameter for any subsequent messages. If the ACK is for a failure (4xx, 5xx, or 6xx) response, the new value MUST NOT be used.
o 当端点或中介接收到带有新UUID值的成功（2xx）或重定向（3xx）响应的ACK时，它必须接受对等方的新UUID值，并将此新UUID作为任何后续消息的“远程”参数。如果ACK用于故障（4xx、5xx或6xx）响应，则不得使用新值。
o As stated in Sections 6 and 7, the Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding INVITE request. Upon receiving a CANCEL request, an endpoint or intermediary would normally send a 487 Request Terminated response (see Section 15.1.2 of [RFC3261]) which, by the rules outlined above, would result in the endpoint or intermediary not storing any UUID value contained in the CANCEL request. Section 3.8 of [RFC6141] specifies conditions where a CANCEL request can result in a 2xx response. Because a CANCEL request is not passed end-to-end and will always contain the UUID from the original INVITE request, retaining a new UUID value received in a CANCEL request may result in inconsistency with the Session-ID value stored on the endpoints and intermediaries involved in the session. To avoid this situation, an endpoint or intermediary MUST NOT accept the new UUID value received in a CANCEL request and any subsequent messages MUST contain the previously stored UUID value in the
o 如第6节和第7节所述，取消请求中包含的会话ID头字段值必须与相应INVITE请求中包含的会话ID头字段值相同。接收到取消请求后，端点或中介通常会发送487请求终止响应（参见[RFC3261]第15.1.2节），根据上述规则，这将导致端点或中介不存储取消请求中包含的任何UUID值。[RFC6141]第3.8节规定了取消请求可能导致2xx响应的条件。由于取消请求不是端到端传递的，并且始终包含来自原始INVITE请求的UUID，因此保留在取消请求中接收的新UUID值可能会导致与存储在会话中涉及的端点和中介上的会话ID值不一致。为了避免这种情况，端点或中介体不得接受在取消请求中接收到的新UUID值，并且任何后续消息都必须包含先前存储的UUID值
"remote" parameter". Note that the response to the CANCEL request will contain the UUID value from the CANCEL request in the "remote" parameter.
“远程”参数。请注意，对取消请求的响应将在“远程”参数中包含来自取消请求的UUID值。
o When an endpoint or intermediary receives a response containing a new UUID from a peer, the endpoint or intermediary MUST accept the new UUID as the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages.
o 当端点或中介从对等方接收到包含新UUID的响应时，端点或中介方必须接受新UUID作为对等方的UUID，并将此新UUID作为任何后续消息的“远程”参数。
When an intermediary accepts a new UUID from a peer, the intermediary SHOULD attempt to provide the correct Session-ID header field to other endpoints involved in the session, for example, by sending a re-INVITE request. If an intermediary receives a message with a "remote" parameter in the session identifier that does not match the updated UUID, the intermediary MUST update the "remote" parameter with the latest stored UUID.
当中介从对等方接受新的UUID时，中介应尝试向会话中涉及的其他端点提供正确的会话ID头字段，例如，通过发送重新邀请请求。如果中介接收到会话标识符中的“远程”参数与更新的UUID不匹配的消息，则中介必须使用最新存储的UUID更新“远程”参数。
If an intermediary is performing interworking between two different protocols that both support the session identifier defined in this document (e.g., SIP to H.323), UUID changes SHOULD be communicated between protocols to maintain the end-to-end session identifier.
如果中介正在两个不同的协议之间执行互通，这两个协议都支持本文档中定义的会话标识符（例如，SIP到H.323），则应在协议之间传递UUID更改，以维护端到端会话标识符。
Multipoint Control Units (MCUs) group two or more sessions into a single multipoint conference and have a conference focus responsible for maintaining the dialogs connected to it [RFC4353]. MCUs, including cascaded MCUs, MUST utilize the same UUID value ("local-uuid" portion of the Session-ID header field value) with all participants in the conference. In so doing, each individual session in the conference will have a unique session identifier (since each endpoint will create a unique UUID of its own), but will also have one UUID in common with all other participants in the conference.
多点控制单元（MCU）将两个或多个会话分组为一个多点会议，并有一个会议焦点负责维护与其连接的对话框[RFC4353]。MCU（包括级联MCU）必须与会议的所有参与者使用相同的UUID值（“会话ID头字段值的本地UUID”部分）。这样，会议中的每个单独会话将有一个唯一的会话标识符（因为每个端点将创建自己的唯一UUID），但也将有一个与会议中所有其他参与者相同的UUID。
When creating a cascaded conference, an MCU MUST convey the UUID value to be utilized for a conference via the "local-uuid" portion of the Session-ID header field value in an INVITE request to a second MCU when using SIP to establish the cascaded conference. A conference bridge, or MCU, needs a way to identify itself when contacting another MCU. [RFC4579] defines the "isfocus" Contact header field value parameter just for this purpose. The initial MCU MUST include the UUID of that particular conference in the "local-uuid" of an INVITE request to the other MCU(s) participating in that conference. Also included in this INVITE request is an "isfocus" Contact header field value parameter identifying that this INVITE request is coming from an MCU, and that this UUID is to be given out in all responses from endpoints into those MCUs participating in this
创建级联会议时，MCU必须在使用SIP建立级联会议时，通过INVITE请求中会话ID报头字段值的“本地UUID”部分将要用于会议的UUID值传递给第二个MCU。会议网桥或MCU需要一种在联系另一个MCU时识别自身的方法。[RFC4579]仅为此目的定义“isfocus”联系人标题字段值参数。初始MCU必须将该特定会议的UUID包含在对参与该会议的其他MCU的INVITE请求的“本地UUID”中。此INVITE请求中还包括一个“isfocus”联系人标头字段值参数，该参数标识此INVITE请求来自MCU，并且此UUID将在从端点到参与此请求的MCU的所有响应中发出
same conference. This ensures that a single UUID is common across all participating MCUs of the same conference, but that it is unique between different conferences.
同一次会议。这确保了单个UUID在同一会议的所有参与MCU中是通用的，但在不同会议之间是唯一的。
In the case where two existing conferences are joined, there should be a session between the two MCUs where the session identifier is comprised of the UUID values of the two conferences. This session identifier can be used to correlate the sessions between participants in the joined conference. This specification does not impose any additional requirements when two existing conferences are joined.
在加入两个现有会议的情况下，两个MCU之间应该有一个会话，其中会话标识符由两个会议的UUID值组成。此会话标识符可用于关联已加入会议的参与者之间的会话。当两个现有会议合并时，本规范不施加任何附加要求。
Intermediary devices or network-diagnostic equipment might assume that when they see two or more sessions with different session identifiers but with one UUID in common, the sessions are part of the same conference. However, the assumption that two sessions having one common UUID being part of the same conference is not always correct. In a SIP-forking scenario, for example, there might also exist what appears to be multiple sessions with a shared UUID value; this is intended. The desire is to allow for the association of related sessions, regardless of whether a session is forked or part of a conference.
中间设备或网络诊断设备可能会假设，当它们看到两个或多个会话具有不同的会话标识符，但具有一个共同的UUID时，这些会话是同一会议的一部分。但是，假设两个会话具有一个公共UUID，并且是同一个会议的一部分并不总是正确的。例如，在SIP分叉场景中，可能还存在多个具有共享UUID值的会话；这是有意的。其目的是允许相关会话的关联，而不管会话是分叉的还是会议的一部分。
Seeing something frequently makes understanding easier. With that in mind, this section includes several call flow examples with the initial UUID and the complete session identifier indicated per message, as well as examples of when the session identifier changes according to the rules within this document during certain operations/functions.
经常看东西使理解更容易。考虑到这一点，本节包括几个具有初始UUID和每个消息指示的完整会话标识符的调用流示例，以及会话标识符在某些操作/功能期间根据本文档中的规则更改的示例。
This section is for illustrative purposes only and is non-normative. In the following flows, "RTP" refers to the Real-time Transport Protocol [RFC3550].
本节仅用于说明目的，不具有规范性。在以下流程中，“RTP”指的是实时传输协议[RFC3550]。
In the examples in this section, "N" represents a nil UUID and other letters represent the unique UUID values corresponding to endpoints or MCUs.
在本节的示例中，“N”表示nil UUID，其他字母表示对应于端点或MCU的唯一UUID值。
Session-ID
--- Alice B2BUA Bob Carol
{A,N} |---INVITE F1--->| |
{A,N} | |---INVITE F2--->|
{B,A} | |<---200 OK F3---|
{B,A} |<---200 OK F4---| |
{A,B} |-----ACK F5---->| |
{A,B} | |-----ACK F6---->|
|<==============RTP==============>|
Session-ID
--- Alice B2BUA Bob Carol
{A,N} |---INVITE F1--->| |
{A,N} | |---INVITE F2--->|
{B,A} | |<---200 OK F3---|
{B,A} |<---200 OK F4---| |
{A,B} |-----ACK F5---->| |
{A,B} | |-----ACK F6---->|
|<==============RTP==============>|
Figure 1: Session-ID Creation When Alice Calls Bob
图1:Alice调用Bob时会话ID的创建
General operation of this example:
此示例的一般操作：
o UA-Alice populates the "local-uuid" portion of the Session-ID header field value.
o UA Alice填充会话ID头字段值的“本地uuid”部分。
o UA-Alice sends its UUID in the SIP INVITE request and populates the "remote" parameter with a nil value (32 zeros).
o UA Alice在SIP INVITE请求中发送其UUID，并用nil值（32个零）填充“remote”参数。
o The B2BUA receives an INVITE request with both a "local-uuid" portion of the Session-ID header field value from UA-Alice as well as the nil "remote-uuid" value and transmits the INVITE request towards UA-Bob with an unchanged Session-ID header field value.
o B2BUA从UA Alice接收具有会话ID报头字段值的“本地uuid”部分以及nil“远程uuid”值的INVITE请求，并使用未更改的会话ID报头字段值向UA Bob发送INVITE请求。
o UA-Bob receives the Session-ID and generates its "local-uuid" portion of the Session-ID header field value UUID to construct the whole/complete Session-ID header field value, at the same time transferring UA-Alice's UUID unchanged to the "remote-uuid" portion of the Session-ID header field value in the 200 OK SIP response.
o UA Bob接收会话ID并生成会话ID报头字段值uuid的“本地uuid”部分，以构造整个/完整会话ID报头字段值，同时在200 OK SIP响应中将UA Alice的uuid未更改传输到会话ID报头字段值的“远程uuid”部分。
o The B2BUA receives the 200 OK response with a complete Session-ID header field value from UA-Bob and transmits the 200 OK response towards UA-Alice with an unchanged Session-ID header field value.
o B2BUA从UA Bob接收具有完整会话ID报头字段值的200 OK响应，并向UA Alice发送具有未更改会话ID报头字段值的200 OK响应。
o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits the ACK towards the B2BUA. The construction of the Session-ID header field in this ACK is that of UA-Alice's UUID is the "local-uuid", and UA-Bob's UUID populates the "remote-uuid" portion of the header-value.
o UA Alice在从B2BUA接收到200 OK时，向B2BUA发送ACK。此ACK中会话ID报头字段的构造是UA Alice的UUID是“本地UUID”，UA Bob的UUID填充报头值的“远程UUID”部分。
o The B2BUA receives the ACK with a complete Session-ID header field from UA-Alice and transmits the ACK towards UA-Bob with an unchanged Session-ID header field value.
o B2BUA从UA Alice接收带有完整会话ID报头字段的ACK，并使用未更改的会话ID报头字段值向UA Bob发送ACK。
Below is a SIP message exchange illustrating proper use of the Session-ID header field. For the sake of brevity, non-essential headers and message bodies are omitted.
下面是SIP消息交换，说明了会话ID头字段的正确使用。为了简洁起见，省略了非必要的头和消息体。
F1 INVITE Alice -> B2BUA
F1邀请Alice->B2BUA
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（未显示Alice的SDP）
F2 INVITE B2BUA -> Bob
F2邀请B2BUA->Bob
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（未显示Alice的SDP）
F3 200 OK Bob -> B2BUA
F3 200正常鲍勃->B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（未显示鲍勃的SDP）
F4 200 OK B2BUA -> Alice
F4 200正常B2BUA->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
（未显示鲍勃的SDP）
F5 ACK Alice -> B2BUA
F5确认->B2BUA
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8
Route: <sip:server10.biloxi.example.com;lr>
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8
Route: <sip:server10.biloxi.example.com;lr>
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
F6 ACK B2BUA -> Bob
F6确认B2BUA->Bob
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.2
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8;received=10.1.3.33
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.2
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8;received=10.1.3.33
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0
The remaining examples in this section do not display the complete SIP message exchange. Instead, they simply use the set notation described in Section 4.2 to show the session identifier exchange throughout the particular call flow being illustrated.
本节中的其余示例不显示完整的SIP消息交换。相反，它们只是使用第4.2节中描述的集合表示法来显示所示的整个特定调用流中的会话标识符交换。
From the example built within Section 10.1, we proceed to this 'Basic Call Transfer using REFER' example. Note that this is a mid-dialog REFER in contrast with the out-of-dialog REFER in Section 10.9.
根据第10.1节中构建的示例，我们将继续此“使用REFER进行基本呼叫转移”示例。请注意，这是一个中间对话框参考，而不是第10.9节中的对话框外参考。
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
{B,A} | |<---re-INVITE---| |
{B,A} |<---re-INVITE---| (puts Alice on Hold) |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{B,A} | |<-----ACK-------| |
{B,A} |<-----ACK-------| | |
| | | |
{B,A} | |<----REFER------| |
{B,A} |<----REFER------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
| | | |
{A,N} |-----INVITE---->| |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{C,A} |<----200 OK-----| |
{A,C} |------ACK------>| |
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
{B,A} | |<-----BYE-------| |
{B,A} |<-----BYE-------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
| | | |
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
{B,A} | |<---re-INVITE---| |
{B,A} |<---re-INVITE---| (puts Alice on Hold) |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{B,A} | |<-----ACK-------| |
{B,A} |<-----ACK-------| | |
| | | |
{B,A} | |<----REFER------| |
{B,A} |<----REFER------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
| | | |
{A,N} |-----INVITE---->| |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{C,A} |<----200 OK-----| |
{A,C} |------ACK------>| |
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
{B,A} | |<-----BYE-------| |
{B,A} |<-----BYE-------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
| | | |
Figure 2: Call Transfer Using REFER
图2：使用REFER的呼叫转移
General operation of this example:
此示例的一般操作：
Starting from the existing Alice/Bob call described in Figure 1 of this document, which established an existing Session-ID header field value:
从本文档图1中描述的现有Alice/Bob调用开始，该调用建立了现有会话ID头字段值：
o UA-Bob requests Alice to call Carol, using a REFER transaction, as described in [RFC3515]. UA-Alice is initially put on hold, then told in the REFER who to contact with a new INVITE, in this case UA-Carol. This Alice-to-Carol dialog will have a new Call-ID; therefore, it requires a new Session-ID header field value. The wrinkle here is we can, and will, use Alice's UUID from her existing dialog with Bob in the new INVITE request to Carol.
o UA Bob要求Alice使用REFER事务调用Carol，如[RFC3515]中所述。UA Alice最初被搁置，然后在“推荐人”中被告知与新的邀请人（在本例中为UA Carol）联系。此Alice to Carol对话框将有一个新的呼叫ID；因此，它需要一个新的会话ID头字段值。这里的问题是，我们可以并且将在新的邀请Carol请求中使用Alice与Bob现有对话中的UUID。
o UA-Alice retains her UUID from the Alice-to-Bob call {A} when requesting a call with UA-Carol. This is placed in the "local-uuid" portion of the Session-ID header field value, at the same time inserting a nil "remote-uuid" value (because Carol's UA has not yet received the UUID value). This same UUID traverses the B2BUA unchanged.
o UA Alice在请求与UA Carol通话时保留来自Alice-to-Bob呼叫{A}的UUID。这被放置在会话ID头字段值的“本地uuid”部分，同时插入一个nil“远程uuid”值（因为Carol的UA尚未收到uuid值）。这个UUID不变地遍历B2BUA。
o UA-Carol receives the INVITE request with a session identifier UUID {A,N}, replaces the "A" UUID value into the "remote-uuid" portion of the Session-ID header field value and creates its own UUID {C}, and places this value in the "local-uuid" portion of the Session-ID header field value, thereby removing the "N" (nil) value altogether. This combination forms a full session identifier {C,A} in the 200 OK to the INVITE. This Session-ID header field traverses the B2BUA unchanged towards UA-Alice.
o UA Carol接收带有会话标识符UUID{a，N}的INVITE请求，将“a”UUID值替换为会话ID头字段值的“remote UUID”部分，并创建自己的UUID{C}，并将该值放置在会话ID头字段值的“local UUID”部分，从而完全删除“N”（nil）值。这种组合在200 OK中形成一个完整的会话标识符{C，a}，用于邀请。此会话ID头字段未更改地遍历B2BUA。
o UA-Alice receives the 200 OK with the session identifier {C,A} and responds to UA-Carol with an ACK (just as in Figure 1, this switches the places of the two UUID fields), and generates a NOTIFY request to Bob with a session identifier {A,B} indicating that the call transfer was successful.
o UA Alice接收会话标识符为{C，A}的200OK，并用ACK响应UA Carol（如图1所示，这将切换两个UUID字段的位置），并向Bob生成一个通知请求，其中会话标识符为{A，B}，指示呼叫转移成功。
o It does not matter which UA terminates the Alice-to-Bob call; Figure 2 shows UA-Bob terminating the call.
o 无论哪个UA终止Alice-to-Bob呼叫；图2显示UA Bob终止呼叫。
From the example built within Section 10.1, we proceed to this 'Basic Call Transfer using re-INVITE' example.
根据第10.1节中构建的示例，我们将继续此“使用重新邀请的基本呼叫转移”示例。
Alice is talking to Bob. Bob pushes a button on his phone to transfer Alice to Carol via the B2BUA (using re-INVITE).
爱丽丝正在和鲍勃说话。Bob按下手机上的按钮，通过B2BUA（使用重新邀请）将Alice转接给Carol。
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
| | | |
| | <--- (non-standard signaling) |
{A,B} | |---re-INVITE--->| |
{B,A} | |<-----200 OK----| |
{A,B} | |-----ACK------->| |
| | | |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} | |------BYE------>| |
{B,A} | |<----200 OK-----| |
| | | |
{C,A} |<--re-INVITE----| | |
{A,C} |----200 OK----->| | |
{C,A} |<-----ACK-------| | |
| (Suppose Alice modifies the session) |
{A,C} |---re-INVITE--->| | |
{A,C} | |---re-INVITE------------------->|
{C,A} | |<---200 OK----------------------|
{C,A} |<---200 OK------| | |
{A,C} |------ACK------>| | |
{A,C} | |------ACK---------------------->|
| | | |
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
| | | |
| | <--- (non-standard signaling) |
{A,B} | |---re-INVITE--->| |
{B,A} | |<-----200 OK----| |
{A,B} | |-----ACK------->| |
| | | |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} | |------BYE------>| |
{B,A} | |<----200 OK-----| |
| | | |
{C,A} |<--re-INVITE----| | |
{A,C} |----200 OK----->| | |
{C,A} |<-----ACK-------| | |
| (Suppose Alice modifies the session) |
{A,C} |---re-INVITE--->| | |
{A,C} | |---re-INVITE------------------->|
{C,A} | |<---200 OK----------------------|
{C,A} |<---200 OK------| | |
{A,C} |------ACK------>| | |
{A,C} | |------ACK---------------------->|
| | | |
Figure 3: Call Transfer Using Re-INVITE
图3：使用重新邀请的呼叫转移
General operation of this example:
此示例的一般操作：
o We assume the call between Alice and Bob from Section 10.1 is operational with session identifier {A,B}.
o 我们假设第10.1节中Alice和Bob之间的调用在会话标识符{A，B}下是可操作的。
o Bob uses non-standard signaling to the B2BUA to initiate a call transfer from Alice to Carol. This could also be initiated via a REFER message from Bob, but the signaling that follows might still be similar to the above flow. In either case, Alice is completely unaware of the call transfer until a future point in time when Alice receives a message from Carol.
o Bob使用到B2BUA的非标准信令发起从Alice到Carol的呼叫转接。这也可以通过来自Bob的REFER消息来启动，但是随后的信令可能仍然类似于上述流。无论哪种情况，Alice都完全不知道呼叫转接，直到将来Alice收到Carol的消息。
o The B2BUA sends a re-INVITE request with the session identifier {"local-uuid" = "A", "remote-uuid" = "B"} to renegotiate the session with Bob.
o B2BUA发送会话标识符为{“本地uuid”=“a”，“远程uuid”=“B”）的重新邀请请求，以与Bob重新协商会话。
o The B2BUA sends a new INVITE request with Alice's UUID {"local-uuid" = "A"} to Carol.
o B2BUA使用Alice的UUID{“local UUID”=“a”}向Carol发送一个新的INVITE请求。
o Carol receives the INVITE request and accepts the request and adds her UUID {C} to the session identifier for this session {"local-uuid" = "C", "remote-uuid" = "A"}.
o Carol收到INVITE请求并接受该请求，并将她的UUID{C}添加到此会话的会话标识符{“本地UUID”=“C”，“远程UUID”=“A”}。
o The B2BUA then terminates the call to Bob with a BYE using the session identifier {"local-uuid" = "A", "remote-uuid" = "B"}.
o B2BUA然后使用会话标识符{“local uuid”=“a”，“remote uuid”=“B”}以BYE终止对Bob的调用。
o The B2BUA sends a re-INVITE request to Alice to update Alice's view of the session identifier.
o B2BUA向Alice发送重新邀请请求，以更新Alice的会话标识符视图。
o When Alice later attempts to modify the session with a re-INVITE, Alice will send "remote-uuid" = "C" toward Carol because it had previously received the updated UUID in the re-INVITE request from the B2BUA. The B2BUA maintains the session identifier {"local-uuid" = "A", "remote-uuid" = "C"}. Carol replies with the "local-uuid" = "C", "remote-uuid" = "A" to reflect what was received in the INVITE request (which Carol already knew from previous exchanges with the B2BUA). Alice then includes "remote-uuid" = "C" in the subsequent ACK message.
o 当Alice稍后尝试使用重新邀请修改会话时，Alice将向Carol发送“remote uuid”=“C”，因为它以前在B2BUA的重新邀请请求中收到了更新的uuid。B2BUA维护会话标识符{“本地uuid”=“A”，“远程uuid”=“C”}。Carol回复为“本地uuid”=“C”，“远程uuid”=“A”，以反映在邀请请求中收到的内容（Carol在之前与B2BUA的交流中已经知道）。Alice然后在随后的ACK消息中包括“远程uuid”=“C”。
Multiple users call into a conference server (for example, an MCU) to attend one of many conferences hosted on or managed by that server. Each user has to identify which conference they want to join, but this information is not necessarily in the SIP messaging. It might be done by having a dedicated address for the conference or via an Interactive Voice Response (IVR), as assumed in this example and depicted with the use of M1, M2, and M3. Each user in this example goes through a two-step process of signaling to gain entry onto their conference call, which the conference focus identifies as "M".
多个用户呼叫会议服务器（例如，MCU）以参加由该服务器主持或管理的多个会议之一。每个用户都必须确定他们想要加入哪个会议，但SIP消息中不一定包含此信息。这可以通过为会议提供专用地址或通过交互式语音应答（IVR）来实现，如本示例中所假设的，并使用M1、M2和M3来描述。本例中的每个用户通过两步信令过程进入他们的会议呼叫，会议焦点将其标识为“M”。
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
| | | |
{A,N} |----INVITE----->| | |
{M1,A} |<---200 OK------| | |
{A,M1} |-----ACK------->| | |
|<====RTP=======>| | |
{M',A} |<---re-INVITE---| | |
{A,M'} |-----200 OK---->| | |
{M',A} |<-----ACK-------| | |
| | | |
| | | |
{B,N} | |<----INVITE-----| |
{M2,B} | |-----200 OK---->| |
{B,M2} | |<-----ACK-------| |
| |<=====RTP======>| |
{M',B} | |---re-INVITE--->| |
{B,M'} | |<----200 OK-----| |
{M',B} | |------ACK------>| |
| | | |
| | | |
{C,N} | |<--------------------INVITE-----|
{M3,C} | |---------------------200 OK---->|
{C,M3} | |<---------------------ACK-------|
| |<=====================RTP======>|
{M',C} | |-------------------re-INVITE--->|
{C,M'} | |<--------------------200 OK-----|
{M',C} | |----------------------ACK------>|
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
| | | |
{A,N} |----INVITE----->| | |
{M1,A} |<---200 OK------| | |
{A,M1} |-----ACK------->| | |
|<====RTP=======>| | |
{M',A} |<---re-INVITE---| | |
{A,M'} |-----200 OK---->| | |
{M',A} |<-----ACK-------| | |
| | | |
| | | |
{B,N} | |<----INVITE-----| |
{M2,B} | |-----200 OK---->| |
{B,M2} | |<-----ACK-------| |
| |<=====RTP======>| |
{M',B} | |---re-INVITE--->| |
{B,M'} | |<----200 OK-----| |
{M',B} | |------ACK------>| |
| | | |
| | | |
{C,N} | |<--------------------INVITE-----|
{M3,C} | |---------------------200 OK---->|
{C,M3} | |<---------------------ACK-------|
| |<=====================RTP======>|
{M',C} | |-------------------re-INVITE--->|
{C,M'} | |<--------------------200 OK-----|
{M',C} | |----------------------ACK------>|
Figure 4: Single Focus Conference Bridge
图4：单焦点会议桥
General operation of this example:
此示例的一般操作：
Alice calls into a conference server to attend a certain conference. This is a two-step operation since Alice cannot include the conference ID at this time and/or any passcode in the INVITE request. The first step is Alice's UA calling another UA to participate in a session. This will appear to be similar as the call flow in Figure 1 (in Section 10.1). What is unique about this call is the second step: the conference server sends a re-INVITE request with its second UUID, but maintaining the UUID Alice sent in the first INVITE. This subsequent UUID from the conference server will be the same for each UA that calls into this conference server participating in this same conference bridge/call, which is generated once Alice typically authenticates and identifies which bridge she wants to participate on.
Alice呼叫会议服务器以参加某个会议。这是一个两步操作，因为Alice此时不能在INVITE请求中包含会议ID和/或任何密码。第一步是Alice的UA呼叫另一个UA参与会话。这看起来与图1（第10.1节）中的调用流类似。此调用的独特之处在于第二步：会议服务器使用其第二个UUID发送重新邀请请求，但维护在第一个邀请中发送的UUID。来自会议服务器的后续UUID对于参与此同一会议网桥/呼叫的每个呼叫到此会议服务器的UA都是相同的，这是在Alice通常验证并标识她想要参与的网桥后生成的。
o Alice sends an INVITE request to the conference server with her UUID {A} and a "remote-uuid" = "N".
o Alice使用她的UUID{A}和“remote UUID”=“N”向会议服务器发送INVITE请求。
o The conference server responds with a 200 OK response, which replaces the "N" UUID with a temporary UUID ("M1") as the "local-uuid" and a "remote-uuid" = "A".
o 会议服务器以200 OK响应进行响应，该响应将“N”UUID替换为临时UUID（“M1”）作为“本地UUID”和“远程UUID”=“a”。
NOTE: this 'temporary' UUID is a real UUID; it is only temporary to the conference server because it knows that it is going to generate another UUID to replace the one just sent in the 200 OK response.
注意：此“临时”UUID是真实的UUID；这对于会议服务器来说只是暂时的，因为它知道它将生成另一个UUID来替换刚刚在200OK响应中发送的UUID。
o Once Alice, the user, gains access to the IVR for this conference server, she enters a specific conference ID and whatever passcode (if needed) to enter a specific conference call.
o 一旦用户Alice获得此会议服务器的IVR访问权，她将输入特定的会议ID和任何密码（如果需要）以输入特定的会议呼叫。
o Once the conference server is satisfied Alice has identified which conference she wants to attend (including any passcode verification), the conference server re-INVITEs Alice to the specific conference and includes the Session-ID header field value component "local-uuid" = "M'" (and "remote-uuid" = "A") for that conference. All valid participants in the same conference will receive this same UUID for identification purposes and to better enable monitoring and tracking functions.
o 一旦会议服务器确信Alice已确定她想要参加的会议（包括任何密码验证），会议服务器将重新邀请Alice参加特定会议，并包括该会议的会话ID头字段值组件“本地uuid”=“M”（和“远程uuid”=“A”）。同一会议中的所有有效参与者将收到相同的UUID，以便于识别，并更好地启用监控和跟踪功能。
o Bob goes through this two-step process of an INVITE transaction, followed by a re-INVITE transaction to get this same UUID ("M'") for the conference.
o Bob经历了邀请事务的两个步骤，然后是重新邀请事务，以获得会议的相同UUID（“M”）。
o In this example, Carol (and each additional user) goes through the same procedures as Alice and Bob to get on this same conference.
o 在本例中，Carol（以及每个其他用户）与Alice和Bob进行相同的过程，以参加相同的会议。
Alice, Bob, and Carol call into the same web-based conference. Note that this is one of many ways of implementing this functionality, and it should not be construed as the preferred way of establishing a web-based conference.
爱丽丝、鲍勃和卡罗尔参加了同一个网络会议。请注意，这是实现此功能的多种方法之一，不应将其解释为建立基于web的会议的首选方法。
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
|<** HTTPS *****>| | |
| Transaction | | |
| | | |
{M,N} |<----INVITE-----| | |
{A,M} |-----200 OK---->| | |
{M,A} |<-----ACK-------| | |
|<=====RTP======>| | |
| | | |
| |<** HTTPS *****>| |
| | Transaction | |
| | | |
{M,N} | |-----INVITE---->| |
{B,M} | |<----200 OK-----| |
{M,B} | |------ACK------>| |
| |<=====RTP======>| |
| | | |
| |<****************** HTTPS *****>|
| | Transaction |
| | | |
{M,N} | |--------------------INVITE----->|
{C,M} | |<-------------------200 OK------|
{M,C} | |---------------------ACK------->|
| |<====================RTP=======>|
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
|<** HTTPS *****>| | |
| Transaction | | |
| | | |
{M,N} |<----INVITE-----| | |
{A,M} |-----200 OK---->| | |
{M,A} |<-----ACK-------| | |
|<=====RTP======>| | |
| | | |
| |<** HTTPS *****>| |
| | Transaction | |
| | | |
{M,N} | |-----INVITE---->| |
{B,M} | |<----200 OK-----| |
{M,B} | |------ACK------>| |
| |<=====RTP======>| |
| | | |
| |<****************** HTTPS *****>|
| | Transaction |
| | | |
{M,N} | |--------------------INVITE----->|
{C,M} | |<-------------------200 OK------|
{M,C} | |---------------------ACK------->|
| |<====================RTP=======>|
Figure 5: Single Focus Web-Based Conference
图5：基于Web的单焦点会议
General operation of this example:
此示例的一般操作：
o Alice communicates with the web server that she wants to join a certain meeting by using a meeting number and including UA-Alice's contact information (phone number, URI, and/or IP address, etc.) for each device she wants for this conference call. For example, the audio and video (A/V) play-out devices could be separate units.
o Alice通过使用会议号码和UA Alice的联系信息（电话号码、URI和/或IP地址等）与web服务器通信，表示她希望加入某个会议。例如，音频和视频（A/V）播放设备可以是单独的单元。
o The Conference Focus server sends the INVITE request (Session-ID header field value components "local-uuid" = "M" and a remote UUID of "N", where "M" equals the "local-uuid" for each participant on this conference bridge) to UA-Alice to start a session with that server for this A/V conference call.
o 会议焦点服务器向UA Alice发送INVITE请求（会话ID头字段值组件“local uuid”=“M”和远程uuid“N”，其中“M”等于此会议桥上每个参与者的“local uuid”），以便为此a/V会议呼叫启动与该服务器的会话。
o Upon receiving the INVITE request from the conference focus server, Alice responds with a 200 OK. Her UA moves the "local-uuid" unchanged into the "remote-uuid" field, generates her own UUID, and places that into the "local-uuid" field to complete the Session-ID construction.
o 在收到来自会议焦点服务器的INVITE请求后，Alice以200 OK响应。她的UA将“本地uuid”原封不动地移动到“远程uuid”字段，生成她自己的uuid，并将其放入“本地uuid”字段以完成会话ID构造。
o Bob and Carol perform same function to join this same A/V conference call as Alice.
o Bob和Carol执行与Alice相同的功能来加入这个A/V电话会议。
Expanding conferencing capabilities requires cascading conference bridges. A conference bridge, or MCU, needs a way to identify itself when contacting another MCU. [RFC4579] defines the "isfocus" Contact header field value parameter just for this purpose.
扩展会议功能需要级联会议桥。会议网桥或MCU需要一种在联系另一个MCU时识别自身的方法。[RFC4579]仅为此目的定义“isfocus”联系人标题字段值参数。
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
Figure 6: MCUs Communicating Session Identifier UUID for Bridge
图6：用于网桥的MCU通信会话标识符UUID
Regardless of which MCU (1 or 2) a UA contacts for this conference, once the above exchange has been received and acknowledged, the UA will get the same {M',N} UUID pair from the MCU for the complete session identifier.
无论UA为此会议联系了哪个MCU（1或2），一旦收到并确认了上述交换，UA将从MCU获得相同的{M'，N}UUID对作为完整会话标识符。
A more complex form would be a series of MCUs all being informed of the same UUID to use for a specific conference. This series of MCUs can be informed in one of two ways:
更复杂的形式是一系列MCU，所有MCU都被告知要用于特定会议的同一UUID。可通过以下两种方式之一通知此系列MCU：
o All by one MCU (that initially generates the UUID for the conference).
o 全部由一个MCU完成（最初为会议生成UUID）。
o The MCU that generates the UUID informs one or several MCUs of this common UUID, and then they inform downstream MCUs of this common UUID that each will be using for this one conference.
o 生成UUID的MCU通知一个或多个MCU此公共UUID，然后通知下游MCU此公共UUID，每个MCU将用于此会议。
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{M',N} |-------------------------------------INVITE----->|
{L,M'} |<------------------------------------200 OK------|
{M',L} |--------------------------------------ACK------->|
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{M',N} |-------------------------------------INVITE----->|
{L,M'} |<------------------------------------200 OK------|
{M',L} |--------------------------------------ACK------->|
Figure 7: MCU Communicating Session Identifier UUID to More Than One MCU
图7:MCU将会话标识符UUID通信到多个MCU
General operation of this example:
此示例的一般操作：
o The MCU generating the session identifier UUID communicates this in a separate INVITE, having a Contact header with the "isfocus" Contact header field value parameter. This will identify the MCU as what [RFC4579] calls a "conference-aware" SIP entity.
o 生成会话标识符UUID的MCU在单独的INVITE中进行通信，具有带有“isfocus”联系人标头字段值参数的联系人标头。这将MCU识别为[RFC4579]所称的“会议感知”SIP实体。
o An MCU that receives this {M',N} UUID pair in an inter-MCU transaction can communicate the M' UUID in a manner in which it was received to construct a hierarchical cascade (though this time this second MCU would be the UAC MCU).
o 在MCU间事务中接收该{M'，N}UUID对的MCU可以以接收该M'UUID的方式来通信该M'UUID，以构造分层级联（尽管这次第二个MCU将是UAC MCU）。
o Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade.
o 一旦会议终止，级联MCU将收到终止级联的BYE消息。
Here is an example of how a UA, Robert for example, calls into a cascaded conference focus. Because MCU-1 has already contacted MCU-3 (the MCU where Robert is going to join the conference), MCU-3 already has the Session-ID (M') for this particular conference call.
下面是一个例子，举例来说，一个UA，Robert，是如何调用级联会议焦点的。因为MCU-1已经联系了MCU-3（Robert将参加会议的MCU），所以MCU-3已经有了这个特定会议呼叫的会话ID（M'）。
Session-ID
--- MCU-1 MCU-2 MCU-3 Robert
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{R,N} | | |<---INVITE-----|
(M',R} | | |----200 OK---->|
{R,M'} | | |<----ACK-------|
Session-ID
--- MCU-1 MCU-2 MCU-3 Robert
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{R,N} | | |<---INVITE-----|
(M',R} | | |----200 OK---->|
{R,M'} | | |<----ACK-------|
Figure 8: A UA Calling Into a Cascaded MCU UUID
图8：UA调用级联MCU UUID
General operation of this example:
此示例的一般操作：
o The UA, Robert in this case, INVITEs the MCU to join a particular conference call. Robert's UA does not know anything about whether this is the main MCU of the conference call or a cascaded MCU. Robert likely does not know MCUs can be cascaded, he just wants to join a particular call. As is the case with any standard implementation, he includes a nil "remote-uuid".
o UA（本例中为Robert）邀请MCU加入特定的电话会议。罗伯特的UA不知道这是电话会议的主MCU还是级联MCU。罗伯特可能不知道MCU可以级联，他只是想加入一个特定的呼叫。与任何标准实现一样，他包括一个nil“远程uuid”。
o The cascaded MCU, upon receiving this INVITE request from Robert, replaces the nil UUID with the UUID value communicated from MCU-1 for this conference call as the "local-uuid" in the SIP response, thus moving Robert's UUID "R" to the "remote-uuid" value.
o 级联MCU在收到来自Robert的此INVITE请求后，将nil UUID替换为MCU-1为此会议呼叫传递的UUID值，作为SIP响应中的“本地UUID”，从而将Robert的UUID“R”移动到“远程UUID”值。
o The ACK has the Session-ID {R,M'}, completing the three-way handshake for this call establishment. Robert has now joined the conference call originated from MCU-1.
o ACK具有会话ID{R，M'}，用于完成此呼叫建立的三方握手。罗伯特现在加入了由MCU-1发起的电话会议。
o Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade.
o 一旦会议终止，级联MCU将收到终止级联的BYE消息。
An external entity sets up calls to both Alice and Bob for them to talk to each other.
外部实体设置对Alice和Bob的调用，以使他们能够相互交谈。
Session-ID
--- Alice B2BUA Bob Carol
| | |
{X,N} |<----INVITE-----| |
{A,X} |-----200 OK---->| |
{A,N} | |----INVITE----->|
{B,A} | |<---200 OK------|
{B,A} |<-----ACK-------| |
{A,B} | |------ACK------>|
|<==============RTP==============>|
Session-ID
--- Alice B2BUA Bob Carol
| | |
{X,N} |<----INVITE-----| |
{A,X} |-----200 OK---->| |
{A,N} | |----INVITE----->|
{B,A} | |<---200 OK------|
{B,A} |<-----ACK-------| |
{A,B} | |------ACK------>|
|<==============RTP==============>|
Figure 9: 3PCC-Initiated Call between Alice and Bob
图9:3PCC发起的Alice和Bob之间的呼叫
General operation of this example:
此示例的一般操作：
o Some out-of-band procedure directs a B2BUA (or other SIP server) to have Alice and Bob talk to each other. In this case, the SIP server has to be transaction stateful, if not dialog stateful.
o 一些带外过程指示B2BUA（或其他SIP服务器）让Alice和Bob彼此对话。在这种情况下，SIP服务器必须是事务状态的，如果不是对话框状态的话。
o The SIP server INVITEs Alice to a session and uses a temporary UUID {X} and a nil UUID pairing.
o SIP服务器邀请Alice参加会话，并使用临时UUID{X}和nil UUID配对。
o Alice receives and accepts this call setup and replaces the nil UUID with her UUID {A} in the session identifier, now {A,X}.
o Alice接收并接受此调用设置，并在会话标识符（现在为{A，X}）中用她的UUID{A}替换nil UUID。
o The transaction-stateful SIP server receives Alice's UUID {A} in the local UUID portion and keeps it there; and it discards its own UUID {X}, replacing this with a nil UUID value in the INVITE request to Bob as if this came from Alice originally.
o 事务状态SIP服务器在本地UUID部分接收Alice的UUID{A}，并将其保存在那里；并且它丢弃自己的UUID{X}，在对Bob的INVITE请求中用nil UUID值替换它，就好像它最初来自Alice一样。
o Bob receives and accepts this INVITE request and adds his own UUID {B} to the session identifier, now {B,A}, for the response.
o Bob接收并接受此INVITE请求，并将自己的UUID{B}添加到会话标识符（现在为{B，A}）中，用于响应。
o The session is established.
o 会议成立。
The following two subsections show examples of the session identifier for a 100 Trying response and a CANCEL request in a single call flow.
以下两小节显示了单个调用流中100次尝试响应和取消请求的会话标识符示例。
The following 100 Trying response is taken from [RFC5359], Section 2.9 ("Call Forwarding - No Answer").
以下100次尝试响应取自[RFC5359]，第2.9节（“呼叫转移-无应答”）。
Session-ID Alice SIP Server Bob-1 Bob-2
| | | |
{A,N} |----INVITE----->| | |
{A,N} | |---INVITE---->| |
{N,A} |<--100 Trying---| | |
{B1,A} | |<-180 Ringing-| |
{B1,A} |<--180 Ringing--| | |
| | | |
| *Request Timeout* |
| | | |
{A,N} | |---CANCEL---->| |
{B1,A} | |<--200 OK-----| |
{B1,A} | |<---487-------| |
{A,B1} | |---- ACK ---->| |
| | | |
{N,A} |<-181 Call Fwd--| | |
| | | |
{A,N} | |------------------INVITE------>|
{B2,A} | |<----------------180 Ringing---|
{B2,A} |<-180 Ringing---| | |
{B2,A} | |<-----------------200 OK ------|
{B2,A} |<--200 OK-------| | |
{A,B2} |----ACK-------->| | |
{A,B2} | |------------------ACK--------->|
| | | |
|<=========== Both way RTP Established =========>|
| | | |
{A,B2} |----BYE-------->| | |
{A,B2} | |--------------------BYE------->|
{B2,A} | |<------------------200 OK------|
{B2,A} |<--200 OK-------| | |
| | | |
Session-ID Alice SIP Server Bob-1 Bob-2
| | | |
{A,N} |----INVITE----->| | |
{A,N} | |---INVITE---->| |
{N,A} |<--100 Trying---| | |
{B1,A} | |<-180 Ringing-| |
{B1,A} |<--180 Ringing--| | |
| | | |
| *Request Timeout* |
| | | |
{A,N} | |---CANCEL---->| |
{B1,A} | |<--200 OK-----| |
{B1,A} | |<---487-------| |
{A,B1} | |---- ACK ---->| |
| | | |
{N,A} |<-181 Call Fwd--| | |
| | | |
{A,N} | |------------------INVITE------>|
{B2,A} | |<----------------180 Ringing---|
{B2,A} |<-180 Ringing---| | |
{B2,A} | |<-----------------200 OK ------|
{B2,A} |<--200 OK-------| | |
{A,B2} |----ACK-------->| | |
{A,B2} | |------------------ACK--------->|
| | | |
|<=========== Both way RTP Established =========>|
| | | |
{A,B2} |----BYE-------->| | |
{A,B2} | |--------------------BYE------->|
{B2,A} | |<------------------200 OK------|
{B2,A} |<--200 OK-------| | |
| | | |
Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging
图10:100 Trying和CANCEL消息中的会话标识符
Below is the explanatory text from RFC 5359, Section 2.9, detailing what the desired behavior is in the above call flow (i.e., what the call flow is attempting to achieve).
以下是RFC 5359第2.9节的解释性文本，详细说明了上述调用流中的期望行为（即调用流试图实现的内容）。
Bob wants calls to B1 forwarded to B2 if B1 is not answered (information is known to the SIP server). Alice calls B1, and no one answers. The SIP server then places the call to B2.
如果B1没有应答，Bob希望将对B1的呼叫转发到B2（SIP服务器已知信息）。爱丽丝打电话给B1，但没人接。然后，SIP服务器将呼叫放在B2上。
General operation of this example:
此示例的一般操作：
o Alice generates an INVITE request because she wants to invite Bob to join her session. She creates a UUID as described in Section 10.1, and she places that value in the "local-uuid" field of the Session-ID header field value. Alice also generates a "remote-uuid" of nil and sends this along with the "local-uuid".
o Alice生成一个邀请请求，因为她想邀请Bob加入她的会话。她创建了一个UUID，如第10.1节所述，并将该值放在会话ID头字段值的“local UUID”字段中。Alice还生成一个“远程uuid”nil，并将其与“本地uuid”一起发送。
o The SIP server (imagine this is a B2BUA), upon receiving Alice's INVITE request, generates the optional provisional response 100 Trying. Since the SIP server has no knowledge of Bob's UUID for his part of the session identifier value, it cannot include his "local-uuid". Rather, any 100 Trying response includes Alice's UUID in the "remote-uuid" portion of the Session-ID header-value with a nil "local-uuid" value in the response. This is consistent with what Alice's UA expects to receive in any SIP response containing this UUID.
o SIP服务器（假设这是一个B2BUA）在收到Alice的INVITE请求时，生成可选的临时响应。由于SIP服务器不知道Bob部分会话标识符值的UUID，因此它不能包括他的“本地UUID”。相反，任何100次尝试的响应都会在会话ID头值的“远程UUID”部分包含Alice的UUID，在响应中包含nil“local UUID”值。这与Alice的UA期望在包含此UUID的任何SIP响应中接收的内容一致。
In the same call flow example as the 100 Trying response is a CANCEL request. Please refer to Figure 10 for the CANCEL request example.
在与100 Trying响应相同的调用流示例中，是一个取消请求。请参阅图10以了解取消请求示例。
General operation of this example:
此示例的一般操作：
o In Figure 10 above, Alice generates an INVITE request with her UUID value in the Session-ID header field.
o 在上面的图10中，Alice在会话ID头字段中使用她的UUID值生成一个INVITE请求。
o Bob-1 responds to this INVITE request with a 180 Ringing. In that response, he includes his UUID in the Session-ID header field value (i.e., {B1,A}); thus completing the Session-ID header field for this session, even though no final response has been generated by any of Bob's UAs.
o Bob-1以180响响应此邀请请求。在该响应中，他将其UUID包括在会话ID报头字段值中（即，{B1，A}）；因此，即使Bob的任何UAs没有生成最终响应，也要完成此会话的会话ID标头字段。
o While this means that if the SIP server were to generate a SIP request within this session it could include the complete SessionID, the server sends a CANCEL request and a CANCEL request always uses the same Session-ID header field as the original INVITE request. Thus, the CANCEL request would have a session identifier with the "local-uuid" = "A", and the "remote-uuid" = "N".
o 虽然这意味着，如果SIP服务器要在此会话中生成SIP请求，它可能会包含完整的会话ID，但服务器会发送取消请求，并且取消请求始终使用与原始INVITE请求相同的会话ID头字段。因此，取消请求将具有“本地uuid”=“a”和“远程uuid”=“N”的会话标识符。
o As it happens with this CANCEL, the SIP server intends to invite another UA of Bob's (i.e., B2) for Alice to communicate with.
o 当执行此取消时，SIP服务器打算邀请Bob的另一个UA（即B2）与Alice进行通信。
o In this example call flow, taken from RFC 5359, Section 2.9, a 181 Call is Being Forwarded response is sent to Alice. Since the SIP server generated this SIP request, and has no knowledge of Bob-2's
o 在这个例子中，调用流取自RFC 5359第2.9节，一个181呼叫正在转发，响应被发送到Alice。因为SIP服务器生成了这个SIP请求，并且不知道Bob-2的请求
UUID value, it cannot include that value in this 181. Thus, and for the exact reasons the 100 Trying including the session identifier value, only Alice's UUID is included in the remote-uuid component of the Session-ID header field value, with a nil UUID present in the "local-uuid" component.
UUID值，它不能在此181中包含该值。因此，出于包括会话标识符值的确切原因，只有Alice的UUID包含在会话ID头字段值的远程UUID组件中，而“本地UUID”组件中存在nil UUID。
The following call flow was extracted from Section 6.1 of [RFC5589] ("Successful Transfer"), with the only changes being the names of the UAs to maintain consistency within this document.
以下调用流程摘自[RFC5589]（“成功转移”）的第6.1节，唯一的更改是UAs的名称，以保持本文件的一致性。
Alice is the transferee Bob is the transferer and Carol is the transfer-target
Alice是受让人Bob是转让人Carol是转让目标
Session-ID Bob Alice Carol
| | |
{A,N} |<-----INVITE--------| |
{B,A} |------200 OK------->| |
{A,B} |<------ACK----------| |
| | |
{B,A} |--INVITE {hold}---->| |
{A,B} |<-200 OK------------| |
{B,A} |--- ACK ----------->| |
| | |
{B,A} |--REFER------------>|(Refer-To:Carol) |
{A,B} |<-202 Accepted------| |
| | |
{A,B} |<NOTIFY {100 Trying}| |
{B,A} |-200 OK------------>| |
| | |
{A,N} | |--INVITE------------>|
{C,A} | |<-200 OK-------------|
{A,C} | |---ACK-------------->|
| | |
{A,B} |<--NOTIFY {200 OK}--| |
{B,A} |---200 OK---------->| |
| | |
{B,A} |--BYE-------------->| |
{A,B} |<-200 OK------------| |
{C,A} | |<------------BYE-----|
{A,C} | |-------------200 OK->|
Session-ID Bob Alice Carol
| | |
{A,N} |<-----INVITE--------| |
{B,A} |------200 OK------->| |
{A,B} |<------ACK----------| |
| | |
{B,A} |--INVITE {hold}---->| |
{A,B} |<-200 OK------------| |
{B,A} |--- ACK ----------->| |
| | |
{B,A} |--REFER------------>|(Refer-To:Carol) |
{A,B} |<-202 Accepted------| |
| | |
{A,B} |<NOTIFY {100 Trying}| |
{B,A} |-200 OK------------>| |
| | |
{A,N} | |--INVITE------------>|
{C,A} | |<-200 OK-------------|
{A,C} | |---ACK-------------->|
| | |
{A,B} |<--NOTIFY {200 OK}--| |
{B,A} |---200 OK---------->| |
| | |
{B,A} |--BYE-------------->| |
{A,B} |<-200 OK------------| |
{C,A} | |<------------BYE-----|
{A,C} | |-------------200 OK->|
Figure 11: Out-Of-Dialog Call Transfer
图11：对话外呼叫转移
General operation of this example:
此示例的一般操作：
o Just as in Section 10.2, Figure 2, Alice invites Bob to a session, and Bob eventually transfers Alice to communicate with Carol.
o 正如第10.2节中的图2所示，Alice邀请Bob参加一个会话，Bob最终将Alice转为与Carol交流。
o What is different about the call flow in Figure 11 is that Bob's REFER is not in-dialog. Even so, this is treated as part of the same communication session and, thus, the session identifier in those messages is {A,B}.
o 图11中调用流的不同之处在于Bob的REFER不在对话框中。即使如此，这也被视为同一通信会话的一部分，因此，这些消息中的会话标识符是{A，B}。
o Alice will use her existing UUID and the nil UUID ({A,N}) in the INVITE request towards Carol (who generates UUID "C" for this session), thus maintaining the common UUID within the session identifier for this new Alice-to-Carol session.
o Alice将在对Carol的INVITE请求中使用她现有的UUID和nil UUID（{A，N}）（Carol为该会话生成UUID“C”），从而在会话标识符中为这个新的Alice-to-Carol会话维护公共UUID。
There is a much earlier document that specifies the use of a Session-ID header field (namely, [RFC7329]) that we will herewith attempt to achieve backwards compatibility. Neither Session-ID header field has any versioning information, so merely adding that this document describes "version 2" is insufficient. This section contains the set of rules for compatibility between the two specifications. Although the previous version was never standardized, it has been heavily implemented and adopted by other standards development organizations. For the purposes of this discussion, we will label the pre-standard specification of the Session-ID as the "old" version and this specification as the "new" version of the Session-ID.
有一个更早的文档指定了会话ID头字段（即，[RFC7329]）的使用，我们将在此尝试实现向后兼容性。两个会话ID头字段都没有任何版本控制信息，因此仅添加此文档描述的“版本2”是不够的。本节包含两个规范之间的兼容性规则集。尽管以前的版本从未标准化，但它已被其他标准开发组织大量实施和采用。出于本讨论的目的，我们将会话ID的预标准规范标记为“旧”版本，将本规范标记为会话ID的“新”版本。
The previous (i.e., "old") version only has a single UUID value as a Session-ID header field value, but has a generic-parameter value that can be of use.
以前的（即“旧”）版本只有一个UUID值作为会话ID头字段值，但有一个通用参数值可供使用。
In order to have an "old" version talk to an "old" version implementation, nothing needs to be done as far as the IETF is concerned.
为了让“旧”版本与“旧”版本实现对话，就IETF而言，不需要做任何事情。
In order to have a "new" version talk to a "new" version implementation, both implementations need to follow this document (to the letter) and everything should be just fine.
为了让一个“新”版本与一个“新”版本实现对话，两个实现都需要严格遵循本文档，并且一切都应该很好。
For this "new" implementation to work with the "old" implementation and an "old" implementation to work with "new" implementations, there needs to be a set of rules that all "new" implementations MUST follow if the "new" implementation will be communicating with devices that have implemented the "old" implementation.
为了使此“新”实现与“旧”实现协同工作，“旧”实现与“新”实现协同工作，如果“新”实现将与实现了“旧”实现的设备通信，则需要一组所有“新”实现都必须遵循的规则。
o Since no option tags or feature tags are to be used for distinguishing versions, the presence and order of any "remote-uuid" value within the Session-ID header field value is to be used to distinguish implementation versions.
o 由于没有选项标签或功能标签用于区分版本，因此会话ID头字段值中任何“远程uuid”值的存在和顺序将用于区分实现版本。
o If a SIP request has a "remote-uuid" value, this comes from a standard implementation, and not a pre-standard one.
o 如果SIP请求具有“远程uuid”值，则该值来自标准实现，而不是预标准实现。
o If a SIP request has no "remote-uuid" value, this comes from a pre-standard implementation, and not a standard one. In this case, one UUID is used to identify this dialog, even if the responder is a standard implementor of this specification.
o 如果SIP请求没有“remote uuid”值，则这来自于预标准实现，而不是标准实现。在这种情况下，一个UUID用于标识该对话框，即使响应者是本规范的标准实现者。
o If a SIP response has a non-nil "local-uuid" that is 32 octets long and differs from the endpoint's own UUID value, this response comes from a standard implementation.
o 如果SIP响应具有非nil的“本地uuid”，该“本地uuid”长度为32个八位字节，并且与端点自己的uuid值不同，则该响应来自标准实现。
o If a SIP response arrives that has the same value of Session-ID UUIDs in the same order as was sent, this comes from a pre-standard implementation and MUST NOT be discarded even though the "remote-uuid" may be nil. In this case, any new transaction within this dialog MUST preserve the order of the two UUIDs within all Session-ID header fields, including the ACK, until this dialog is terminated.
o 如果SIP响应的会话ID uuid值与发送的会话ID uuid值相同，则该响应来自预标准实现，即使“远程uuid”可能为零，也不得丢弃。在这种情况下，此对话框中的任何新事务都必须在所有会话ID头字段（包括ACK）中保留两个UUID的顺序，直到此对话框终止。
o If a SIP response only contains the "local-uuid" that was sent originally, this comes from a pre-standard implementation and MUST NOT be discarded for removing the nil "remote-uuid". In this case, all future transactions within this dialog MUST contain only the UUID received in the first SIP response. Any new transaction starting a new dialog from the standard Session-ID implementation MUST include a "local-uuid" and a nil "remote-uuid", even if that new dialog is between the same two UAs.
o 如果SIP响应仅包含最初发送的“本地uuid”，则这来自于预标准实现，并且不得因删除nil“远程uuid”而丢弃。在这种情况下，此对话框中的所有未来事务必须仅包含在第一个SIP响应中接收的UUID。从标准会话ID实现启动新对话框的任何新事务必须包括“本地uuid”和nil“远程uuid”，即使该新对话框位于同两个UAs之间。
o Standard implementations should not expect pre-standard implementations to be consistent in their implementation, even within the same dialog. For example, perhaps the first, third, and tenth responses contain a "remote-uuid", but all the others do not. This behavior MUST be allowed by implementations of this specification.
o 标准实现不应期望预标准实现在其实现中保持一致，即使在同一对话框中也是如此。例如，第一个、第三个和第十个响应可能包含“远程uuid”，但其他所有响应都不包含。此规范的实现必须允许此行为。
o The foregoing does not apply to other, presently unknown parameters that might be defined in the future. They are ignored for the purposes of interoperability with previous implementations.
o 上述规定不适用于将来可能定义的其他目前未知的参数。为了与以前实现的互操作性，它们被忽略。
The session identifier MUST be constructed in such a way that does not convey any user or device information as outlined in Section 4.1. This ensures that the data contained in the session identifier itself does not convey user or device information; however, the session identifier may reveal relationships between endpoints that might not be revealed by messages without a session identifier.
会话标识符的构造方式必须不传递第4.1节所述的任何用户或设备信息。这确保会话标识符本身中包含的数据不会传递用户或设备信息；然而，会话标识符可能揭示端点之间的关系，而没有会话标识符的消息可能不会揭示这些关系。
Section 4.2 requires that a UA always generate a new, previously unused UUID when transmitting a request to initiate a new session. This ensures that two unrelated sessions originating from the same UA will never have the same UUID value, thereby removing the ability for an attacker to use the session identifier to identify the two unrelated sessions as being associated with the same user.
第4.2节要求UA在发送启动新会话的请求时始终生成一个新的、以前未使用的UUID。这确保了来自同一UA的两个不相关会话永远不会具有相同的UUID值，从而消除了攻击者使用会话标识符将两个不相关会话标识为与同一用户关联的能力。
Because of the inherent property that session identifiers are conveyed end-to-end and remain unchanged by a UA for the duration of a session, the session identifier could be misused to discover relationships between two or more parties when multiple parties are involved in the same session such as the case of a redirect, transfer, or conference. For example, suppose that Alice calls Bob and Bob, via his PBX (acting as a B2BUA), forwards or transfers the call to Carol. Without use of the session identifier, an unauthorized third party that is observing the communications between Alice and Bob might not know that Alice is actually communicating with Carol. If Alice, Bob, and Carol include the session identifier as a part of the signaling messages, it is possible for the third party to observe that the UA associated with Bob changed to some other UA. If the third party also has access to signaling messages between Bob and Carol, the third party can then discover that Alice is communicating with Carol. This would be true even if all other information relating to the session is changed by the PBX, including both signaling information and media address information. That said, the session identifier would not reveal the identity of Alice, Bob, or Carol. It would only reveal the fact that those endpoints were associated with the same session.
由于会话标识符被端到端地传送并且在会话期间由UA保持不变的固有特性，当多个参与方参与同一会话时（例如重定向、传输或会议的情况），会话标识符可能被误用以发现两个或多个参与方之间的关系。例如，假设Alice给Bob打电话，Bob通过他的PBX（充当B2BUA）将电话转发或转接给Carol。如果不使用会话标识符，观察Alice和Bob之间通信的未经授权的第三方可能不知道Alice实际上正在与Carol通信。如果Alice、Bob和Carol将会话标识符作为信令消息的一部分，则第三方可能会观察到与Bob相关联的UA已更改为其他UA。如果第三方也可以访问Bob和Carol之间的信令消息，则第三方可以发现Alice正在与Carol通信。即使PBX改变了与会话相关的所有其他信息，包括信令信息和媒体地址信息，这也是正确的。也就是说，会话标识符不会透露Alice、Bob或Carol的身份。这只会揭示这些端点与同一会话相关联的事实。
This document allows for additional parameters (generic-param) to be included in the Session-ID header. This is done to allow for future extensions while preserving backward compatibility with this document. To protect privacy, the data for any generic-param included in the Session-ID header value MUST NOT include any user or
本文档允许在会话ID标头中包含其他参数（通用参数）。这样做是为了允许将来进行扩展，同时保留与本文档的向后兼容性。为保护隐私，会话ID标头值中包含的任何通用参数的数据不得包含任何用户或用户
device information. Additionally, any information conveyed through an additional parameter MUST NOT persist beyond the current session, and therefore MUST NOT be reused between unrelated sessions. Additional parameters MAY be used by future extensions of this document to correlate related communication sessions that cannot already be correlated by the procedures described in this document as long as the requirements regarding privacy and persistence defined above are followed.
设备信息。此外，通过附加参数传递的任何信息不得在当前会话之后保留，因此不得在不相关的会话之间重用。本文档的未来扩展可能会使用其他参数来关联本文档中描述的过程无法关联的相关通信会话，只要遵循上述关于隐私和持久性的要求。
An intermediary implementing a privacy service that provides user privacy as per Section 5.3 of [RFC3323] MAY choose to consider the Session-ID header as being a nonessential informational header with the understanding that doing so will impair the ability to use the session identifier for troubleshooting purposes.
An intermediary implementing a privacy service that provides user privacy as per Section 5.3 of [RFC3323] MAY choose to consider the Session-ID header as being a nonessential informational header with the understanding that doing so will impair the ability to use the session identifier for troubleshooting purposes.translate error, please retry
The following is the registration for the Session-ID header field to the "Header Name" registry at
以下是会话ID头字段在“头名称”注册表中的注册信息
<http://www.iana.org/assignments/sip-parameters>:
<http://www.iana.org/assignments/sip-parameters>:
RFC number: RFC 7989
RFC编号：RFC 7989
Header name: 'Session-ID'
标题名称：“会话ID”
Compact form: none
紧凑型：无
Note: This document replaces the Session-ID header originally registered via [RFC7329].
注意：本文档替换最初通过[RFC7329]注册的会话ID头。
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 Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+-----------+
| Session-ID | remote | No | [RFC7989] |
+--------------+----------------+-------------------+-----------+
+--------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+-----------+
| Session-ID | remote | No | [RFC7989] |
+--------------+----------------+-------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，DOI 10.17487/RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 3891，DOI 10.17487/RFC3891，2004年9月<http://www.rfc-editor.org/info/rfc3891>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，DOI 10.17487/RFC4579，2006年8月<http://www.rfc-editor.org/info/rfc4579>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[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>.
[H.323] International Telecommunications Union, "Packet-based multimedia communications systems", ITU-T Recommendation H.323, December 2009.
[H.323]国际电信联盟，“基于分组的多媒体通信系统”，ITU-T建议H.323，2009年12月。
[H.460.27] International Telecommunications Union, "End-to-End Session Identifier for H.323 Systems", ITU-T Recommendation H.460.27, November 2015.
[H.460.27]国际电信联盟，“H.323系统的端到端会话标识符”，ITU-T建议H.460.27，2015年11月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, DOI 10.17487/RFC2543, March 1999, <http://www.rfc-editor.org/info/rfc2543>.
[RFC2543]Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 2543，DOI 10.17487/RFC2543，1999年3月<http://www.rfc-editor.org/info/rfc2543>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<http://www.rfc-editor.org/info/rfc3323>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <http://www.rfc-editor.org/info/rfc3725>.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 3725，DOI 10.17487/RFC3725，2004年4月<http://www.rfc-editor.org/info/rfc3725>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，DOI 10.17487/RFC4353，2006年2月<http://www.rfc-editor.org/info/rfc4353>.
[RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>.
[RFC5359]Johnston，A.，Ed.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，DOI 10.17487/RFC5359，2008年10月<http://www.rfc-editor.org/info/rfc5359>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc5589>.
[RFC6141] Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)", RFC 6141, DOI 10.17487/RFC6141, March 2011, <http://www.rfc-editor.org/info/rfc6141>.
[RFC6141]Camarillo，G.，Ed.，Holmberg，C.，和Y.Gao，“会话启动协议（SIP）中的重新邀请和目标刷新请求处理”，RFC 6141，DOI 10.17487/RFC6141，2011年3月<http://www.rfc-editor.org/info/rfc6141>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc6872>.
[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>.
[RFC7329] Kaplan, H., "A Session Identifier for the Session Initiation Protocol (SIP)", RFC 7329, DOI 10.17487/RFC7329, August 2014, <http://www.rfc-editor.org/info/rfc7329>.
[RFC7329]Kaplan，H.，“会话启动协议（SIP）的会话标识符”，RFC 7329，DOI 10.17487/RFC7329，2014年8月<http://www.rfc-editor.org/info/rfc7329>.
Acknowledgements
致谢
The authors would like to thank Robert Sparks, Hadriel Kaplan, Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their invaluable comments during the development of this document.
作者感谢Robert Sparks、Hadriel Kaplan、Christer Holmberg、Paul Kyzivat、Brett Tate、Keith Drage、Mary Barnes、Charles Eckel、Peter Dawes、Andrew Hutton、Arun Arunachalam、Adam Gensler、Roland Jeske和Faisal Siyavuden在本文件编制过程中提出的宝贵意见。
Dedication
奉献
This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including being one of its primary editors. The IETF global community mourns his loss, and he will be missed dearly.
本文件旨在纪念詹姆斯·波尔克，一位长期的朋友和同事。James对该规范做出了重要贡献，包括作为其主要编辑之一。IETF全球社区对他的损失表示哀悼，人们将非常怀念他。
Authors' Addresses
作者地址
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
Paul E.Jones Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编：27709
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编：27709
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
Chris Pearce Cisco Systems, Inc. 2300 East President George Bush Highway Richardson, TX 75082 United States of America
Chris Pearce Cisco Systems，Inc.美国德克萨斯州理查森市东乔治布什公路2300号，邮编75082
Phone: +1 972 813 5123
Email: chrep@cisco.com
Phone: +1 972 813 5123
Email: chrep@cisco.com
Paul Giralt Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
美国北卡罗来纳州三角研究公园Kit Creek路7025号Paul Giralt Cisco Systems，Inc.美国北卡罗来纳州27709
Phone: +1 919 991 5644
Email: pgiralt@cisco.com
Phone: +1 919 991 5644
Email: pgiralt@cisco.com