Network Working Group M. Barnes, Ed.
Request for Comments: 4244 Nortel
Category: Standards Track November 2005
Network Working Group M. Barnes, Ed.
Request for Comments: 4244 Nortel
Category: Standards Track November 2005
An Extension to the Session Initiation Protocol (SIP) for Request History Information
会话启动协议（SIP）的扩展，用于请求历史信息
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.
本文档定义了一种标准机制，用于捕获与会话启动协议（SIP）请求相关联的历史信息。此功能通过提供有关呼叫如何以及为什么到达特定应用程序或用户的信息，实现了许多增强的服务。本文档定义了一个新的可选SIP头History Info，用于捕获请求中的历史信息。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Background: Why define a Generic "Request History"
capability? ................................................3
2. "Request History" Requirements ..................................4
2.1. Security Requirements ......................................6
2.2. Privacy Requirements .......................................7
3. Request History Information Description .........................7
3.1. Optionality of History-Info ................................8
3.2. Securing History-Info ......................................8
3.3. Ensuring the Privacy of History-Info .......................9
4. Request History Information Protocol Details ....................9
4.1. Protocol Structure of History-Info ........................10
4.2. Protocol Examples .........................................11
4.3. Protocol Usage ............................................12
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Background: Why define a Generic "Request History"
capability? ................................................3
2. "Request History" Requirements ..................................4
2.1. Security Requirements ......................................6
2.2. Privacy Requirements .......................................7
3. Request History Information Description .........................7
3.1. Optionality of History-Info ................................8
3.2. Securing History-Info ......................................8
3.3. Ensuring the Privacy of History-Info .......................9
4. Request History Information Protocol Details ....................9
4.1. Protocol Structure of History-Info ........................10
4.2. Protocol Examples .........................................11
4.3. Protocol Usage ............................................12
4.3.1. User Agent Client (UAC) Behavior ...................12
4.3.2. User Agent Server (UAS) Behavior ...................13
4.3.3. Proxy Behavior .....................................13
4.3.4. Redirect Server Behavior ...........................18
4.4. Security for History-Info .................................18
4.5. Example Applications Using History-Info ...................19
4.5.1. Example with Privacy Header for Entire
Request at Proxy2 ..................................21
4.5.2. Example with Privacy Header for Specific
URI (UA4) at Proxy2 ................................22
5. Application Considerations .....................................24
6. Security Considerations ........................................25
7. IANA Considerations ............................................25
7.1. Registration of New SIP History-Info Header ...............25
7.2. Registration of "history" for SIP Privacy Header ..........26
8. Normative References ...........................................26
9. Informative References .........................................26
10. Acknowledgements ..............................................26
11. Contributors' Addresses .......................................27
Appendix. Example Scenarios........................................28
Appendix A. Sequentially forking (History-Info in Response).....28
Appendix B. Voicemail...........................................34
Appendix C. Automatic Call Distribution Example.................39
Appendix D. Session via Redirect and Proxy Servers..............41
4.3.1. User Agent Client (UAC) Behavior ...................12
4.3.2. User Agent Server (UAS) Behavior ...................13
4.3.3. Proxy Behavior .....................................13
4.3.4. Redirect Server Behavior ...........................18
4.4. Security for History-Info .................................18
4.5. Example Applications Using History-Info ...................19
4.5.1. Example with Privacy Header for Entire
Request at Proxy2 ..................................21
4.5.2. Example with Privacy Header for Specific
URI (UA4) at Proxy2 ................................22
5. Application Considerations .....................................24
6. Security Considerations ........................................25
7. IANA Considerations ............................................25
7.1. Registration of New SIP History-Info Header ...............25
7.2. Registration of "history" for SIP Privacy Header ..........26
8. Normative References ...........................................26
9. Informative References .........................................26
10. Acknowledgements ..............................................26
11. Contributors' Addresses .......................................27
Appendix. Example Scenarios........................................28
Appendix A. Sequentially forking (History-Info in Response).....28
Appendix B. Voicemail...........................................34
Appendix C. Automatic Call Distribution Example.................39
Appendix D. Session via Redirect and Proxy Servers..............41
Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via "click to talk" SIP Uniform Resource Locators (URLs) on a web page, "call history/logging" style services within intelligent "call management" software for SIP User Agents (UAs), and calls to voicemail servers. Although SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This "request history" information allows the receiving application to determine hints about how and why the call arrived at the application/user.
SIP预计支持的许多服务都需要能够确定呼叫到达特定应用程序的原因和方式。此类服务的示例包括（但不限于）通过网页上的“点击通话”SIP统一资源定位器（URL）向呼叫中心发起的会话、“用于SIP用户代理（UAs）的智能“呼叫管理”软件中的呼叫历史/记录”式服务，以及对语音邮件服务器的呼叫。尽管SIP隐式地提供了重定向/重定目标功能，使呼叫能够路由到所选的应用程序，但目前SIP中没有标准机制用于传递此类请求的历史记录。此“请求历史记录”信息允许接收应用程序确定有关调用如何以及为什么到达应用程序/用户的提示。
This document defines a new SIP header, History-Info, to provide a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users. The History-Info header provides a building block for development of new services.
本文档定义了一个新的SIP头，History Info，以提供一种标准机制来捕获请求历史信息，从而为网络和最终用户提供多种服务。历史信息标题为新服务的开发提供了一个构建块。
Section 1.3 provides additional background motivation for the Request History capability. Section 2 identifies the requirements for a solution, with Section 3 providing an overall description of the solution.
第1.3节为请求历史记录功能提供了额外的背景动机。第2节确定了解决方案的需求，第3节提供了解决方案的总体描述。
Section 4 provides the details of the additions to the SIP protocol. Example uses of the new header are included in Section 4.5, with additional scenarios included in the Appendix.
第4节详细介绍了SIP协议的新增内容。第4.5节包含了新标题的示例使用，附录中包含了其他场景。
Section 5 summarizes the application considerations identified in the previous sections. Section 6 summarizes the security solution.
第5节总结了前几节中确定的应用注意事项。第6节总结了安全解决方案。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
SIP implicitly provides redirect/retarget capabilities that enable calls to be routed to specific applications as defined in [RFC3261]. The term 'retarget' will be used henceforth in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request and thus changing the target of the request. This term is chosen to avoid associating this request history only with the specific SIP Redirect Server capability that provides for a response to be sent back to a UAC requesting that the UAC should retarget the original request to an alternate URI. The rules for determining request targets as described in Section 16.5 of [RFC3261] are consistent with the use of the retarget term in this document.
SIP隐式提供重定向/重定目标功能，使呼叫能够路由到[RFC3261]中定义的特定应用程序。此后，本文档中将使用术语“重定目标”来指代代理服务器/用户代理客户端（UAC）更改请求中的统一资源标识符（URI）从而更改请求目标的过程。选择此术语是为了避免将此请求历史仅与特定SIP重定向服务器功能相关联，该功能提供将响应发送回UAC，请求UAC将原始请求重定目标为备用URI。[RFC3261]第16.5节所述的确定请求目标的规则与本文件中重定目标术语的使用一致。
The motivation for the request history is that in the process of retargeting, old routing information can be forever lost. This lost information may be important history that allows elements to which the call is retargeted to process the call in a locally defined, application-specific manner. The proposal in this document is to provide a mechanism for transporting the request history. It is not proposing any application-specific behavior for a Proxy or UA upon receipt of the information. Indeed, such behavior should be a local decision for the recipient application.
请求历史记录的动机是，在重定目标过程中，旧的路由信息可能永远丢失。丢失的信息可能是重要的历史记录，它允许调用重定目标的元素以本地定义的特定于应用程序的方式处理调用。本文档中的建议是提供一种传输请求历史记录的机制。它不会在收到信息后为代理或UA提出任何特定于应用程序的行为。事实上，这种行为应该是收件人应用程序的本地决定。
Current network applications provide the ability for elements involved with the call to exchange additional information relating to how and why the call was routed to a particular destination. The following are examples of such applications:
当前的网络应用程序为与呼叫相关的元素提供了交换有关如何以及为什么将呼叫路由到特定目的地的附加信息的能力。以下是此类应用的示例：
1. Web "referral" applications, whereby an application residing within a web server determines that a visitor to a website has arrived at the site via an "associate" site that will receive some "referral" commission for generating this traffic
1. Web“转介”应用程序，其中驻留在Web服务器内的应用程序确定网站的访问者已通过“关联”网站到达该网站，该网站将收到一些“转介”佣金以生成此流量
2. Email forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time
2. 通过电子邮件转发，转发给用户的用户可以获得谁在何时向谁发送电子邮件的“历史记录”
3. Traditional telephony services such as voicemail, call-center "automatic call distribution", and "follow-me" style services
3. 传统电话服务，如语音邮件、呼叫中心“自动呼叫分配”和“跟我走”式服务
Several of the aforementioned applications currently define application-specific mechanisms through which it is possible to obtain the necessary history information.
上述几个应用程序目前定义了特定于应用程序的机制，通过这些机制可以获得必要的历史信息。
In addition, request history information could be used to enhance basic SIP functionality by providing the following:
此外，请求历史信息可用于通过提供以下内容来增强基本SIP功能：
o Some diagnostic information for debugging SIP requests. (Note that the diagnostic utility of this mechanism is limited by the fact that its use by entities that retarget is optional.)
o 一些用于调试SIP请求的诊断信息。（请注意，此机制的诊断实用程序受到以下事实的限制：重定目标的实体使用它是可选的。）
o A stronger security solution for SIP. A side effect is that each proxy that captures the "request history" information in a secure manner provides an additional means (without requiring signed keys) for the original requestor to be assured that the request was properly retargeted.
o 一个更强的SIP安全解决方案。一个副作用是，以安全方式捕获“请求历史记录”信息的每个代理都为原始请求者提供了一种额外的手段（无需签名密钥），以确保请求被正确地重定目标。
The following list constitutes a set of requirements for a "Request History" capability.
以下列表构成了“请求历史记录”功能的一组需求。
1) CAPABILITY-req: The "Request History" capability provides a capability to inform proxies and UAs involved in processing a request about the history/progress of that request. Although this is inherently provided when the retarget is in response to a SIP redirect, it is deemed useful for non-redirect retargeting scenarios, as well.
1) 能力需求：“请求历史记录”能力提供了将请求的历史记录/进度通知参与处理请求的代理和UAs的能力。虽然这是在重定目标响应SIP重定向时固有地提供的，但它被认为对于非重定向重定目标场景也是有用的。
2) OPTIONALITY-req: The "Request History" information is optional.
2) 可选性要求：“请求历史记录”信息是可选的。
2.1) In many cases, it is anticipated that whether the history is added to the Request would be a local policy decision enforced by the specific application; thus, no specific protocol element is needed.
2.1）在许多情况下，预计历史记录是否添加到请求中将是由特定应用程序执行的本地政策决定；因此，不需要特定的协议元素。
2.2) Due to the capability being "optional" from the SIP protocol perspective, the impact to an application of not having the "Request History" must be described. Applicability guidelines to be addressed by applications using this capability must be provided as part of the solution to these requirements.
2.2）由于从SIP协议的角度来看，该功能是“可选的”，因此必须描述没有“请求历史记录”对应用程序的影响。使用此功能的应用程序必须提供适用性指南，作为这些需求解决方案的一部分。
3) GENERATION-req: "Request History" information is generated when the request is retargeted.
3) 生成请求：重新定位请求时生成“请求历史记录”信息。
3.1) In some scenarios, it might be possible for more than one instance of retargeting to occur within the same Proxy. A proxy should also generate Request History information for the 'internal retargeting'.
3.1）在某些情况下，可能会在同一代理中发生多个重定目标实例。代理还应为“内部重定目标”生成请求历史记录信息。
3.2) An entity (UA or proxy) retargeting in response to a redirect or REFER should include any Request History information from the redirect/REFER in the new request.
3.2）响应重定向或引用而重定目标的实体（UA或代理）应在新请求中包含来自重定向/引用的任何请求历史信息。
4) ISSUER-req: "Request History" information can be generated by a UA or proxy. It can be passed in both requests and responses.
4) 发卡机构请求：“请求历史记录”信息可由UA或代理生成。它可以在请求和响应中传递。
5) CONTENT-req: The "Request History" information for each occurrence of retargeting shall include the following:
5) 内容请求：每次重定目标的“请求历史”信息应包括以下内容：
5.1) The new URI or address to which the request is in the process of being retargeted,
5.1）请求正在重定目标的新URI或地址，
5.2) The URI or address from which the request was retargeted,
5.2）请求重定目标的URI或地址，
5.3) The reason for the Request-URI or address modification,
5.3）请求URI或地址修改的原因，
5.4) Chronological ordering of the Request History information.
5.4）请求历史信息的时间顺序。
6) REQUEST-VALIDITY-req: Request History is applicable to requests not sent within an established dialog (e.g., INVITE, REGISTER, MESSAGE, and OPTIONS).
6) 请求有效性请求：请求历史记录适用于未在已建立的对话框中发送的请求（例如，邀请、注册、消息和选项）。
7) BACKWARDS-req: Request History information may be passed from the generating entity backwards towards the UAC. This is needed to enable services that inform the calling party about the dialog establishment attempts.
7) 向后请求：请求历史信息可以从生成实体向后传递到UAC。这是启用通知呼叫方对话建立尝试的服务所必需的。
8) FORWARDS-req: Request History information may also be included by the generating entity in the request, if it is forwarded onwards.
8) 转发请求：如果请求向前转发，则生成实体也可以在请求中包含请求历史信息。
The Request History information is being inserted by a network element retargeting a Request, resulting in a slightly different problem than the basic SIP header problem, thus requiring specific consideration. It is recognized that these security requirements can be generalized to a basic requirement of being able to secure information that is inserted by proxies.
请求历史信息由重新定位请求的网元插入，导致与基本SIP报头问题稍有不同的问题，因此需要特别考虑。人们认识到，这些安全要求可以概括为能够保护由代理插入的信息的基本要求。
The potential security problems include the following:
潜在的安全问题包括：
1) A rogue application could insert a bogus Request History entry either by adding an additional entry as a result of retargeting or entering invalid information.
1) 流氓应用程序可以插入虚假的请求历史记录条目，方法是由于重定目标而添加额外条目或输入无效信息。
2) A rogue application could re-arrange the Request History information to change the nature of the end application or to mislead the receiver of the information.
2) 恶意应用程序可能会重新安排请求历史信息，以改变最终应用程序的性质或误导信息接收者。
3) A rogue application could delete some or all of the Request History information.
3) 恶意应用程序可能会删除部分或全部请求历史记录信息。
Thus, a security solution for "Request History" must meet the following requirements:
因此，“请求历史记录”的安全解决方案必须满足以下要求：
1) SEC-req-1: The entity receiving the Request History must be able to determine whether any of the previously added Request History content has been altered.
1) SEC-req-1：接收请求历史记录的实体必须能够确定先前添加的任何请求历史记录内容是否已被更改。
2) SEC-req-2: The ordering of the Request History information must be preserved at each instance of retargeting.
2) SEC-req-2：每个重定目标实例都必须保留请求历史信息的顺序。
3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the entity providing the request.
3) SEC-req-3：接收请求历史信息的实体必须能够验证提供请求的实体。
4) SEC-req-4: To ensure the confidentiality of the Request History information, only entities that process the request should have visibility to the information.
4) SEC-req-4：为确保请求历史记录信息的机密性，只有处理请求的实体才能查看信息。
It should be noted that these security requirements apply to any entity making use of the Request History information, either by retargeting and capturing the information, or as an application making use of the information received in either a Request or Response.
应当注意，这些安全性要求适用于通过重定目标和捕获信息，或者作为使用在请求或响应中接收的信息的应用程序，来使用请求历史信息的任何实体。
Since the Request-URI that is captured could inadvertently reveal information about the originator, there are general privacy requirements that MUST be met:
由于捕获的请求URI可能会无意中泄露有关发起人的信息，因此必须满足以下一般隐私要求：
1) PRIV-req-1: The entity retargeting the Request must ensure that it maintains the network-provided privacy (as described in [RFC3323]) associated with the Request as it is retargeted.
1) PRIV-req-1：重定请求目标的实体必须确保其在重定目标时维护与请求相关的网络提供的隐私（如[RFC3323]中所述）。
2) PRIV-req-2: The entity receiving the Request History must maintain the privacy associated with the information.
2) PRIV-req-2：接收请求历史记录的实体必须维护与信息相关的隐私。
In addition, local policy at a proxy may identify privacy requirements associated with the Request-URI being captured in the Request History information.
此外，代理的本地策略可以识别与请求历史信息中捕获的请求URI相关联的隐私要求。
3) PRIV-req-3: Request History information subject to privacy requirements shall not be included in outgoing messages unless it is protected as described in [RFC3323].
3) PRIV-req-3：受隐私要求约束的请求历史信息不得包含在传出消息中，除非按照[RFC3323]中所述进行保护。
The fundamental functionality provided by the request history information is the ability to inform proxies and UAs involved in processing a request about the history or progress of that request (CAPABILITY-req). The solution is to capture the Request-URIs as a request is forwarded in a new header for SIP messages: History-Info (CONTENT-req). This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent forwarding of the request. This solution proposes no changes in the fundamental determination of request targets or in the request forwarding as defined in Sections 16.5 and 16.6 of the SIP protocol specification [RFC3261].
请求历史记录信息提供的基本功能是能够将请求的历史记录或进度通知处理请求所涉及的代理和UAs（能力需求）。解决方案是在SIP消息的新头中转发请求时捕获请求URI：历史信息（CONTENT req）。这允许捕获请求的历史记录，该历史记录将在请求的后续转发中涉及的正常SIP处理中丢失。该解决方案不建议对SIP协议规范[RFC3261]第16.5节和第16.6节中定义的请求目标的基本确定或请求转发进行任何更改。
The History-Info header can appear in any request not associated with an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any valid response to these requests (ISSUER-req).
历史信息头可以出现在与已建立的对话框（例如，邀请、注册、消息、参考和选项、发布和订阅等）无关的任何请求（请求有效性请求）和对这些请求的任何有效响应（发卡机构请求）中。
The History-Info header is added to a Request when a new request is created by a UAC or forwarded by a Proxy, or when the target of a request is changed. The term 'retarget' is introduced to refer to this changing of the target of a request and the subsequent forwarding of that request. It should be noted that retargeting only occurs when the Request-URI indicates a domain for which the processing entity is responsible. In terms of the SIP protocol, the processing associated with retargeting is described in Sections 16.5
当UAC创建新请求或代理转发新请求时，或者当请求的目标发生更改时，历史信息标头将添加到请求中。引入术语“重定目标”是指请求目标的这种改变以及该请求的后续转发。应该注意，重定目标仅在请求URI指示处理实体负责的域时发生。关于SIP协议，第16.5节描述了与重定目标相关的处理
and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it is possible for the target of a request to be changed by the same proxy multiple times (referred to as 'internal retargeting' in Section 2), as the proxy MAY add targets to the target set after beginning Request Forwarding. Section 16.6 of [RFC3261] describes Request Forwarding. It is during this process of Request Forwarding that the History Information is captured as an optional, additional header field. Thus, the addition of the History-Info header does not impact fundamental SIP Request Forwarding. An entity (UA or proxy) changing the target of a request in response to a redirect or REFER SHOULD also propagate any History-Info header from the initial Request in the new request (GENERATION-req, FORWARDS-req).
和[RFC3261]的第16.6条。如[RFC3261]第16.5节所述，同一代理可能多次更改请求的目标（在第2节中称为“内部重定目标”），因为代理可能在开始请求转发后向目标集添加目标。[RFC3261]第16.6节描述了请求转发。正是在请求转发过程中，历史信息被捕获为可选的附加头字段。因此，添加历史信息报头不会影响基本SIP请求转发。为响应重定向或引用而更改请求目标的实体（UA或代理）也应在新请求（生成请求、转发请求）中传播来自初始请求的任何历史信息头。
The History-Info header is optional in that neither UAs nor Proxies are required to support it. A new Supported header, "histinfo", is included in the Request to indicate whether the History-Info header is returned in Responses (BACKWARDS-req). In addition to the "histinfo" Supported header, local policy determines whether or not the header is added to any request, or for a specific Request-URI, being retargeted. It is possible that this could restrict the applicability of services that make use of the Request History Information to be limited to retargeting within domain(s) controlled by the same local policy, or between domain(s) which negotiate policies with other domains to ensure support of the given policy, or services for which complete History Information isn't required to provide the service (OPTIONALITY-req). All applications making use of the History-Info header MUST clearly define the impact of the information not being available and specify the processing of such a request.
历史信息头是可选的，因为不需要UAs或代理来支持它。请求中包含一个新的受支持标头“histinfo”，以指示是否在响应中返回历史信息标头（向后请求）。除了“histinfo”支持的标头之外，本地策略还确定是否将标头添加到任何请求中，或是否针对正在重定目标的特定请求URI添加标头。这可能会限制使用请求历史信息的服务的适用性，使其仅限于在由同一本地策略控制的域内或与其他域协商策略以确保支持给定策略的域之间重定目标，或不需要完整历史信息来提供服务的服务（可选性要求）。所有使用历史信息头的应用程序必须明确定义信息不可用的影响，并指定此类请求的处理。
This document defines a new header for SIP. The use of the Transport Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to ensure the overall confidentiality of the History-Info headers (SEC-req-4) is strongly RECOMMENDED. This results in History-Info having at least the same level of security as other headers in SIP that are inserted by intermediaries. If TLS is not available for the connection over which the request is being forwarded, then the request MUST NOT include the History-Info header or the request MUST be redirected to the client, including the History-Info header, so that the request can be retargeted by the client.
本文档为SIP定义了一个新的头。强烈建议使用传输层安全（TLS）协议[RFC2246]作为强制机制，以确保历史信息头（SEC-req-4）的整体机密性。这导致历史信息的安全级别至少与中介插入的SIP中的其他头相同。如果TLS不可用于转发请求的连接，则请求不得包含历史信息标头，或者请求必须重定向到客户端，包括历史信息标头，以便客户端可以重新确定请求的目标。
With the level of security provided by TLS (SEC-req-3), the information in the History-Info header can thus be evaluated to determine if information has been removed by evaluating the indices
通过TLS（SEC-req-3）提供的安全级别，可以评估历史信息头中的信息，从而通过评估索引确定信息是否已被删除
for gaps (SEC-req-1, SEC-req-2). It would be up to the application to define whether it can make use of the information in the case of missing entries.
对于间隙（SEC-req-1、SEC-req-2）。在缺少条目的情况下，应用程序将决定是否可以使用这些信息。
Note that while using the SIPS scheme protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries.
请注意，虽然使用SIPS方案可以保护历史信息不被SIP消息路径之外的任意方篡改，但该路径上的所有中介都受到隐式信任。恶意中介可以任意删除、重写或修改历史信息。本规范不试图防止或检测恶意中介的攻击。
Since the History-Info header can inadvertently reveal information about the requestor as described in [RFC3323], the Privacy header SHOULD be used to determine whether an intermediary can include the History-Info header in a Request that it receives and forwards (PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy.
由于历史信息头可能会无意中泄露[RFC3323]中所述的关于请求者的信息，因此应使用隐私头来确定中介体是否可以在其接收和转发的请求（PRIV-req-2）或其重定目标（PRIV-req-1）中包含历史信息头。因此，如果请求者已指示会话或报头级别隐私的priv值，则历史信息报头不应包含在请求中。
In addition, the History-Info header can reveal general routing information, which may be viewed by a specific intermediary or network, to be subject to privacy restrictions. Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded.
此外，历史信息报头可以显示一般路由信息，这些信息可能由特定中介或网络查看，并受到隐私限制。因此，本地策略还可用于确定是否完全包括历史信息报头，是否在报头中捕获特定请求URI，或者是否仅在请求在特定域内重定目标时将其包括在请求中（PRIV-req-3）。在后一种情况下，这是通过将新的priv值history添加到隐私报头[rfc323]来实现的，该报头指示是否应转发任何或特定的历史信息报头。
It is recognized that satisfying the privacy requirements can impact the functionality of this solution by overriding the request to generate the information. As with the optionality and security requirements, applications making use of History-Info SHOULD address any impact this may have or MUST explain why it does not impact the application.
众所周知，满足隐私要求会通过覆盖生成信息的请求而影响此解决方案的功能。与可选性和安全性要求一样，使用历史信息的应用程序应该解决可能产生的任何影响，或者必须解释为什么它不会影响应用程序。
This section contains the details and usage of the proposed new SIP protocol elements. It also discusses the security aspects of the solution.
本节包含建议的新SIP协议元素的详细信息和用法。它还讨论了解决方案的安全方面。
History-Info is a header field as defined by [RFC3261]. It is an optional header field and MAY appear in any request or response not associated with a dialog or which starts a dialog. For example, History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests that initiate a dialog.
历史信息是[RFC3261]定义的标题字段。它是可选的标题字段，可以出现在与对话框无关或启动对话框的任何请求或响应中。例如，历史信息可能出现在INVITE、REGISTER、MESSAGE、REFER、OPTIONS、SUBSCRIBE和PUBLISH中，以及任何有效响应中，以及启动对话框的NOTIFY请求中。
This document adds the following entry to Table 2 of [RFC3261]. The additions to this table are also provided for extension methods at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way.
本文件将以下条目添加到[RFC3261]的表2中。在本文件发布时，本表还提供了扩展方法的补充内容。这是出于对读者的礼貌，在任何方面都不规范。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
The History-Info header carries the following information, with the mandatory parameters required when the header is included in a request or response:
“历史信息”标头包含以下信息，以及请求或响应中包含标头时所需的强制参数：
o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for capturing the Request-URI for the specific Request as it is forwarded.
o Targeted to URI（hi Targeted to URI）：用于在转发特定请求时捕获该请求的请求URI的强制参数。
o Index (hi-index): A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to also reflect the forking and nesting of requests. The format for this parameter is a string of digits, separated by dots to indicate the number of forward hops and retargets. This results in a tree representation of the history of the request, with the lowest-level index reflecting a branch of the tree. By adding the new entries in order (i.e., following existing entries per the details in Section 4.3.3.1), including the index and securing the header, the ordering of the History-Info headers in the request is assured (SEC-req-2). In addition, applications may extract a variety of metrics (total number of retargets, total number of retargets from a specific branch, etc.) based upon the index values.
o 索引（hi Index）：历史信息的一个必需参数，反映信息的时间顺序，索引也反映请求的分叉和嵌套。此参数的格式为一串数字，以点分隔，以指示向前跳跃和重定目标的数量。这导致请求历史的树表示，最低级别的索引反映了树的一个分支。通过按顺序添加新条目（即，根据第4.3.3.1节中的详细信息，遵循现有条目），包括索引和保护标头，确保请求中历史信息标头的顺序（SEC-req-2）。此外，应用程序可以基于索引值提取各种度量（重定目标总数、来自特定分支的重定目标总数等）。
o Reason: An optional parameter for History-Info, reflected in the History-Info header by including the Reason Header [RFC3326] escaped in the hi-targeted-to-uri. A reason is not included for
o 原因：历史信息的一个可选参数，通过将原因头[RFC3326]包含在针对uri的hi中转义，反映在历史信息头中。原因不包括在内
a hi-targeted-to-uri when it is first added in a History-Info header, but rather is added when the retargeting actually occurs. Note that this does appear to complicate the security problem; however, retargeting only occurs when the hi-targeted-to-uri indicates a domain for which the processing entity is responsible. Thus, it would be the same processing entity that initially added the hi-targeted-to-URI to the header that would be updating it with the Reason.
当第一次将hi添加到历史信息头中时，它以uri为目标，但在实际发生重定目标时添加。注意，这确实会使安全问题复杂化；但是，仅当hi目标为uri指示处理实体负责的域时，才会发生重定目标。因此，最初将hi目标添加到URI的处理实体将与更新它的头相同。
o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi-targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded.
o 隐私：历史信息的可选参数，通过在针对uri的hi中包含priv值为“History”的隐私头[RFC3323]或通过将priv值为“History”的隐私头添加到请求中，反映在历史信息头字段值中。priv值为“history”的Privacy标头的使用表明是否不应转发特定或所有历史信息标头。
o Extension (hi-extension): An optional parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension should ignore it.
o Extension（hi Extension）：一个可选参数，允许将来进行可选扩展。根据[RFC3261]，任何不理解扩展的实现都应该忽略它。
The following summarizes the syntax of the History-Info header, based upon the standard SIP syntax [RFC3261]:
以下根据标准SIP语法[RFC3261]总结了历史信息头的语法：
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
History Info=“History Info”HCOLON hi entry*（逗号hi entry）
hi-entry = hi-targeted-to-uri *( SEMI hi-param )
hi entry=hi针对uri*（半hi参数）
hi-targeted-to-uri= name-addr
hi目标为uri=name addr
hi-param = hi-index / hi-extension
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
hi-extension = generic-param
The following provides some examples of the History-Info header. Note that the backslash and CRLF between the fields in the examples below are for readability purposes only.
下面提供了历史信息标题的一些示例。请注意，以下示例中字段之间的反斜杠和CRLF仅用于可读性目的。
History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1;foo=bar
History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \ cause%3D302>; index=1.1,
历史信息：<sip:UserA@ims.example.com？原因=SIP%3B \原因%3D302>；指数=1.1，
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2,
<sip:45432@vm.example.com>;index=1.3
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2,
<sip:45432@vm.example.com>;index=1.3
This section describes the processing specific to UAs and Proxies for the History-Info header, the "histinfo" option tag, and the priv-value of "history". As discussed in Section 1.3, the fundamental objective is to capture the target Request-URIs as a request is forwarded. This allows for the capturing of the history of a request that would be lost due to subsequent (re)targeting and forwarding. To accomplish this for the entire history of a request, either the UAC must capture the Request-URI in a History-Info header in the initial request or a proxy must add a History-Info header with both a hi-entry for the Request-URI in the initial request and a hi-entry for the target Request-URI as the request is forwarded. The basic processing is for each entity forwarding a request to add a hi-entry for the target Request-URI, updating the index and adding the Reason as appropriate for any retargeted Request-URI.
本节描述了特定于UAs和代理的历史信息头、“histinfo”选项标记和“History”priv值的处理。如第1.3节所述，基本目标是在转发请求时捕获目标请求URI。这允许捕获由于后续（重新）定位和转发而丢失的请求的历史记录。为了在请求的整个历史记录中实现这一点，UAC必须在初始请求的历史信息头中捕获请求URI，或者代理必须在请求转发时添加一个历史信息头，其中包含初始请求URI的hi条目和目标请求URI的hi条目。基本处理是针对每个转发请求的实体，为目标请求URI添加hi条目，更新索引，并根据需要为任何重定目标的请求URI添加原因。
The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its request by adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URI was modified by a previous hop.
UAC应将“histinfo”选项标记包含在与UAC希望在响应中包含历史信息标头的已建立对话框无关的任何请求的受支持标头中。此外，UAC可以通过添加历史信息报头、使用请求的请求URI作为URI的hi目标并将索引初始化为hi条目中的建议值1来改进其请求的诊断实用程序。因此，中介机构和UAS将至少知道原始请求URI，以及请求URI是否被前一个跃点修改。
In the case where the request is routed to a redirect server and the UAC receives a 3xx response with a Contact header, the UAC MAY maintain the previous hi-entry(s) in the request. In this case, the reason header SHOULD be associated with the hi-targeted-to-uri in the previous (last) hi-entry, as described in Section 4.3.3.1.2. A new hi-entry MAY then be added for the URI from the Contact header (which becomes the new Request-URI). In this case, the index is created by reading and incrementing the value of the index from the previous hi-entry, thus following the same rules as those prescribed for a proxy in retargeting, described in Section 4.3.3.1.3. An example of this scenario can be found in Appendix D.
在请求被路由到重定向服务器并且UAC接收到带有联系人报头的3xx响应的情况下，UAC可以保持请求中先前的hi条目。在这种情况下，如第4.3.3.1.2节所述，原因标头应与上一个（最后一个）hi条目中针对uri的hi相关联。然后，可以从联系人头（成为新的请求URI）为URI添加新的hi条目。在这种情况下，通过读取并增加上一个hi条目的索引值来创建索引，从而遵循与第4.3.3.1.3节中描述的重定目标代理相同的规则。附录D中给出了这种情况的一个示例。
A UAC that does not want the History-Info header added due to privacy considerations SHOULD include a Privacy header with a priv-value(s) of "session", "header", or "history" in the request.
出于隐私考虑，不希望添加历史信息头的UAC应在请求中包含priv值为“session”、“header”或“History”的隐私头。
With the exception of the processing of a 3xx response described above, the processing of the History-Info header received in the Response is application specific and outside the scope of this document. However, the validity of the information SHOULD be ensured prior to any application usage. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
除上述3xx响应的处理外，响应中接收的历史信息头的处理是特定于应用程序的，不在本文档的范围内。但是，在使用任何应用程序之前，应确保信息的有效性。例如，可以对条目进行评估以确定索引中的差距，这可能表明条目被恶意删除或出于隐私原因被删除。无论哪种方式，应用程序都可能希望知道可能丢失的信息。
The processing of the History-Info header by a UAS in a Request depends upon local policy and specific applications at the UAS that might make use of the information. Prior to any application usage of the information, the validity SHOULD be ascertained. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
UAS在请求中对历史信息头的处理取决于本地策略和UAS中可能使用该信息的特定应用程序。在对信息进行任何应用之前，应确定其有效性。例如，可以对条目进行评估以确定索引中的差距，这可能表明条目被恶意删除或出于隐私原因被删除。无论哪种方式，应用程序都可能希望知道可能丢失的信息。
If the "histinfo" option tag is received in a request, the UAS SHOULD include any History-Info received in the request in the subsequent response.
如果在请求中收到“histinfo”选项标记，UAS应在后续响应中包括在请求中收到的任何历史信息。
The inclusion of the History-Info header in a Request does not alter the fundamental processing of proxies for determining request targets as defined in Section 16.5 of [RFC3261]. Whether a proxy adds the History-Info header or a new hi-entry as it forwards a Request depends upon the following considerations:
请求中包含历史信息头不会改变[RFC3261]第16.5节中定义的用于确定请求目标的代理的基本处理。代理在转发请求时是添加历史信息头还是添加新的hi条目取决于以下注意事项：
1. Whether the Request contains the "histinfo" option tag in the Supported header. 2. Whether the proxy supports the History-Info header. 3. Whether the Request contains a Privacy header with a priv-value of "session", "header", or "history". 4. Whether any History-Info header added for a proxy/domain should go outside that domain. An example being the use of the History-Info header within the specific domain in which it is retargeted, however, policies (for privacy, user and network security, etc.) would prohibit the exposure of that information outside that domain. To accommodate such a scenario, a proxy MAY insert the Privacy header with a priv-value of "history" when the request is being forwarded within the same domain. An example of such an application is provided in Appendix C.
1. 请求是否在支持的标头中包含“histinfo”选项标记。2.代理是否支持历史信息头。3.请求是否包含priv值为“session”、“header”或“history”的隐私标头。4.为代理/域添加的任何历史信息头是否应超出该域。例如，在重定目标的特定域中使用历史信息头，但是，策略（隐私、用户和网络安全等）将禁止在该域之外公开该信息。为了适应这种情况，当请求在同一域内转发时，代理可以插入priv值为“history”的隐私报头。附录C中提供了此类应用的示例。
5. Whether a hi-entry is added for a specific Request-URI due to local privacy policy considerations. A proxy MAY add the Privacy header with a priv-value of "history" associated with the specific hi-targeted-to-uri.
5. 由于本地隐私策略的考虑，是否为特定请求URI添加hi条目。代理可以添加priv值为“history”的隐私头，该priv值与针对uri的特定hi相关联。
An example policy would be a proxy that only adds the History-Info header if the "histinfo" option tag is in the Supported header. Other proxies may have a policy that they always add the header, but never forward it outside a particular domain, accomplishing this by adding a Privacy header with a priv-value of "history" to each hi-entry to allow the information to be collected for internal retargeting only.
例如，如果“histinfo”选项标记位于受支持的标头中，则仅添加历史信息标头的代理策略。其他代理可能有一个策略，即他们总是添加头，但从不将其转发到特定域之外，通过向每个hi条目添加PRIVE值为“history”的隐私头来实现这一点，以允许收集信息仅用于内部重定目标。
Each application making use of the History-Info header SHOULD address the impacts of the local policies on the specific application (e.g., what specification of local policy is optimally required for a specific application and any potential limitations imposed by local policy decisions).
使用历史信息标题的每个应用程序都应解决本地政策对特定应用程序的影响（例如，特定应用程序最需要什么本地政策规范，以及本地政策决策施加的任何潜在限制）。
Consistent with basic SIP processing of optional headers, proxies SHOULD maintain the History-Info header(s), received in messages being forwarded, independent of whether local policy supports History-Info.
与可选头的基本SIP处理一致，代理应维护在转发的消息中接收的历史信息头，而与本地策略是否支持历史信息无关。
The specific processing by proxies for adding the History-Info headers in Requests and Responses, to accommodate the considerations outlined above, is described in detail in the following sections.
以下各节将详细描述代理在请求和响应中添加历史信息头的具体处理过程，以适应上述注意事项。
Upon evaluation of the considerations under which the History-Info header is to be included in requests (e.g., no Privacy header overriding inclusion, local policy supports, etc.), detailed in Section 4.3.3, a proxy SHOULD add a hi-entry as it forwards a Request. Section 16.6 of [RFC3261] defines the steps to be followed as the proxy forwards a Request. Step 5 prescribes the addition of optional headers. Although this would seem the appropriate step for adding the History-Info header, the interaction with Step 6, "Postprocess routing information", and the impact of a strict route in the Route header could result in the Request-URI being changed; thus, adding the History-Info header between Steps 8 (adding Via header) and 9 (adding Content-Length) is RECOMMENDED. Note that in the case of loose routing, the Request-URI does not change during the forwarding of a Request; thus, the capturing of History-Info for such a request would result in duplicate Request-URIs with different indices. The hi-entry MUST be added following any hi-entry received in the request being forwarded. Additionally, if a request is received that doesn't include a History-Info header, the proxy MAY
根据第4.3.3节的详细说明，在评估请求中包含历史信息头的考虑因素后（例如，没有覆盖包含的隐私头、本地策略支持等），代理应在转发请求时添加hi条目。[RFC3261]第16.6节定义了代理转发请求时应遵循的步骤。步骤5规定添加可选标题。尽管这似乎是添加历史信息报头的适当步骤，但与步骤6“后处理路由信息”的交互以及路由报头中严格路由的影响可能会导致请求URI被更改；因此，建议在步骤8（通过标题添加）和步骤9（添加内容长度）之间添加历史信息标题。注意，在松散路由的情况下，请求URI在请求转发期间不会改变；因此，捕获此类请求的历史信息将导致具有不同索引的重复请求URI。必须在转发请求中收到的hi条目之后添加hi条目。此外，如果收到不包含历史信息头的请求，则代理可能会
add a History-Info header with a hi-entry preceding the one being added for the current request being forwarded. The index for this hi-entry is RECOMMENDED to start at 1. The following subsections define the details of creating the information associated with each hi-entry.
添加历史信息标头，其中hi条目位于为当前转发请求添加的条目之前。建议此hi条目的索引从1开始。以下小节定义了创建与每个hi条目关联的信息的详细信息。
If there is a Privacy header in the request with a priv-value of "session", "header", or "history", a hi-entry MAY be added, if the request is being forwarded to a Request-URI associated with a domain for which the processing entity is responsible (and provided local policy supports the History-Info header, etc.). If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and there is a Privacy header in the request with a priv-value of "session", "header", or "history", the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending upon local policy and whether the proxy might know a priori that it can rely on a downstream privacy service to apply the requested privacy.
如果请求中存在priv值为“session”、“header”或“history”的隐私报头，则如果请求被转发到与处理实体负责的域相关联的请求URI（并且提供本地策略支持历史信息报头等），则可以添加hi条目。如果请求被转发到与代理不负责的域相关联的请求URI，并且请求中存在priv值为“session”、“header”或“history”的隐私标头，则代理应在转发之前删除任何hi条目，取决于本地策略以及代理是否先验地知道它可以依赖下游隐私服务来应用请求的隐私。
For the scenario where there is no Privacy header in the request and the request is being forwarded to a Request-URI associated with the domain(s) for which this entity is responsible, there are several additional considerations:
对于请求中没有隐私标头且请求被转发到与该实体负责的域相关联的请求URI的场景，还有几个额外的注意事项：
o If there is no local policy associated with privacy, then a hi-entry MAY be added to the Request.
o 如果没有与隐私相关的本地策略，则可以向请求中添加hi条目。
o If the proxy's local policies, per consideration 4 in section 4.3.3, indicate that the History-Info header should not be forwarded beyond the domain for which this intermediary is responsible, then a Privacy header with a priv-value of "history" SHOULD be associated with each hi-entry added by that proxy in this scenario.
o 如果代理的本地策略（根据第4.3.3节中的考虑事项4）表明历史信息标头不应转发到该中介机构负责的域之外，则priv值为“History”的隐私标头应与该代理在此场景中添加的每个hi条目相关联。
o If the proxy's policy, per consideration 5 in Section 4.3.3, indicates that History-Info for a specific Request-URI should not be forwarded beyond the domain for which this intermediary is responsible, then a Privacy header with a priv-value of "history" SHOULD be associated with the specific hi-entry, for that specific hi-targeted-to-uri, added by that proxy in this scenario.
o 根据第4.3.3节中的考虑事项5，如果代理的策略指示特定请求URI的历史信息不应转发到该中介机构负责的域之外，则priv值为“History”的隐私标头应与特定hi条目相关联，该特定hi针对URI，在此场景中由该代理添加。
If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and local policy requires privacy associated with any, or with specific, hi-entries it
如果请求被转发到与代理不负责的域相关联的请求URI，并且本地策略要求与任何hi条目或特定hi条目相关联的隐私
has added, any hi-entry with a priv-value of "history" SHOULD be removed prior to forwarding.
已添加，任何priv值为“历史记录”的hi条目都应在转发之前删除。
For retargets that are the result of an explicit SIP response, a Reason MUST be associated with the hi-targeted-to-uri. If the SIP response does not include a Reason header, the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. If the response contains a non-SIP Reason header (e.g., Q.850), it MUST be captured as an additional Reason associated with the hi-targeted-to-uri that has been retargeted, along with the SIP Response Code. If the Reason header is a SIP reason, then it MUST be used as the Reason associated with the hi-targeted-to-uri rather than the SIP response code.
对于作为显式SIP响应结果的重定目标，必须将原因与以uri为目标的hi相关联。如果SIP响应不包含原因标头，则触发重定目标的SIP响应代码必须包含为与已重定目标的hi目标uri关联的原因。如果响应包含非SIP原因头（例如，Q.850），则必须将其与已重定目标的hi目标uri相关联的附加原因以及SIP响应代码一起捕获。如果原因头是SIP原因，则必须将其用作与针对uri的hi关联的原因，而不是SIP响应代码。
For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted.
对于由于超时或内部事件而导致的重定目标，原因可能与已重定目标的针对uri的hi相关。
The addition of the Reason should occur prior to the forwarding of the request (which may add a new hi-entry with a new hi-targeted-to-uri) as it is associated with the hi-targeted-to-uri that has been retargeted, since it reflects the reason why the Request to that specific URI was not successful.
添加原因应在转发请求之前发生（这可能会添加一个新的hi条目，其中新的hi针对uri），因为它与已重定目标的hi针对uri相关联，因为它反映了向该特定uri的请求未成功的原因。
In order to maintain ordering and accurately reflect the nesting and retargeting of the request, an index MUST be included along with the Targeted-to-URI being captured. Per the syntax in Section 4.1, the index consists of a dot-delimited series of digits (e.g., 1.1.2). Each dot reflects a hop or level of nesting; thus, the number of hops is determined by the total number of dots. Within each level, the integer reflects the number of peer entities to which the request has been routed. Thus, the indexing results in a logical tree representation for the history of the Request. It is recommended that for each level of indexing, the index start at 1. It is recommended that an increment of 1 is used for advancing to a new branch.
为了保持顺序并准确反映请求的嵌套和重定目标，必须在捕获目标URI的同时包含索引。根据第4.1节中的语法，索引由一系列以点分隔的数字组成（如1.1.2）。每个点反映一个跳跃或嵌套水平；因此，跳数由点的总数决定。在每个级别中，整数反映了请求路由到的对等实体的数量。因此，索引将导致请求历史的逻辑树表示。建议对于每个索引级别，索引从1开始。建议使用增量1前进到新分支。
The basic rules for adding the index are summarized as follows:
添加索引的基本规则总结如下：
1. Basic Forwarding: In the case of a Request that is being forwarded, the index is determined by adding another level of indexing since the depth/length of the branch is increasing. To accomplish this, the proxy reads the value from the History-Info
1. 基本转发：对于正在转发的请求，由于分支的深度/长度在增加，因此通过添加另一级别的索引来确定索引。为此，代理从历史信息中读取值
header in the received request, if available, and adds another level of indexing by appending the dot delimiter followed by an initial index for the new level RECOMMENDED to be 1. For example, if the index in the last History-Info header field in the received request is 1.1, this proxy would initialize its index to 1.1.1 and forward the request.
接收到的请求中的标头（如果可用），并通过添加点分隔符和建议为1的新级别的初始索引来添加另一级别的索引。例如，如果接收到的请求中最后一个历史信息头字段中的索引为1.1，则此代理将其索引初始化为1.1.1并转发请求。
2. Retargeting within a Proxy - 1st instance: For the first instance of retargeting within a Proxy, the calculation of the index follows that prescribed for basic forwarding.
2. 代理内重定目标-第一个实例：对于代理内重定目标的第一个实例，索引的计算遵循基本转发的规定。
3. Retargeting within a Proxy - subsequent instance: For each subsequent retargeting of a request by the same proxy, another branch is added. With the index for each new branch calculated by incrementing the last/lowest digit at the current level, the index in the next request forwarded by this same proxy, following the example above, would be 1.1.2.
3. 代理内的重定目标-后续实例：对于同一代理对请求的每次后续重定目标，将添加另一个分支。通过在当前级别增加最后/最低数字来计算每个新分支的索引，按照上面的示例，该代理转发的下一个请求中的索引将为1.1.2。
4. Retargeting based upon a Response: In the case of retargeting due to a specific response (e.g., 302), the index would be calculated per rule 3. That is, the lowest/last digit of the index is incremented (i.e., a new branch is created), with the increment RECOMMENDED to be 1. For example, if the index in the History-Info header of the received request was 1.2, then the index in the History-Info header field for the new hi-targeted-to-URI would be 1.3.
4. 基于响应的重定目标：在由于特定响应（例如302）而重定目标的情况下，将根据规则3计算索引。也就是说，索引的最低/最后一位数字递增（即，创建一个新的分支），建议增量为1。例如，如果接收到的请求的历史信息头中的索引是1.2，那么针对URI的新hi的历史信息头字段中的索引将是1.3。
5. Retargeting the request in parallel (forking): If the request forwarding is done in parallel, the index MUST be captured for each forked request per the rules above, with each new Request having a unique index. The only difference in the messaging for this scenario and the messaging produced per basic proxy retargeting in rules 2 and 3 is these forwarded requests do not have History-Info entries associated with their peers. The proxy builds the subsequent response (or request) using the aggregated information associated with each of those requests and including the header entries in the order indicated by the indexing. Responses are processed as described in Section 16.7 of [RFC3261] with the aggregated History-Info entries processed similar to Step 7 "Aggregate Authentication Header Field Values". Section 4.5 provides an example of a parallel request scenario, highlighting this indexing mechanism.
5. 并行重定目标请求（forking）：如果请求转发是并行完成的，则必须根据上述规则为每个forking请求捕获索引，每个新请求都有一个唯一的索引。此场景的消息传递与规则2和规则3中每个基本代理重定目标生成的消息传递的唯一区别在于，这些转发的请求没有与其对等方关联的历史信息条目。代理使用与每个请求相关联的聚合信息构建后续响应（或请求），并按照索引指示的顺序包括头条目。响应的处理如[RFC3261]第16.7节所述，聚合历史信息条目的处理类似于步骤7“聚合身份验证标头字段值”。第4.5节提供了一个并行请求场景的示例，重点介绍了这种索引机制。
A proxy that receives a Request with the "histinfo" option tag in the Supported header, and depending upon a local policy supporting the capture of History-Info, SHOULD return captured History-Info in subsequent, provisional, and final responses to the Request, subject to the following considerations for privacy:
根据支持捕获历史信息的本地策略，接收请求且在受支持标头中带有“histinfo”选项标记的代理应在请求的后续、临时和最终响应中返回捕获的历史信息，但需考虑以下隐私因素：
o If the response is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and there was a Privacy header, in the request received by the proxy, with a priv-value of "session", "header", or "history", the proxy MUST remove the History-Info header (i.e., all hi-entries) prior to forwarding.
o 如果响应被转发到与代理不负责的域相关联的请求URI，并且在代理接收到的请求中存在priv值为“session”、“header”或“history”的隐私标头，则代理必须在转发之前删除history Info标头（即所有hi条目）。
o If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and local policy requires privacy associated with any or all hi-entry(s) it has added, any hi-entry with a priv-value of "history" MUST be removed prior to forwarding.
o 如果请求被转发到与代理不负责的域相关联的请求URI，并且本地策略要求与它添加的任何或所有hi条目相关联的隐私，则在转发之前必须删除priv值为“history”的任何hi条目。
o If a proxy receives a response from another intermediary associated with a domain for which it is responsible, including hi-entry(s) with privacy headers, and that response is to be forwarded to a domain for which it is not responsible, then those hi-entry(s) MUST be removed.
o 如果代理从与其负责的域相关联的另一个中介接收到响应，包括带有隐私头的hi条目，并且该响应将转发到其不负责的域，则必须删除这些hi条目。
The processing of History-Info in responses follows the methodology described in Section 16.7 of [RFC3261], with the processing of History-Info headers adding an additional step, just before Step 9, "Forwarding the Response".
响应中历史信息的处理遵循[RFC3261]第16.7节中描述的方法，在步骤9“转发响应”之前，历史信息标题的处理增加了一个附加步骤。
A redirect server SHOULD NOT add any new History-Info, as that would be done by the entity receiving the 3xx response. However, a redirect server MAY include History-Info in responses by adding any History-Info headers received in a request to a subsequent response.
重定向服务器不应添加任何新的历史记录信息，因为接收3xx响应的实体会这样做。但是，重定向服务器可以通过将请求中接收到的任何历史信息头添加到后续响应中，从而在响应中包含历史信息。
As discussed in Section 3, the security requirements are met by recommending the use of TLS (a basic SIP requirement per [RFC3261]) for hop-by-hop security. If TLS is not available on the connection over which a request containing a History-Info header is being forwarded, then either of the following two options MUST be implemented:
如第3节所述，建议使用TLS（根据[RFC3261]的基本SIP要求）来实现逐跳安全，从而满足安全要求。如果TLS在转发包含历史信息标头的请求的连接上不可用，则必须实现以下两个选项之一：
o The History-Info header MUST be removed prior to forwarding the request, or o The request MUST be redirected, including the History-Info header in the response, to allow the UAC to securely issue the request, including the History-Info header.
o 在转发请求之前必须删除历史信息头，或者必须重定向请求，包括响应中的历史信息头，以允许UAC安全地发出请求，包括历史信息头。
This scenario highlights an example where the History-Info in the response is primarily of use in not retrying routes that have already been tried by another proxy. Note that this is just an example and that there may be valid reasons why a Proxy would want to retry the routes, and thus, this would likely be a local proxy or even user-specific policy.
此场景突出显示了一个示例，其中响应中的历史信息主要用于不重试已由另一个代理尝试的路由。请注意，这只是一个示例，可能存在代理希望重试路由的有效原因，因此，这可能是本地代理，甚至是特定于用户的策略。
UA1 sends a call to Bob to proxy 1. Proxy 1 forwards the request to Proxy 2. Proxy 2 sends the requests in parallel and tries several places (UA2, UA3, and UA4) before sending a response to Proxy 1 that all the places are busy. Proxy 1, without the History-Info, would try some of the same places (e.g., UA3) based upon registered contacts for Bob, before completing at UA5. However, with the History-Info, Proxy 1 determines that UA3 has already received the invite; thus, the INVITE goes directly to UA5.
UA1向Bob发送一个到代理1的调用。代理1将请求转发给代理2。代理2并行发送请求，并尝试几个位置（UA2、UA3和UA4），然后向代理1发送所有位置都忙的响应。没有历史记录信息的代理1将根据Bob的注册联系人尝试一些相同的地方（例如UA3），然后在UA5完成。但是，根据历史信息，代理1确定UA3已经收到邀请；因此，邀请直接发送到UA5。
Section 4.5.1 provides this same scenario using one of the privacy mechanisms, with Proxy2 (P2) adding the Privacy header indicating that the History-Info header is not to be propagated outside P2's domain. This scenario highlights the potential functionality lost with the use of "history" privacy in the Privacy header for the entire request and the need for careful consideration on the use of privacy for History-Info.
第4.5.1节使用其中一种隐私机制提供了相同的场景，Proxy2（P2）添加了隐私头，指示历史信息头不会传播到P2的域之外。此场景强调了在整个请求的隐私标头中使用“历史”隐私可能会丢失的功能，以及需要仔细考虑历史信息隐私的使用。
Section 4.5.2 also provides the same scenario using one of the privacy mechanisms, however, due to local policy at Proxy2, only one of the Request-URIs (UA4) in the History-Info contains a priv-value of "history", thus allowing some optimized functionality in the routing of the request, but still maintaining privacy for specific URIs.
第4.5.2节还使用一种隐私机制提供了相同的场景，但是，由于Proxy2的本地策略，历史信息中只有一个请求URI（UA4）包含priv值“History”，因此允许在请求路由中使用一些优化的功能，但仍然保持特定URI的隐私。
The formatting in these scenarios is for visual purposes; thus, backslash and CRLF are used between the fields for readability and the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples for the proper formatting. Additional detailed scenarios are available in the appendix.
这些场景中的格式设置用于视觉目的；因此，为了可读性，在字段之间使用了反斜杠和CRLF，并且URI中的头没有正确显示以进行转义。有关正确的格式，请参阅第4.2节示例。附录中提供了其他详细场景。
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1代理1代理2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
/* All Responses from the INVITEs indicate non-success/non-
availability*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;cause=603;\
text="Decline">; index=1.1.3
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;cause=603;\
text="Decline">; index=1.1.3
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1代理1代理2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1
| | | | | | |
| | |-INVITE>| | | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1
| | | | | | |
| | |-INVITE>| | | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability and only the initial, received History-Info entries
are NOT returned to P1 due to the Privacy header value.*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
/* All Responses from the INVITEs indicate non-success/non-
availability and only the initial, received History-Info entries
are NOT returned to P1 due to the Privacy header value.*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, including UA3, which was attempted by P2, but due to
Privacy P1 is not aware of this, so UA3 is re-attempted prior to
forwarding the INVITE to UA5, where the session is successfully
established */
| | | | | | |
| |--------------INVITE ----->| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |<-- 486 -------------------| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
INVITE, including UA3, which was attempted by P2, but due to
Privacy P1 is not aware of this, so UA3 is re-attempted prior to
forwarding the INVITE to UA5, where the session is successfully
established */
| | | | | | |
| |--------------INVITE ----->| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |<-- 486 -------------------| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1代理1代理2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com?\
Privacy=history>; index=1.1.3
| | |-------INVITE------------>| |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com?\
Privacy=history>; index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability. The History-Info associated with UA4 is not returned
in the response due to the privacy header associated with that URI */
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
/* All Responses from the INVITEs indicate non-success/non-
availability. The History-Info associated with UA4 is not returned
in the response due to the privacy header associated with that URI */
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
As seen by the example scenarios in the appendix, History-Info provides a very flexible building block that can be used by intermediaries and UAs for a variety of services. As such, any services making use of History-Info must be designed with the following considerations:
正如附录中的示例场景所示，历史信息提供了一个非常灵活的构建块，可供中介机构和UAs用于各种服务。因此，任何使用历史信息的服务在设计时必须考虑以下因素：
1) History-Info is optional; thus, a service MUST define default behavior for requests and responses not containing History-Info headers. 2) History-Info may be impacted by privacy considerations. Applications requiring History-Info need to be aware that if Header-, Session-, or History-level privacy is requested by a UA (or imposed by an intermediary) that History-Info may not be available in a request or response. This would be addressed by an application in the same manner as the previous consideration by ensuring there is reasonable default behavior should the information not be available. 3) History-Info may be impacted by local policy. Each application making use of the History-Info header SHOULD address the impacts of the local policies on the specific application (e.g., what specification of local policy is optimally required for a specific application and any potential limitations imposed by local policy decisions). Note that this is related to the optionality and privacy considerations identified in 1 and 2 above, but goes beyond that. For example, due to the optionality and privacy considerations, an entity may receive only partial History-Info entries; will this suffice? Note that this would be a limitation for debugging purposes, but might be perfectly satisfactory for some models whereby only the information from a specific intermediary is required. 4) The security associated with the History-Info header requires the use of TLS. In the case of TLS not being available for a connection over which a request is being forwarded, the History-Info header may be removed from a request. The impact of lack of having the information depends upon the nature of the specific application (e.g., Is the information something that appears on a display or is it processed by automata which could have negative impacts on the subsequent processing of a request?). It is suggested that the impact of an intermediary not supporting the security recommendations should be evaluated by the application to ensure that the impacts have been sufficiently addressed by the application.
1) 历史信息是可选的；因此，服务必须为不包含历史信息头的请求和响应定义默认行为。2） 历史记录信息可能会受到隐私因素的影响。需要历史信息的应用程序需要知道，如果UA请求（或由中间人强制）头级、会话级或历史级隐私，则历史信息可能在请求或响应中不可用。应用程序将以与前面考虑相同的方式解决这一问题，确保在信息不可用时存在合理的默认行为。3） 历史记录信息可能会受到本地策略的影响。使用历史信息标题的每个应用程序都应解决本地政策对特定应用程序的影响（例如，特定应用程序最需要什么本地政策规范，以及本地政策决策施加的任何潜在限制）。请注意，这与上文1和2中确定的可选性和隐私考虑有关，但超出了这一范围。例如，由于可选性和隐私考虑，实体可能只接收部分历史信息条目；这够了吗？请注意，这对于调试目的来说是一个限制，但对于某些只需要特定中介的信息的模型来说可能是完全令人满意的。4） 与历史信息标头关联的安全性要求使用TLS。在TLS不可用于转发请求的连接的情况下，可以从请求中删除历史信息头。缺少信息的影响取决于特定应用程序的性质（例如，信息是否显示在显示器上，或者是否由自动机处理，这可能会对请求的后续处理产生负面影响？）。建议应用程序对不支持安全建议的中介机构的影响进行评估，以确保应用程序充分处理了影响。
The threat model and related security and privacy requirements for the History-Info header are described in Sections 2.1 and 2.2 of this document. Sections 3.2, 3.3, and 4.4 provide normative recommendations related to security and privacy fulfilling these requirements. The use of TLS is mandated between the entities (i.e., UAC to Proxy, Proxy to Proxy, and Proxy to UAS) that use the History-Info header. The appropriate handling of a request in the case that TLS is not available for a specific connection is described in Section 5.
本文件第2.1节和第2.2节描述了历史信息标题的威胁模型和相关安全和隐私要求。第3.2、3.3和4.4节提供了与满足这些要求的安全和隐私相关的规范性建议。TLS的使用是在使用历史信息头的实体（即UAC到代理、代理到代理和代理到UAS）之间强制执行的。第5节描述了在TLS不可用于特定连接的情况下对请求的适当处理。
With TLS, History-Info headers are no less, nor no more, secure than other SIP headers, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header.
使用TLS，历史信息头的安全性不低于或不高于其他SIP头，通常比历史信息头对SIP会话的后续处理有更大的影响。
This document defines a new SIP header field name: History-Info and a new option tag: histinfo.
本文档定义了一个新的SIP头字段名：History Info和一个新的选项标记：histinfo。
The following changes have been made to
http:///www.iana.org/assignments/sip-parameters
The following changes have been made to
http:///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section:
以下行已添加到标题字段部分：
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC4244]
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC4244]
The following has been added to the Options Tags section:
以下内容已添加到“选项标记”部分：
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header, [RFC4244]
this option tag indicates support
for the History Information to be
captured for requests and returned in
subsequent responses. This tag is not
used in a Proxy-Require or Require
header field since support of
History-Info is optional.
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header, [RFC4244]
this option tag indicates support
for the History Information to be
captured for requests and returned in
subsequent responses. This tag is not
used in a Proxy-Require or Require
header field since support of
History-Info is optional.
This document defines a new priv-value for the SIP Privacy header: history
本文档为SIP隐私头定义了一个新的priv值：history
The following changes have been made to
http://www.iana.org/assignments/sip-priv-values
The following changes have been made to
http://www.iana.org/assignments/sip-priv-values
The following has been added to the registration for the SIP Privacy header:
以下内容已添加到SIP隐私标头的注册中：
Name Description Registrant Reference
---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC4244]
History-Info header(s) mary.barnes@nortel.com
Name Description Registrant Reference
---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC4244]
History-Info header(s) mary.barnes@nortel.com
[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月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665]Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 36652003年12月。
The editor would like to acknowledge the constructive feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger,
编辑想感谢Robert Sparks、Paul Kyzivat、Scott Orton、John Elwell、Nir Chen、Francois Audet、Palash Jain、Brian Stucker、Norma Ng、Anthony Brown、Jayshree Bharatia、Jonathan Rosenberg、Eric Burger、，
Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Garcin.
Martin Dolly、Roland Jeske、Takuya Sawada、Sebastien Prouvost和Sebastien Garcin。
The editor would like to acknowledge the significant input from Rohan Mahy on some of the normative aspects of the ABNF, particularly around the need for and format of the index and around the security aspects.
编辑想感谢Rohan Mahy在ABNF的一些规范方面的重要投入，特别是在索引的需要和格式以及安全方面。
Cullen, Mark, and Jon contributed to the development of the initial requirements.
Cullen、Mark和Jon对初始需求的开发做出了贡献。
Cullen and Mark provided substantial input in the form of email discussion in the development of the initial version of the individual solution document.
Cullen和Mark以电子邮件讨论的形式在个人解决方案文档初始版本的开发过程中提供了大量投入。
Cullen Jennings Cisco Systems 170 West Tasman Dr MS: SJC-21/3
库伦·詹宁斯思科系统170西塔斯曼博士：SJC-21/3
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925-363-8720
EMail: Jon.Peterson@NeuStar.biz
Phone: +1 925-363-8720
EMail: Jon.Peterson@NeuStar.biz
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
马克·沃森数字喷泉美国加利福尼亚州弗里蒙特市公民中心大道300号39141室，邮编94538。
EMail: mark@digitalfountain.com
EMail: mark@digitalfountain.com
Appendix. Example Scenarios
附录示例场景
The scenarios in Appendices A-D provide sample use cases for the History-Info header for informational purposes only. They are not intended to be normative and the formatting is for visual purposes; thus, the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples with the proper formatting.
附录A-D中的场景提供了历史信息标题的示例用例，仅供参考。它们不是为了规范，格式是为了视觉目的；因此，URI中的头没有正确显示以进行转义。请参阅第4.2节的示例，并提供正确的格式。
Appendix A. Sequentially Forking (History-Info in Response)
附录A.顺序分叉（响应的历史信息）
This scenario highlights an example where the History-Info in the response is useful to an application or user that originated the request.
此场景突出显示了一个示例，其中响应中的历史信息对发起请求的应用程序或用户很有用。
Alice at UA1 sends a call to Bob via Proxy1. Proxy1 sequentially tries several places (UA2, UA3 and UA4) unsuccessfully before sending a response to Alice.
UA1的Alice通过Proxy1向Bob发送电话。Proxy1在向Alice发送响应之前，顺序尝试了几个位置（UA2、UA3和UA4），但未成功。
This scenario is provided to show that by providing the History-Info to UA1, the end-user or an application at UA1 could make a decision on how best to attempt finding Bob. Without this mechanism, UA1 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a third manual attempt at reaching Bob. With this mechanism, either the end-user or application could know that Bob is busy on his home phone and is physically not in the office. If there were an alternative address for Bob known to this end-user or application, that hasn't been attempted, then either the application or the end-user could attempt that. The intent here is to highlight an example of the flexibility of this mechanism that enables applications well beyond SIP as it is certainly well beyond the scope of this document to prescribe detailed applications.
提供此场景是为了说明，通过向UA1提供历史信息，UA1的最终用户或应用程序可以决定如何最好地尝试查找Bob。如果没有这种机制，UA1很可能会尝试UA3（从而尝试UA4），然后在第三次手动尝试到达Bob时重新尝试UA4。通过这种机制，最终用户或应用程序都可以知道Bob正在忙着打家庭电话，实际上不在办公室。如果此最终用户或应用程序已知Bob的替代地址，但尚未尝试，则应用程序或最终用户都可以尝试。这里的目的是强调该机制灵活性的一个示例，该机制使应用程序远远超出SIP，因为规定详细的应用程序肯定远远超出了本文档的范围。
In this scenario, since UA1 has not included the original Request-URI in the INVITE, the proxy adds a hi-entry to capture the original Request-URI to provide the complete set of information, as discussed in Section 4.3.3.1.
在这种情况下，由于UA1没有在INVITE中包含原始请求URI，代理添加一个hi条目来捕获原始请求URI，以提供完整的信息集，如第4.3.3.1节所述。
UA1 Proxy1 UA2 UA3 UA4
| | | | |
|-INVITE F1->| | | |
| | | | |
| |--INVITE F2------>| | |
|<--100 F3---| | | |
| |<-302 F4----------| | |
| | | | |
| |-------INVITE F5 --------->| |
| | | | |
| |<-------180 F6 ------------| |
|<---180 F7--| | | |
| . . |---retransmit INVITE ----->| |
| | | | |
| | ( timeout ) | | |
| | | | |
| |------INVITE F8 ------------------->|
|<--100 F9 --| | | |
| | | | |
| |<-486 F10 --------------------------|
| | | | |
| |-- ACK F11------------------------->|
|<--486 F12--| | | |
| | | | |
|--ACK F13-->| | | |
| | | | |
UA1 Proxy1 UA2 UA3 UA4
| | | | |
|-INVITE F1->| | | |
| | | | |
| |--INVITE F2------>| | |
|<--100 F3---| | | |
| |<-302 F4----------| | |
| | | | |
| |-------INVITE F5 --------->| |
| | | | |
| |<-------180 F6 ------------| |
|<---180 F7--| | | |
| . . |---retransmit INVITE ----->| |
| | | | |
| | ( timeout ) | | |
| | | | |
| |------INVITE F8 ------------------->|
|<--100 F9 --| | | |
| | | | |
| |<-486 F10 --------------------------|
| | | | |
| |-- ACK F11------------------------->|
|<--486 F12--| | | |
| | | | |
|--ACK F13-->| | | |
| | | | |
Message Details
消息详细信息
F1 INVITE UA1 ->Proxy1
F1邀请UA1->Proxy1
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for UA1 prepares to receive data on port 49170
from the network. */
/*Client for UA1 prepares to receive data on port 49170
from the network. */
F2 INVITE Proxy1 ->UA2
F2 INVITE Proxy1->UA2
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com>; index=1.1
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com>; index=1.1
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F3 100 Trying Proxy1 ->UA1
F3 100正在尝试Proxy1->UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F4 302 Moved Temporarily UA2 ->Proxy1
F4 302临时移动UA2->Proxy1
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
F5 INVITE Proxy1 -> UA3
F5邀请代理1->UA3
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1.1,
<sip:UserB@example.com>;index=1.2
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1.1,
<sip:UserB@example.com>;index=1.2
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F6 180 Ringing UA3 ->Proxy1
F6 180振铃UA3->Proxy1
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F7 180 Ringing Proxy1 -> UA1
F7 180振铃代理->UA1
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* The proxy forwards the INVITE to UA4 after adding the
additional History Information entry. */
/* The proxy forwards the INVITE to UA4 after adding the
additional History Information entry. */
F8 INVITE Proxy1 -> UA4
F8邀请Proxy1->UA4
INVITE sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F9 100 Trying Proxy1 ->UA1
F9 100正在尝试Proxy1->UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F10 486 Busy Here UA4 -> Proxy1
F10 486此处忙UA4->Proxy1
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE Content-Length: 0
CSeq:1邀请内容长度：0
F11 ACK Proxy1 -> UA4
F11确认代理->UA4
ACK sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
ACK sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
/* The proxy forwards the 486 to Alice after adding the
associated History Information entries from the series of
INVITES */
/* The proxy forwards the 486 to Alice after adding the
associated History Information entries from the series of
INVITES */
F12 486 Busy Here Proxy1 -> UA1
F12 486此处忙代理->UA1
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Content-Length: 0
F13 ACK Alice -> Proxy 1
F13确认->代理1
ACK sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
ACK sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
This scenario highlights an example where the History-Info in the request is primarily of use by an edge service (e.g., voicemail server). It should be noted that this isn't intended to be a complete specification for this specific edge service as it is quite likely that additional information is needed by the edge service. History-Info is just one building block that this service makes use of.
此场景突出显示了一个示例，其中请求中的历史信息主要由边缘服务（例如，语音邮件服务器）使用。应该注意的是，这并不是此特定边缘服务的完整规范，因为边缘服务很可能需要其他信息。历史信息只是此服务使用的一个构建块。
UA1 called UA A, which had been forwarded to UA B, which forwarded to a UA VM (voicemail server). Based upon the retargeted URIs and Reasons (and other information) in the INVITE, the VM server makes a policy decision about what mailbox to use, which greeting to play, etc.
UA1称为UA A，已转发给UA B，后者转发给UA VM（语音邮件服务器）。VM服务器根据INVITE中重定目标的URI和原因（以及其他信息），就使用哪个邮箱、播放哪个问候语等做出策略决定。
UA1 Proxy UA-A UA-B UA-VM
UA1代理UA-A UA-B UA-VM
| | | | |
|--INVITE F1-->| | | |
| | | | |
| |--INVITE F2-->| | |
|<--100 F3-----| | | |
| |<-302 F4------| | |
| | | | |
| |--------INVITE F5---------->| |
| | | | |
| |<--------180 F6-------------| |
|<---180 F7----| | | |
| . . . | | | |
| |------retransmit INVITE---->| |
| . . . | | | |
| | (timeout) | |
| | | | |
| |-------INVITE F8---------------------->|
| | | | |
| |<-200 F9-------------------------------|
| | | | |
|<-200 F10-----| | | |
| | | | |
|--ACK F11-------------------------------------------->|
| | | | |
|--INVITE F1-->| | | |
| | | | |
| |--INVITE F2-->| | |
|<--100 F3-----| | | |
| |<-302 F4------| | |
| | | | |
| |--------INVITE F5---------->| |
| | | | |
| |<--------180 F6-------------| |
|<---180 F7----| | | |
| . . . | | | |
| |------retransmit INVITE---->| |
| . . . | | | |
| | (timeout) | |
| | | | |
| |-------INVITE F8---------------------->|
| | | | |
| |<-200 F9-------------------------------|
| | | | |
|<-200 F10-----| | | |
| | | | |
|--ACK F11-------------------------------------------->|
Message Details
消息详细信息
INVITE F1 UA1->Proxy
邀请F1 UA1->代理
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for UA1 prepares to receive data on port 49170
from the network. */
/*Client for UA1 prepares to receive data on port 49170
from the network. */
INVITE F2 Proxy->UA-A
邀请F2代理->UA-A
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDPims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@ims.example.com>; index=1
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDPims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@ims.example.com>; index=1
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
100 Trying F3 Proxy->UA1
100正在尝试F3代理->UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
302 Moved Temporarily F4 UserA->Proxy
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
302 Moved Temporarily F4 UserA->Proxy
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
INVITE F5 Proxy-> UA-B
邀请F5代理->UA-B
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1,
<sip:UserB@example.com>;index=2
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1,
<sip:UserB@example.com>;index=2
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
180 Ringing F6 UA-B ->Proxy
180振铃F6 UA-B->代理
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
To: LittleGuy <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
180 Ringing F7 Proxy-> UA1
180振铃F7代理->UA1
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* The proxy forwards the INVITE to UA-VM after adding the
additional History Information entry. */
/* The proxy forwards the INVITE to UA-VM after adding the
additional History Information entry. */
INVITE F8 Proxy-> UA-VM
邀请F8代理->UA-VM
INVITE sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info:<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=2,
<sip:VM@example.com>;index=3
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info:<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=2,
<sip:VM@example.com>;index=3
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F9
200好F9
SIP/2.0 200 OK UA-VM->Proxy
SIP/2.0 200 OK UA-VM->代理
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F10 Proxy->UA1
200正常F10代理->UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
SIP/2.0 200 OK
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK F11 UA1-> UA-VM
确认F11 UA1->UA-VM
ACK sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
ACK sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 ACK Content-Length: 0
CSeq:1确认内容长度：0
/* RTP streams are established between UA1 and
UA-VM. UA-VM starts announcement for UA1 */
/* RTP streams are established between UA1 and
UA-VM. UA-VM starts announcement for UA1 */
This scenario highlights an example of an Automatic Call Distribution service, where the agents are divided into groups based upon the type of customers they handle. In this example, the Gold customers are given higher priority than Silver customers, so a Gold call would get serviced even if all the agents servicing the Gold group (ACDGRP1) were busy, by retargeting the request to the Silver Group. Upon receipt of the call at the agent assigned to handle the incoming call, based upon the History-Info header in the message, the application at the agent can provide an indication that this is a Gold call, from how many groups it might have overflowed before reaching the agent, etc. and thus can be handled appropriately by the agent.
此场景突出显示了自动呼叫分配服务的一个示例，其中代理根据其处理的客户类型划分为多个组。在本例中，黄金客户的优先级高于白银客户，因此，即使为黄金组（ACDGRP1）提供服务的所有代理都很忙，黄金呼叫也会得到服务，方法是将请求重新定位到白银组。在被指派来处理传入呼叫的代理处接收到呼叫时，基于消息中的历史信息报头，代理处的应用程序可以提供一个指示，表明这是一个Gold呼叫，在到达代理之前它可能溢出了多少组，等等，因此可以由代理适当地处理。
For scenarios whereby calls might overflow from the Silver to the Gold, clearly the alternate group identification, internal routing, or actual agent that handles the call SHOULD not be sent to UA1. Thus, for this scenario, one would expect that the Proxy would not support the sending of the History-Info in the response, even if requested by the calling UA.
对于呼叫可能从银到金溢出的场景，显然不应将备用组标识、内部路由或处理呼叫的实际代理发送到UA1。因此，对于这种情况，可以预期代理将不支持在响应中发送历史信息，即使呼叫UA请求。
As with the other examples, this is not prescriptive of how one would do this type of service but an example of a subset of processing that might be associated with such a service. In addition, this example is not addressing any aspects of Agent availability, which might also be done via a SIP interface.
与其他示例一样，这不是说明如何执行此类服务，而是可能与此类服务关联的处理子集的示例。此外，此示例没有解决代理可用性的任何方面，这也可以通过SIP接口完成。
UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
UA1代理ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
| | | | |
|--INVITE F1-->| | | |
Supported:histinfo
| | | | |
| |--INVITE F2-->| | |
Supported:histinfo
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
| | | | |
| |<-302 F3------| | |
Contact: <sip:ACDGRP2@ACD.com>
| | | | |
| |--------INVITE F4---------->| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | | |
| | | |INVITE F5>|
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | |<-200 F6--|
| | | | |
| |<-200 F7--------------------| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
|<-200 F8------| | | |
< No History-Info included in the response due to Local Policy>
| | | | |
|--ACK F9--------------------------------------------->|
| | | | |
|--INVITE F1-->| | | |
Supported:histinfo
| | | | |
| |--INVITE F2-->| | |
Supported:histinfo
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
| | | | |
| |<-302 F3------| | |
Contact: <sip:ACDGRP2@ACD.com>
| | | | |
| |--------INVITE F4---------->| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | | |
| | | |INVITE F5>|
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | |<-200 F6--|
| | | | |
| |<-200 F7--------------------| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
|<-200 F8------| | | |
< No History-Info included in the response due to Local Policy>
| | | | |
|--ACK F9--------------------------------------------->|
In this scenario, Alice places a call to Bob using first a Redirect server then a Proxy Server. The INVITE message is first sent to the Redirect Server. The Server returns a 302 Moved Temporarily response (F2) containing a Contact header with Bob's current SIP address. Alice then generates a new INVITE with Bob's current SIP address included in another History-Info entry. The INVITE is then sent to Bob via the Proxy Server, with Bob receiving the complete History information; the call then proceeds normally. The complete call flow for this scenario, without the use of History-Info, is described in Section 3.6 of the SIP Basic Call Flow Examples [RFC3665].
在这个场景中，Alice首先使用重定向服务器，然后使用代理服务器调用Bob。INVITE消息首先发送到重定向服务器。服务器返回302移动临时响应（F2），其中包含带有Bob当前SIP地址的联系人头。Alice然后生成一个新的邀请，其中Bob的当前SIP地址包含在另一个历史信息条目中。然后通过代理服务器将INVITE发送给Bob，Bob接收完整的历史信息；然后通话正常进行。SIP基本呼叫流示例[RFC3665]的第3.6节描述了此场景的完整呼叫流（不使用历史信息）。
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
Message Details
消息详细信息
F1 INVITE Alice -> Redirect Server
F1邀请Alice->重定向服务器
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:alice@client.atlanta.example.com>
Content-Length: 0
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:alice@client.atlanta.example.com>
Content-Length: 0
F2 302 Moved Temporarily Redirect Proxy -> Alice
F2 302临时移动重定向代理->Alice
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.1
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.1
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:bob@chicago.example.com;transport=tcp>
Content-Length: 0
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:bob@chicago.example.com;transport=tcp>
Content-Length: 0
F3 ACK Alice -> Redirect Server
F3确认Alice->重定向服务器
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
F4 INVITE Alice -> Proxy 3
F4邀请Alice->Proxy 3
INVITE sip:bob@chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
INVITE sip:bob@chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
F5 INVITE Proxy 3 -> Bob
F5邀请代理3->Bob
INVITE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.1
Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2,
<sip:bob@client.chicago.example.com>; index=2.1
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
INVITE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.1
Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2,
<sip:bob@client.chicago.example.com>; index=2.1
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
内容长度：0
Detailed Call Flow continues per section 6.3 in [RFC3665].
按照[RFC3665]中的第6.3节继续详细的呼叫流程。
Editor's Address
编辑地址
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX USA
美国德克萨斯州理查森湖畔大道2201号玛丽·巴恩斯北电
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
电话：1-972-684-5432电子邮件：玛丽。barnes@nortel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。