Internet Engineering Task Force (IETF) H. Kaplan
Request for Comments: 7329 Oracle
Category: Informational August 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) H. Kaplan
Request for Comments: 7329 Oracle
Category: Informational August 2014
ISSN: 2070-1721
A Session Identifier for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的会话标识符
Abstract
摘要
There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.
出于故障排除的目的，需要为同一SIP会话提供一个全局唯一的会话标识符，该标识符可以跨SIP代理、背对背用户代理（B2BUA）和其他SIP中间盒一致地维护。本文提出了一个新的SIP头来携带这样一个值：Session-ID。
The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.
本文件中定义的机制已得到广泛部署，并以向后兼容的方式遵循由平淡的工作组编制的新标准跟踪文件。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7329.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7329.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements ...............................................4
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Session-ID Behavior .............................................5
4.1. Generating a Session-ID Value ..............................5
4.2. UAC Behavior ...............................................6
4.3. UAS Behavior ...............................................6
4.4. Proxy Behavior .............................................6
4.5. B2BUA Behavior .............................................7
4.5.1. B2BUA Generation of New Session-ID ..................8
4.5.2. B2BUA Insertion of Saved Session-ID .................8
5. Handling SIP Transfer Scenarios .................................8
5.1. Out-of-Dialog REFER ........................................9
5.2. Refer-To URI ...............................................9
5.3. Out-of-Dialog INVITE with Replaces .........................9
6. Session-ID Migration and Failure Scenarios .....................10
7. New 'Session-ID' Header ........................................11
7.1. Augmented BNF Definitions .................................11
8. Example Exchange ...............................................11
9. Security Considerations ........................................11
9.1. Security Considerations for Administrators ................12
9.2. Security Considerations for Session-ID Extensions .........12
10. IANA Considerations ...........................................13
11. Acknowledgments ...............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Use Cases Not in Scope for Session-ID .................15
A.1. Dialog Correlation for SIP ................................15
1. Introduction ....................................................3
1.1. Requirements ...............................................4
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Session-ID Behavior .............................................5
4.1. Generating a Session-ID Value ..............................5
4.2. UAC Behavior ...............................................6
4.3. UAS Behavior ...............................................6
4.4. Proxy Behavior .............................................6
4.5. B2BUA Behavior .............................................7
4.5.1. B2BUA Generation of New Session-ID ..................8
4.5.2. B2BUA Insertion of Saved Session-ID .................8
5. Handling SIP Transfer Scenarios .................................8
5.1. Out-of-Dialog REFER ........................................9
5.2. Refer-To URI ...............................................9
5.3. Out-of-Dialog INVITE with Replaces .........................9
6. Session-ID Migration and Failure Scenarios .....................10
7. New 'Session-ID' Header ........................................11
7.1. Augmented BNF Definitions .................................11
8. Example Exchange ...............................................11
9. Security Considerations ........................................11
9.1. Security Considerations for Administrators ................12
9.2. Security Considerations for Session-ID Extensions .........12
10. IANA Considerations ...........................................13
11. Acknowledgments ...............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Use Cases Not in Scope for Session-ID .................15
A.1. Dialog Correlation for SIP ................................15
This RFC, which contains the text of an individual Internet-Draft that was submitted originally to the DISPATCH Working Group, is being published now as an Informational document to provide a reference for later RFCs. The mechanism defined in this document has been widely deployed and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.
本RFC包含最初提交给调度工作组的单个互联网草案的文本，现作为信息性文件发布，为以后的RFC提供参考。本文件中定义的机制已被广泛部署，并以向后兼容的方式遵循，用于平淡的工作组编制的新标准跟踪文件。
The SIP [RFC3261] Call-ID header value is a globally unique identifier, which is mandatory in all requests/responses and identifies SIP messages belonging to the same dialog or registration. It provides a portion of the SIP message dialog-matching criteria and is used in such things as "Replaces" headers [RFC3891] and dialog-event packages [RFC4235] for matching to dialogs, and in SIP Identity [RFC4474] and Connected Identity [RFC4916] as one of the inputs for signing.
SIP[RFC3261]呼叫ID标头值是一个全局唯一标识符，在所有请求/响应中都是必需的，并标识属于同一对话框或注册的SIP消息。它提供了SIP消息对话框匹配标准的一部分，并用于“替换”头[RFC3891]和对话框事件包[RFC4235]以匹配对话框，并在SIP标识[RFC4474]和连接标识[RFC4916]中用作签名输入之一。
In practice, the Call-ID is often changed by SIP Back-to-Back User Agents (B2BUAs) and other such middleboxes in the logical end-to-end message path. A B2BUA logically represents a SIP User Agent Server (UAS) and User Agent Client (UAC), and as such generates a new Call-ID value for the dialog it creates on its UAC side; in fact, for some B2BUA scenarios the Call-ID *must* be changed for SIP to function properly.
在实践中，呼叫ID通常由SIP背靠背用户代理（b2bua）和逻辑端到端消息路径中的其他此类中间盒来更改。B2BUA在逻辑上表示SIP用户代理服务器（UAS）和用户代理客户端（UAC），并且因此为其在UAC侧创建的对话框生成新的呼叫ID值；事实上，对于某些B2BUA场景，必须更改呼叫ID*才能使SIP正常工作。
At the same time, there is a need for a unique, common, consistent end-to-end identifier to help troubleshoot SIP sessions and message flows as they cross SIP nodes. Troubleshooting is more complicated if multiple legs of the session are on different sides of B2BUAs, due to the lack of a common identifier such as a Call-ID to tie the legs together. Proprietary mechanisms are currently used to achieve this goal.
同时，还需要一个唯一、通用、一致的端到端标识符，以帮助解决跨SIP节点的SIP会话和消息流故障。如果会话的多个分支位于B2BUA的不同侧面，则故障排除会更加复杂，因为缺少将分支连接在一起的公共标识符，如调用ID。专有机制目前用于实现这一目标。
Therefore, in order to provide an identifier that will not be modified/replaced by B2BUAs, this document proposes a new SIP Header "Session-ID" and mandatory rules for the value of such a header. The rules are designed to be such that the value in the Session-ID header is not considered unsafe or private and does not have any property that would cause B2BUAs to change it. The goal of this document is to enable troubleshooting by providing a unique identifier for a given session that can successfully cross B2BUAs, such as Application Servers, softswitches, Private Branch Exchanges (PBXs), Session Border Controllers (SBCs), feature servers, etc.
因此，为了提供不会被B2BUAs修改/替换的标识符，本文档提出了一个新的SIP报头“会话ID”和针对此类报头的值的强制性规则。这些规则旨在确保会话ID标头中的值不被视为不安全或私有，并且不具有任何会导致B2BUAs更改它的属性。本文档的目标是通过为可成功跨越B2BUA的给定会话（如应用服务器、软交换机、专用分支交换机（PBX）、会话边界控制器（SBC）、功能服务器等）提供唯一标识符来实现故障排除。
The following requirements drive the need for Session-ID:
以下要求驱动了对会话ID的需求：
REQ1: It must be possible for an administrator to use the identifier to identify a set of dialogs that have a direct correlation with each other such that they represent the same SIP session, with as high a probability as possible.
REQ1：管理员必须能够使用标识符识别一组相互直接相关的对话框，以尽可能高的概率表示相同的SIP会话。
REQ2: It must be possible to pass the identifier through SIP B2BUAs, with as high a probability as possible. This requirement drives the following requirements:
要求2：必须能够以尽可能高的概率通过SIP B2BUAs传递标识符。此要求驱动以下要求：
REQ2a: The identifier must not reveal any information related to any SIP device or domain identity, including IP address, port, hostname, domain name, username, Address-of-Record (AoR), MAC address, IP address family, transport type, etc.
REK2A：标识符不得透露与任何SIP设备或域标识相关的任何信息，包括IP地址、端口、主机名、域名、用户名、记录地址（AoR）、MAC地址、IP地址系列、传输类型等。
REQ2b: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes, with as high a probability as possible.
REQ2b：标识符不得向其接收者透露呼叫ID、标签或任何其他SIP头或主体部分已被中间盒以尽可能高的概率更改。
REQ2c: The identifier must not be used for anything at a SIP layer to change the behavior of the SIP protocol.
REK2C：标识符不得用于SIP层的任何更改SIP协议行为的内容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the terms "header field" and "header field value" following the definition of those terms in [RFC3261]; they are not interchangeable. The "header field" is the entire SIP header's contents, including any parameters. The "header field value" is only the field-value portion, which does not include header parameters.
本文件使用了[RFC3261]中定义的术语“标题字段”和“标题字段值”；它们不能互换。“头字段”是整个SIP头的内容，包括任何参数。“标题字段值”只是字段值部分，不包括标题参数。
The general concept is that the UAC generating an out-of-dialog request generates a new, pseudorandom, unique value that remains constant for the duration of the transaction, any dialog created from that request, or for a registration. The value is inserted in a new Session-ID header field defined in this document. The UAC and UAS then reflect this header field value in all messages for the duration of the dialog. In other words, the Session-ID provides a value
一般的概念是，生成对话外请求的UAC生成一个新的、伪随机的、唯一的值，该值在事务、根据该请求创建的任何对话或注册期间保持不变。该值将插入在此文档中定义的新会话ID标头字段中。然后，UAC和UAS会在对话框期间的所有消息中反映此标题字段值。换句话说，会话ID提供了一个值
similar in nature to Call-ID, except one that crosses B2BUAs and that has no sensitive information in it.
本质上与Call ID类似，除了一个跨越B2BUAs且没有敏感信息的ID。
To aid in migration of deployments, a B2BUA or Proxy MAY also generate and/or insert the value on behalf of a UAC or UAS, if one or the other does not support this document's mechanism.
为了帮助迁移部署，如果一个或另一个不支持本文档的机制，B2BUA或代理也可以代表UAC或UAS生成和/或插入值。
Although the Session-ID concept is similar to that of Call-ID, it is not used for message dialog-matching rules in RFC 3261, nor does it change the Call-ID usage, nor does it replace the Call-ID value. Instead, this new header field provides an identifier for troubleshooting uses only.
尽管会话ID的概念与调用ID的概念类似，但它在RFC 3261中不用于消息对话框匹配规则，也不更改调用ID的用法，也不替换调用ID值。相反，此新标题字段仅为故障排除使用提供标识符。
The format of the Session-ID value is restricted, both to avoid detection of the system type that generated it and to keep it a hexadecimal representation such that it can be stored as a 128-bit binary value in log records.
会话ID值的格式受到限制，以避免检测生成该值的系统类型，并将其保留为十六进制表示形式，以便在日志记录中以128位二进制值的形式存储。
This document proposes the Session-ID header value be generated based on a defined hash mechanism for creating a 128-bit pseudorandom value and be encoded as its lowercase hex representation. The reason for specifying the mechanism is twofold: to make it impossible to determine the manufacturer of the device that generated it by looking at its format or value, and to allow devices to generate the same value if they have the same private key.
本文档建议基于定义的散列机制生成会话ID头值，用于创建128位伪随机值，并将其编码为小写十六进制表示。指定该机制的原因有两个：一是无法通过查看其格式或值来确定生成该机制的设备的制造商，二是允许设备在具有相同私钥的情况下生成相同的值。
The Session-ID value is generated by taking the Call-ID header value and SHA-1 hashing it based on HMAC (as defined in [RFC2104]) using a locally generated pseudorandom 128-bit system secret key to create a 128-bit resultant HMAC value. The secret key makes the resultant HMAC value not re-creatable by other parties; this is necessary to prevent detection of Call-IDs being changed, as required by REQ2b. Otherwise, middleboxes may have motivation to remove the Session-ID in order to hide the fact that they changed the Call-ID.
会话ID值是通过获取调用ID头值并基于HMAC（如[RFC2104]中所定义）使用本地生成的伪随机128位系统密钥对其进行SHA-1散列来生成的，以创建128位的结果HMAC值。秘密密钥使生成的HMAC值不可由其他方重新创建；这是必要的，以防止检测到呼叫ID被更改，如REQ2b所要求。否则，中间盒可能会有删除会话ID的动机，以隐藏更改呼叫ID的事实。
Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, secret_key), and the 128-bit result is encoded using lowercase alphanumeric hex representation, as defined in Section 7.1 ("Augmented BNF Definitions").
根据[RFC2104]，因此算法为HMAC-SHA-1-128（Call-ID_值、密钥），128位结果使用小写字母数字十六进制表示进行编码，如第7.1节（“增强BNF定义”）中所定义。
In order to enable troubleshooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog(s). This is described in more detail in the subsequent sections of this document.
为了对对话框内消息进行故障排除，生成器需要在给定对话框的持续时间内记住或重新创建相同的会话ID值。本文件后续章节将对此进行更详细的描述。
The rules for when a UAC generates a new Session-ID value are similar as those for Call-ID value: a UAC supporting this document's mechanism MUST generate a new unique Session-ID value when it generates an out-of-dialog request or when there is a new Registration. The exception to this rule is for out-of-dialog REFER requests or for an INVITE with a Replaces header field (see [RFC3891]), as described in Section 5.
UAC何时生成新会话ID值的规则与Call ID值的规则类似：支持此文档机制的UAC在生成对话外请求或有新注册时必须生成新的唯一会话ID值。此规则的例外情况是对话框外的REFER请求或带有替换标头字段的INVITE（请参见[RFC3891]），如第5节所述。
The UAC MUST reuse the same Session-ID value for in-dialog messages as that of the original dialog-creating request, and for any out-of-dialog request that it retransmits or re-generates in response to a 3xx that it reformulates due to failure responses. This follows the rules in [RFC3261] for Call-ID generation.
UAC必须为对话内消息重用与原始对话创建请求相同的会话ID值，以及为响应因故障响应而重新编制的3xx而重新传输或重新生成的任何对话外请求重用相同的会话ID值。这遵循[RFC3261]中关于调用ID生成的规则。
Session-ID values in Registration "refreshes" -- REGISTER requests that are used to update the expiry time but not to register a new contact -- MUST use the same Session-ID value as previous REGISTER requests. New Registrations, which add or change the Contact URI for the AoR, but do not simply delete them, MUST use a new Session-ID value. This follows the behavior of Call-ID per RFC 3261; it is reiterated here because some devices incorrectly change their Call-ID value for every re-Registration, and they MUST NOT do the same to the Session-ID.
注册“刷新”（用于更新到期时间但不注册新联系人的注册请求）中的会话ID值必须与以前的注册请求使用相同的会话ID值。新的注册必须使用新的会话ID值，这些注册可以添加或更改AoR的联系人URI，但不能简单地删除它们。这遵循RFC3261中调用ID的行为；这里重申这一点，因为某些设备在每次重新注册时都会错误地更改其呼叫ID值，并且它们不能对会话ID执行相同的操作。
The UAC MUST include the Session-ID header field in every SIP message it transmits.
UAC必须在其传输的每个SIP消息中包含会话ID头字段。
A UAS compliant with this document MUST copy a Session-ID header field (received in a request) into responses and subsequent upstream requests sent within the dialog.
符合本文档要求的UAS必须将会话ID标头字段（在请求中接收）复制到对话框中发送的响应和后续上游请求中。
If an out-of-dialog request is received without a Session-ID header field, the UAS SHOULD generate a new one for subsequent use in the transaction and dialog, as defined for a UAC, and use the same value in all responses and upstream in-dialog requests for the same dialog.
如果接收到的对话外请求没有会话ID头字段，则UAS应生成一个新的请求，以供后续在事务和对话中使用（如UAC所定义），并在所有响应和同一对话的上游对话内请求中使用相同的值。
A Proxy MUST NOT remove or modify the Session-ID header field it receives, if one is in the message. By definition, a Proxy that is compliant with RFC 3261 would not modify or remove such a header.
如果消息中有会话ID头字段，则代理不得删除或修改其接收的会话ID头字段。根据定义，符合RFC 3261的代理不会修改或删除这样的头。
If the Proxy forks a request, it MUST copy the same Session-ID header field into all the forked request copies. If the Proxy recurses requests due to 3xx redirection, or regenerates requests due to failures, it MUST use the same Session-ID header field as the original request, just as the UAC does.
如果代理分叉一个请求，它必须将相同的会话ID头字段复制到所有分叉的请求副本中。如果代理因3xx重定向而递归请求，或因失败而重新生成请求，则它必须使用与原始请求相同的会话ID头字段，就像UAC一样。
If the Proxy locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID header field from the original request into the response message it locally creates. This is necessary for troubleshooting purposes.
如果代理基于接收到的请求（包括100次尝试）在本地生成任何响应或请求，则它必须将原始请求中的任何接收到的会话ID头字段插入到它在本地创建的响应消息中。这对于故障排除是必要的。
A Proxy compliant with this document MAY generate a new Session-ID or insert a previously saved one if and only if none existed in a received message, following the rules for doing so as a B2BUA as defined in Section 4.5.
如果且仅当接收到的消息中不存在新会话ID或插入以前保存的会话ID时，符合本文档要求的代理可以按照第4.5节中定义的B2BUA规则生成新会话ID或插入先前保存的会话ID。
A B2BUA compliant with this document MUST copy:
符合本文件要求的B2BUA必须复制：
- the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC, and
- 它在作为UAS的请求中接收的会话ID头字段被转换为它作为UAC生成的相关请求，以及
- any Session-ID header field it receives in responses as a UAC into the correlated responses it generates as a UAS.
- 它在作为UAC的响应中接收的任何会话ID头字段都会被转换为它作为UAS生成的相关响应。
If the B2BUA forks or creates multiple requests as a UAC, from a request it received as a UAS, the B2BUA MUST copy the same Session-ID header field it received into all the forks/requests. If the B2BUA recurses on 3xx responses, or regenerates requests due to failures, it MUST use the same Session-ID field, just as the UAC does.
如果B2BUA作为UAC分叉或创建多个请求，则B2BUA必须将其作为UAS接收的请求复制到所有分叉/请求中的相同会话ID头字段。如果B2BUA在3xx响应上重复出现，或者由于失败而重新生成请求，那么它必须使用相同的会话ID字段，就像UAC一样。
If the B2BUA locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID field from the original request into the response message it locally creates.
如果B2BUA根据接收到的请求（包括100次尝试）在本地生成任何响应或请求，则必须将原始请求中的任何接收到的会话ID字段插入其在本地创建的响应消息中。
A B2BUA MAY remember the received Session-ID value for the duration of the transaction and dialog, for the purpose of reinsertion, in case the far end does not support this document.
B2BUA可能会在事务和对话期间记住收到的会话ID值，以便在远端不支持此文档的情况下重新插入。
In all cases, if the SIP message received by a B2BUA contains a Session-ID header field, a B2BUA compliant with this document MUST NOT remove, modify, or replace it as it "forwards" the message on the other logical UA "side" of itself.
在所有情况下，如果B2BUA接收到的SIP消息包含会话ID头字段，则符合本文档的B2BUA在其自身的另一逻辑UA“侧”上“转发”消息时，不得移除、修改或替换该消息。
If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does *not* contain a Session-ID header field, the B2BUA MAY generate a new one. The new Session-ID value MUST be calculated based on the received Call-ID of the received request, even if the B2BUA uses a different Call-ID value for requests generated on its other "side(s)". It MUST then insert the new Session-ID in any requests or responses it generates, as if it had actually received the new Session-ID from the UAC, following the rules previously defined for a B2BUA. This allows for a B2BUA to provide a migration to Session-ID deployment, on behalf of upstream nodes that do not yet support it.
如果符合本文档的B2BUA接收到对话外请求，并且该请求*不*包含会话ID头字段，B2BUA可能会生成一个新的会话ID头字段。即使B2BUA对其另一“侧”上生成的请求使用不同的呼叫ID值，也必须根据接收到的请求的接收呼叫ID计算新的会话ID值。然后，它必须按照之前为B2BUA定义的规则，将新会话ID插入到它生成的任何请求或响应中，就好像它实际从UAC收到了新会话ID一样。这允许B2BUA代表尚不支持它的上游节点提供到会话ID部署的迁移。
As defined previously, if any received message already had a Session-ID, a B2BUA compliant with this document would not replace it.
如前所述，如果任何接收到的消息已经有会话ID，则符合此文档的B2BUA不会替换它。
If a Session-ID was received in an out-of-dialog request, or the B2BUA locally generated one because none existed, the B2BUA SHOULD insert the same Session-ID field into all responses and upstream in-dialog requests if and only if a Session-ID is not already in them. This allows for a B2BUA to provide a migration to Session-ID deployment on behalf of downstream nodes that do not yet support it.
如果在对话外请求中收到会话ID，或者B2BUA本地生成的会话ID不存在，则B2BUA应在所有响应和对话请求上游插入相同的会话ID字段，前提是会话ID不在其中。这允许B2BUA代表尚未支持它的下游节点提供到会话ID部署的迁移。
The transfer or movement of SIP sessions represents a complication for a mechanism like Session-ID. On the one hand, the replacement SIP session represents a new one and could reasonably be expected to use a new Session-ID value; on the other hand, from a troubleshooting and human-user perspective, it is clearly related to, if not just a continuation of, the previous session. Since the purpose of this document's mechanism is to aid monitoring and troubleshooting, and it's not used for actual SIP protocol mechanics, the behavior defined in this section is to reuse the same Session-ID value for the replacement SIP session.
SIP会话的传输或移动表示诸如会话ID之类的机制的复杂性。一方面，替换SIP会话表示新会话，并且可以合理地预期使用新会话ID值；另一方面，从故障排除和人类用户的角度来看，它显然与上一个会话相关，如果不仅仅是上一个会话的延续。由于本文档机制的目的是帮助监控和故障排除，而不是用于实际的SIP协议机制，因此本节中定义的行为是为替换SIP会话重用相同的会话ID值。
In order to do so, the Session-ID of the "original" session is transferred as well, in the Refer-To URI of a REFER request as described in [RFC3515]. Furthermore, out-of-dialog REFER and INVITE with Replaces requests as described in [RFC3891] use the appropriate Session-ID values. This assumes, of course, that the UAs involved support the Session-ID mechanism. If they do not, then it is possible for the Session-ID to not be "carried forward" to the new
为此，如[RFC3515]中所述，在Refer请求的Refer-Refer URI中也传输“原始”会话的会话ID。此外，如[RFC3891]中所述，使用适当的会话ID值将对话框外的REFER和INVITE替换为请求。当然，这假设所涉及的UAs支持会话ID机制。如果没有，则会话ID可能不会“结转”到新会话
SIP dialog. Unfortunately, this means troubleshooting such dialogs is not improved or aided by this document's mechanism; but, it would not "break" anything at a SIP layer.
SIP对话框。不幸的是，这意味着此类对话框的故障排除没有得到本文档机制的改进或帮助；但是，它不会在SIP层“破坏”任何东西。
It should also be noted that using the same Session-ID for the transferred-to dialog means the same Session-ID now exists in two independent dialogs, because the original one may well continue due to the implicit Subscription usage created by a REFER. That implicit Subscription-based usage will continue to use the same Session-ID as the new dialog created to the transferred-to party.
还应注意的是，对Transfer to对话框使用相同的会话ID意味着相同的会话ID现在存在于两个独立的对话框中，因为原始会话ID可能会由于引用创建的隐式订阅使用而继续。这种基于订阅的隐式用法将继续使用与创建给被传输方的新对话框相同的会话ID。
In the following subsections, the term "UA" is used for User Agent. The language applies to the SIP device that creates the request, whether it be a UA or B2BUA.
在以下小节中，术语“UA”用于用户代理。该语言适用于创建请求的SIP设备，无论是UA还是B2BUA。
A UA compliant with this document MUST use the same Session-ID header field value for an out-of-dialog REFER request it generates, as the original dialog the REFER is targeted to (i.e., as if the REFER had been in-dialog). For example, if UA Bob has a SIP dialog X to Alice, and Bob sends an out-of-dialog REFER to Alice to refer her to Charlie, the Session-ID header field value of the REFER request would be the same as that used in dialog X.
符合本文档要求的UA必须为其生成的对话外引用请求使用与引用所针对的原始对话相同的会话ID标头字段值（即，就好像引用已在对话中一样）。例如，如果UA Bob向Alice发送了一个SIP对话框X，Bob向Alice发送了一个out-of-dialog REFER-to-to-to-to-Charlie，则REFER请求的会话ID头字段值将与对话框X中使用的值相同。
A UA compliant with this document MUST add the Session-ID header field as an embedded header in the Refer-To header field URI of any REFER request it generates, using the value of the session it is referring to. For example, if UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie, the Session-ID header field value embedded in the Refer-To URI of the REFER request would be the same as that used in dialog Y.
符合本文档要求的UA必须使用其引用的会话的值，将会话ID头字段作为嵌入头添加到其生成的任何引用请求的引用头字段URI中。例如，如果UA Bob将SIP对话框X发送给Alice，将对话框Y发送给Charlie，并且Bob将REFER请求发送给Alice以将她提交给Charlie，则REFER请求的REFER-REFER URI中嵌入的会话ID头字段值将与对话框Y中使用的值相同。
When generating an out-of-dialog INVITE with a Replaces header field as described in [RFC3891], a UA compliant with this document MUST use the same Session-ID header field value for the INVITE request as that used for the dialog it is replacing, if it knows the value. Typically, the UA would know the value by having received it in the Refer-To header field of a REFER, as described previously. For example, if UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie, the Session-ID header field value embedded in the Refer-To
如[RFC3891]所述，当生成带有替换头字段的对话外邀请时，符合本文档要求的UA必须为邀请请求使用与其正在替换的对话相同的会话ID头字段值（如果知道该值）。通常，UA将通过在Refer的Refer-Refer报头字段中接收该值来知道该值，如前所述。例如，如果UA Bob将SIP对话框X发送给Alice，将对话框Y发送给Charlie，并且Bob向Alice发送一个REFER请求以将她转介给Charlie，则REFER REFER中嵌入的会话ID头字段值
URI of the REFER request would be the one used in dialog Y, which Alice would use as the Session-ID header field value for her INVITE to Charlie.
引用请求的URI将是对话框Y中使用的URI，Alice将使用该URI作为她邀请Charlie的会话ID头字段值。
If the UA does not know the Session-ID of the dialog it is replacing, for example, because it is not embedded in the Refer-To URI of a received REFER, then it MUST use a new Session-ID value, calculated using the mechanism as defined in Section 4.1 with the Call-ID of the INVITE.
如果UA不知道它要替换的对话框的会话ID，例如，因为它没有嵌入到接收到的Refer的Refer-Refer URI中，那么它必须使用新的会话ID值，该值是使用第4.1节中定义的机制和INVITE的调用ID计算的。
SIP is already widely deployed on the Internet, and it is impractical to expect all UAs to be upgraded to support this document's mechanism in the near future. A solution for gradual migration is necessary and is provided by this document by allowing B2BUAs or Proxies to perform the Session-ID generator and inserter role. Even within those device types, it is impractical to expect all B2BUAs to support this mechanism all at once or any time in the near future. Therefore, it is expected that some B2BUAs and/or UAs will support generating and inserting Session-ID, while others will not support Session-ID at all.
SIP已经在Internet上广泛部署，期望所有UAs在不久的将来升级以支持本文档的机制是不切实际的。逐步迁移的解决方案是必要的，本文档通过允许B2BUA或代理执行会话ID生成器和插入器角色来提供。即使在这些设备类型中，期望所有B2BUA同时或在不久的将来的任何时候都支持这种机制也是不切实际的。因此，预计一些B2BUA和/或UAs将支持生成和插入会话ID，而其他B2BUA和/或UAs将完全不支持会话ID。
Due to the varying types of B2BUAs (such as PBXs, SBCs, Application Servers, feature servers, and softswitches of various flavors) and the numerous SIP deployment models in use, there are going to be cases in which Session-ID will fail to be a consistent value for all related dialogs or fail to successfully match. The goal of this document is to improve troubleshooting of current deployments as much as possible -- and, in this author's opinion, that is the best that can be done given the constraints.
由于B2BUA的不同类型（如PBX、SBC、应用服务器、功能服务器和各种风格的软交换机）以及使用的众多SIP部署模型，在某些情况下，会话ID将无法为所有相关对话框提供一致的值或无法成功匹配。本文档的目标是尽可能地改进当前部署的故障排除——在本文作者看来，这是在限制条件下可以做到的最好的方法。
One example is for forked requests: if a UAC that does not support this mechanism sends a request to a Proxy or B2BUA that also does not support this mechanism, each fork could reach B2BUAs or UASs that *do* support this mechanism. In such a case, each of those forked-to B2BUA/UAS will generate unique Session-IDs and put them in their responses, temporarily leading to multiple, different Session-ID values for the same related early dialogs. Typically, the UAC would eventually only accept one of the dialogs, and only one Session-ID would remain.
一个例子是分叉请求：如果不支持此机制的UAC向也不支持此机制的代理或B2BUA发送请求，则每个分叉可能到达*不*支持此机制的B2BUA或UAS。在这种情况下，分岔到B2BUA/UAS的每个人都将生成唯一的会话ID并将其放入其响应中，从而临时为相同的相关早期对话框生成多个不同的会话ID值。通常，UAC最终只接受一个对话框，并且只保留一个会话ID。
This document adds the "Session-ID" token to the definition of the element "message-header" in the SIP message grammar. The Session-ID header is a single-instance header.
本文档将“会话ID”标记添加到SIP消息语法中“消息头”元素的定义中。会话ID标头是单个实例标头。
Session-ID = "Session-ID" HCOLON sess-id
*( SEMI generic-param )
sess-id = 32(DIGIT / %x61-66) ; 32 chars of [0-9a-f]
Session-ID = "Session-ID" HCOLON sess-id
*( SEMI generic-param )
sess-id = 32(DIGIT / %x61-66) ; 32 chars of [0-9a-f]
NOTE: The sess-id value is technically case-INSENSITIVE, but only lowercase characters are allowed.
注意：sess id值在技术上不区分大小写，但只允许使用小写字符。
See the Security Considerations section for discussion about using header parameters in Session-ID header fields.
有关在会话ID头字段中使用头参数的讨论，请参阅安全注意事项部分。
In the following example, Alice initiates a call to Bob. Alice generates a Session-ID header in the out-of-dialog INVITE.
在下面的示例中，Alice向Bob发起调用。Alice在out-of-INVITE对话框中生成会话ID头。
Alice generates the following. (Note: much has been left out for simplicity.)
Alice生成以下代码。（注意：为了简单起见，省略了很多内容。）
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix@1.2.3.4
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix@1.2.3.4
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>
There are several security considerations surrounding this document's mechanism.
围绕此文档的机制有几个安全注意事项。
The Session-ID generation algorithm should provide a reasonably random 32-character Session-ID value to avoid collisions and should not let one re-create the original Call-ID.
会话ID生成算法应该提供一个合理的随机32个字符的会话ID值，以避免冲突，并且不应该让用户重新创建原始的调用ID。
There is no known security issue with viewing or modifying the Session-ID, other than to hamper troubleshooting efforts.
查看或修改会话ID没有已知的安全问题，只会妨碍故障排除工作。
The requirement for the Session-ID is to be an identifier which cannot be used by a recipient to identify if the Call-ID has been changed by middleboxes. As such, a UAS/UAC cannot detect the original Call-ID, nor whether it has been changed; thus, administrators should not be concerned if the Session-ID header field is "passed through".
会话ID的要求是一个标识符，收件人不能使用该标识符来识别呼叫ID是否已被中间盒更改。因此，UAS/UAC无法检测原始呼叫ID，也无法检测其是否已更改；因此，如果会话ID头字段为“已通过”，则管理员不必担心。
The Session-ID's value is created from the Call-ID using a hashing mechanism based on [RFC2104], using SHA-1 and a secret key known only to the system generating the Session-ID. Because the algorithm is defined in this document, it should be fairly secure from detecting the generator of the Session-ID, in terms of manufacturer or code base.
会话ID的值是使用基于[RFC2104]的散列机制，使用SHA-1和仅生成会话ID的系统已知的密钥，从调用ID创建的。由于该算法在本文档中定义，从制造商或代码库的角度来看，它应该是相当安全的，不会检测到会话ID的生成器。
The Session-ID generation algorithm should provide a reasonably random 128-bit Session-ID value, to avoid collisions, and should not let one re-create the original Call-ID. The secret key MUST only be used for the Session-ID mechanism, in case a weakness is found that reveals the key. One such weakness may be that a UAC generates one or more Call-IDs that have a property that makes determining the key more likely.
会话ID生成算法应提供合理的随机128位会话ID值，以避免冲突，并且不应让用户重新创建原始调用ID。密钥只能用于会话ID机制，以防发现泄露密钥的弱点。一个这样的弱点可能是UAC生成一个或多个调用ID，这些ID的属性使确定密钥更容易。
In general, B2BUA behavior cannot be dictated by standards. They do whatever their owners/operators wish them to do, or whatever is necessary to make their applications work. This document attempts to normatively specify some B2BUA behavior, by creating a SIP header value for which the properties are such that B2BUAs should have no legitimate reason to interfere. This effectively creates a "promise" that future uses of this Session-ID header field, including its value *and* any future defined parameters, maintain this benign property. Any future extensions to the Session-ID mechanism and header field MUST maintain this property, or else B2BUAs will begin to modify it again or remove it, and its value will be lost.
一般来说，B2BUA行为不能由标准决定。他们做他们的所有者/运营商希望他们做的任何事情，或使他们的应用程序工作所必需的任何事情。本文档试图通过创建一个SIP头值来规范地指定一些B2BUA行为，该值的属性应使B2BUA没有合法的理由进行干预。这有效地创建了一个“承诺”，即将来使用此会话ID头字段（包括其值*和*任何将来定义的参数）时，将保持此良性属性。会话ID机制和标头字段的任何未来扩展都必须维护此属性，否则B2BUAs将再次开始修改或删除它，其值将丢失。
Manufacturers of SIP devices should note that a B2BUA may inspect the Session-ID header field and may remove it if it does not comply with this document's value restrictions. Any Session-ID header parameters MUST be registered with IANA and documented in RFCs from the IETF stream, pursuant to the requirements of [RFC3968].
SIP设备制造商应注意，B2BUA可能会检查会话ID头字段，如果它不符合本文档的值限制，则可能会将其删除。根据[RFC3968]的要求，任何会话ID头参数必须向IANA注册，并记录在IETF流的RFC中。
IANA has registered a new SIP header field named 'Session-ID', pursuant to the registration policies for such in [RFC5727]. This is a single-instance header field and is appropriate for any SIP message, of any Method type, in any request or response.
IANA已根据[RFC5727]中的注册策略注册了一个名为“会话ID”的新SIP头字段。这是一个单实例头字段，适用于任何请求或响应中任何方法类型的任何SIP消息。
The ABNF rules [RFC5234] for this new header allow for header parameters; however, they must be registered following the rules of [RFC3968], as required by [RFC5727].
此新标头的ABNF规则[RFC5234]允许标头参数；但是，必须按照[RFC5727]的要求，按照[RFC3968]的规则进行注册。
This registration is intended to be temporary. The author expects that a Standards Track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA.
本次注册为临时注册。作者希望在将来发布会话ID的标准跟踪定义。假设这样一份文件已经发布，它将用对其自身的引用来代替该注册，此时IANA将不再引用该文件。
Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat, Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, Laura Liess, and Adam Roach for their input.
感谢拉斐尔·科菲奇、鲍勃·彭菲尔德、戴尔·沃利、保罗·基齐瓦特、伊恩·埃尔兹、马可·斯图拉、马丁·多利、马丁·赫尔斯曼、劳拉·利斯和亚当·罗奇的投入。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，Ed.，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
It is very tempting to use a header field value such as that provided by Session-ID, for other purposes than troubleshooting. In a previous document for this same Session-ID concept, the proposal included other uses; however, these were removed because any use case other than troubleshooting can easily lead to a B2BUA needing to change the value, in certain cases. That would defeat the troubleshooting value of Session-ID. This section discusses such use cases and explains why they are potentially harmful.
除了故障排除之外，使用诸如会话ID提供的头字段值是非常诱人的。在同一会议ID概念的先前文件中，提案包括其他用途；然而，这些都被删除了，因为在某些情况下，除了故障排除之外的任何用例都很容易导致B2BUA需要更改值。这将破坏Session-ID的故障排除价值。本节讨论此类用例，并解释它们可能有害的原因。
Although Session-ID does provide a means to correlate separate SIP dialogs, messages, and transactions, it does so at a higher layer than SIP. It does not replace the mechanics of SIP using the Call-ID and To/From tags of SIP messages to correlate SIP dialogs, nor in other uses such as Replaces headers or dialog-event packages. It is tempting, however, to use it for exactly that purpose in certain cases.
尽管会话ID确实提供了一种将单独的SIP对话框、消息和事务关联起来的方法，但它是在比SIP更高的层上实现的。它不会使用SIP消息的Call ID和To/From标记来替换SIP的机制，以关联SIP对话框，也不会用于其他用途，例如替换头或对话框事件包。然而，在某些情况下，正是出于这个目的使用它是很诱人的。
For example, suppose a call transfer case where Alice calls Bob through B2BUA-1. Bob then calls Charlie and sends Charlie a REFER with embedded Replaces to make Charlie send an INVITE with a Replaces header to Alice, to replace the Alice-Bob session. If Charlie uses a different B2BUA-2 to reach Alice, the INVITE with Replaces will fail because the Call-ID/tags won't match anything B2BUA-2 or Alice knows about.
例如，假设一个呼叫转移案例，其中Alice通过B2BUA-1呼叫Bob。Bob然后调用Charlie并向Charlie发送一个包含嵌入式替换的Reference，使Charlie向Alice发送一个包含替换头的邀请，以替换Alice Bob会话。如果Charlie使用不同的B2BUA-2联系Alice，则使用替换的邀请将失败，因为呼叫ID/标记与B2BUA-2或Alice知道的任何内容都不匹配。
+-----+ +-------+ +-------+ +-----+ +-------+
|Alice| |B2BUA-1| |B2BUA-2| | Bob | |Charlie|
+-----+ +-------+ +-------+ +-----+ +-------+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b | | |
|----------->|----------------------->|INVITE |
|sessid:1 |sessid:1 | |callid:2a |
| | | |----------->|
| | | |sessid:2 |
| | | | |
| | | |REFER |
| | | |referto:1b |
| | | |----------->|
| | | | |
| | | | INVITE|
| | | | replaces:1b|
| | X<-----------------------|
| | INVITE| | sessid:1|
| | replaces:1b| | |
X<------------------------| | |
| | sessid:1| | |
+-----+ +-------+ +-------+ +-----+ +-------+
|Alice| |B2BUA-1| |B2BUA-2| | Bob | |Charlie|
+-----+ +-------+ +-------+ +-----+ +-------+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b | | |
|----------->|----------------------->|INVITE |
|sessid:1 |sessid:1 | |callid:2a |
| | | |----------->|
| | | |sessid:2 |
| | | | |
| | | |REFER |
| | | |referto:1b |
| | | |----------->|
| | | | |
| | | | INVITE|
| | | | replaces:1b|
| | X<-----------------------|
| | INVITE| | sessid:1|
| | replaces:1b| | |
X<------------------------| | |
| | sessid:1| | |
Example 1: Call Transfer Case
示例1：呼叫转接箱
If, on the other hand, Alice were to use the Session-ID value for correlation, she would see it matches her dialog with Bob (assuming the Session-ID were passed along in the Refer-To and Replaces info).
另一方面，如果Alice使用会话ID值进行关联，她将看到它与Bob的对话框相匹配（假设会话ID在引用和替换信息中传递）。
There are problems with this approach, however. The first problem is, by not sending the INVITE with Replaces to B2BUA-1, B2BUA-1 is in an incorrect state; the dialog is getting replaced, and the B2BUA doesn't know it.
然而，这种方法存在一些问题。第一个问题是，通过不向B2BUA-1发送带有替换的INVITE，B2BUA-1处于错误状态；对话框被替换，B2BUA不知道。
A second issue is the Session-ID doesn't identify enough information to replace a dialog. Imagine there were a third B2BUA, such as a softswitch, between Alice and B2BUA-1 and B2BUA-2, and the INVITE with Replaces reached the softswitch before Alice. The softswitch won't know which "side" the INVITE is replacing. The To/From tags no longer match anything the softswitch knows about, so it can't figure out if the INVITE with Replaces is replacing the dialog from softswitch to Alice, or the one to Bob. If we try to fix this by creating a tag-type value pair for Session-ID, we're back to devices changing those tag values and defeating the matching property.
第二个问题是会话ID不能识别足够的信息来替换对话框。假设在Alice和B2BUA-1和B2BUA-2之间有第三个B2BUA，例如软交换，并且带有替换项的邀请在Alice之前到达软交换。软交换将不知道INVITE正在替换哪一方。To/From标记不再与softswitch知道的任何内容匹配，因此无法确定INVITE with Replaces是否正在替换softswitch与Alice之间的对话框，还是Bob之间的对话框。如果我们试图通过为会话ID创建一个标记类型值对来解决这个问题，那么我们就回到了改变这些标记值并破坏匹配属性的设备上。
Another example is based on 3GPP 24.605 Annex A.2.2. Alice has a call with Bob through multiple B2BUAs and an Application Server. The dialogs of that call all have the same Session-ID, but unique Call-ID/tags.
另一个示例基于3GPP 24.605附录A.2.2。Alice通过多个B2BUA和一个应用服务器与Bob通话。该调用的对话框都具有相同的会话ID，但具有唯一的调用ID/标记。
Alice wants to invoke a third-party conference facility in the AS and to reference the call she has with Bob for that. In this particular 3GPP scenario, to do that Alice sends a new INVITE to the AS with a resource-list body (a la RFC 5366) containing the call information for the original call. This is the "RL<sessid:1>" piece in the diagram. It has the Call-ID/tags as well, but they'll be wrong when received at the AS.
Alice想调用AS中的第三方会议设施，并引用她与Bob的电话。在这个特定的3GPP场景中，为了做到这一点，Alice向AS发送一个新的INVITE，其中包含原始呼叫的呼叫信息的资源列表主体（la RFC 5366）。这是图中的“RL<sessid:1>”部分。它也有呼叫ID/标签，但在as接收时会出错。
The AS processes that list, can't match the Call-ID/tags in the resource-lit but does match the Session-ID, and sends a re-INVITE to party B within the original call's dialog.
AS处理列表不能匹配资源lit中的呼叫ID/标记，但与会话ID匹配，并在原始呼叫对话框中向乙方发送重新邀请。
+-----+ +-------+ +----+ +-------+ +-----+
|Alice| |B2BUA-1| | AS | |B2BUA-2| | Bob |
+-----+ +-------+ +----+ +-------+ +-----+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b |callid:1c |callid:1d |
|----------->|----------->|---------->|----------->|
|sessid:1 |sessid:1 |sessid:1 |sessid:1 |
| | | | |
|INVITE | | | |
|callid:2a |callid:2b | | |
|----------->|----------->| | |
|sessid:2 |sessid:2 |re-INVITE | |
|RL<sessid:1>|RL<sessid:1>|callid:1c |callid:1d |
| | |---------->|----------->|
| | |sessid:1 |sessid:1 |
| | | | |
+-----+ +-------+ +----+ +-------+ +-----+
|Alice| |B2BUA-1| | AS | |B2BUA-2| | Bob |
+-----+ +-------+ +----+ +-------+ +-----+
| | | | |
|INVITE | | | |
|callid:1a |callid:1b |callid:1c |callid:1d |
|----------->|----------->|---------->|----------->|
|sessid:1 |sessid:1 |sessid:1 |sessid:1 |
| | | | |
|INVITE | | | |
|callid:2a |callid:2b | | |
|----------->|----------->| | |
|sessid:2 |sessid:2 |re-INVITE | |
|RL<sessid:1>|RL<sessid:1>|callid:1c |callid:1d |
| | |---------->|----------->|
| | |sessid:1 |sessid:1 |
| | | | |
Example 2: Resource List
示例2：资源列表
Author's Address
作者地址
Hadriel Kaplan Oracle EMail: hadrielk@yahoo.com
Hadriel Kaplan Oracle电子邮件：hadrielk@yahoo.com