Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8119 Orange
Updates: 4458 M. Barnes
Category: Informational MLB@Realtime Communications
ISSN: 2070-1721 March 2017
Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8119 Orange
Updates: 4458 M. Barnes
Category: Informational MLB@Realtime Communications
ISSN: 2070-1721 March 2017
SIP "cause" URI Parameter for Service Number Translation
用于服务编号转换的SIP“cause”URI参数
Abstract
摘要
RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.
RFC 4458（关于应用程序的SIP URI）定义了“原因”URI参数，该参数可能出现在SIP请求的请求URI中，用于指示请求到达接收消息的用户代理服务器（UAS）的原因。本文档通过为“原因”URI参数创建一个新的预定义值来更新RFC 4458，以涵盖由于导致被调用服务访问号转换的特定服务操作而导致重定目标的情况下的服务号转换。本文档还提供了RFC 4458中缺少的关于在历史信息头字段中使用“原因”URI参数的指导，因为在某些IP网络的实现中必须使用此参数。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8119.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8119.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction, Terminology, and Overview . . . . . . . . . . . 2
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Interaction with Request History Information . . . . . . 4
3.2. Handling and Processing the Service Number Translation
"cause" URI Parameter Value . . . . . . . . . . . . . . . 5
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction, Terminology, and Overview . . . . . . . . . . . 2
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Interaction with Request History Information . . . . . . 4
3.2. Handling and Processing the Service Number Translation
"cause" URI Parameter Value . . . . . . . . . . . . . . . 5
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
[RFC4458] defines a mechanism to identify retargeting due to call forwarding supplementary services. The "cause" URI parameter in the target URI identifies the reason for retargeting and has defined values equivalent to the TDM (Time Division Multiplexing) Redirecting Reasons [ITU-T_Q.763]. The concept of "retargeting" is defined in [RFC7044].
[RFC4458]定义了一种机制，用于识别由于呼叫转移补充服务而导致的重定目标。目标URI中的“原因”URI参数标识重定目标的原因，并定义了与TDM（时分复用）重定目标原因等效的值[ITU-T_Q.763]。[RFC7044]中定义了“重定目标”的概念。
In the Public Switched Telephone Network (PSTN ) / Integrated Services Digital Network (ISDN), there is another kind of retargeting introduced by the Intelligent Network (IN) services based on a translation of the called number as mentioned in [ITU-T_Q.1214]. Indeed, IN aims to ease the introduction of new services (i.e., Universal Personal Telecommunication (UPT), Virtual Private Network (VPN), Freephone, etc.) based on greater flexibility and new
在公共交换电话网（PSTN）/综合业务数字网（ISDN）中，智能网（In）业务基于[ITU-T_Q.1214]中提到的被叫号码的转换引入了另一种重定目标。事实上，IN旨在基于更大的灵活性和新技术，简化新服务（即通用个人电信（UPT）、虚拟专用网络（VPN）、免费电话等）的引入
capabilities as described in [ITU-T_I.312_Q.1201]. For these IN services, ISDN User Part (ISUP) introduced the "called IN number" and the "original called IN number" parameters to capture the information of the requested service access number prior its translation [ITU-T_Q.763].
[ITU-T_I.312_Q.1201]中所述的功能。对于这些IN业务，ISDN用户部分（ISUP）引入了“被叫号码”和“原始被叫号码”参数，以在转换之前捕获请求的业务接入号码的信息[ITU-T_Q.763]。
The term "service access number" is used in this specification to refer to the dialable number by which a specific service is reached. This special number is not a globally routable number; therefore, it needs to be translated into a routable SIP or tel URI to process the session establishment.
术语“服务接入号码”在本规范中用于指达到特定服务的可拨打号码。此特殊号码不是全局可路由号码；因此，需要将其转换为可路由的SIP或tel URI来处理会话建立。
This specification proposes a solution to allow the identification of well-known services, such as premium or toll-free services that perform service access number translation, and to enable interworking with SIP signaling with the ISUP called IN number and original called IN number parameters.
本规范提出了一种解决方案，以允许识别众所周知的服务，例如执行服务接入号码转换的高级或免费服务，并允许使用ISUP呼入号码和原始呼入号码参数与SIP信令进行互通。
The mechanism will allow a SIP network to insert and convey the service access number requested before its translation to the final destination.
该机制将允许SIP网络在将请求的服务接入号码转换到最终目的地之前插入并传输该号码。
In order to provide full call forwarding or access number translation services, usage of the "cause" URI parameter is only relevant within the History-Info header field defined in [RFC7044]. Because this relation has not been described in [RFC4458], this document provides guidance for using the "cause" URI parameter in conjunction with the History-Info header field.
为了提供完整的呼叫转移或访问号码转换服务，“原因”URI参数的使用仅与[RFC7044]中定义的历史信息标头字段相关。由于[RFC4458]中未描述此关系，因此本文档提供了将“原因”URI参数与历史信息标题字段结合使用的指南。
This document also answers a need expressed by the Third Generation Partnership Project (3GPP) [TS.3GPP.24.229] to identify the service access number. The procedures it defines are intended for networks that use 3GPP-defined services. Their use is undefined for other networks.
本文件还回答了第三代合作伙伴计划（3GPP）[TS.3GPP.24.229]提出的识别服务接入号码的需求。它定义的过程适用于使用3GPP定义的服务的网络。它们在其他网络中的用途尚未定义。
A new value for the "cause" URI parameter of the 'sip:' or 'sips:' URI schemes is defined for the "Service number translation" use case. This value may be used in a 'sip:' or 'sips:' URI inserted in the Request-URI and in the History-Info header field [RFC7044] when the URI is issued from a retargeting or a service access number translation by a specific service similar to PSTN/ISDN IN services that is not a call forwarding service.
为“服务编号转换”用例定义了“sip:”或“sips:”URI方案的“cause”URI参数的新值。当URI由非呼叫转发服务中类似于PSTN/ISDN的特定服务通过重定目标或服务访问号码转换发出时，此值可用于插入请求URI和历史信息头字段[RFC7044]中的“sip:”或“sips:”URI。
As defined in [RFC4458], the "cause" URI parameter must be encoded in the new target URI when generated by the service.
如[RFC4458]中所定义，“原因”URI参数在由服务生成时必须编码在新的目标URI中。
The ABNF grammar [RFC5234] for the cause-param and target-param parameters from [RFC4458] is summarized below (including updates described in [Err1409]). The Status-Code is defined in [RFC3261].
[RFC4458]中原因参数和目标参数的ABNF语法[RFC5234]总结如下（包括[Err1409]中描述的更新）。状态代码在[RFC3261]中定义。
target-param = "target=" pvalue
target param=“target=”pvalue
cause-param = "cause=" Status-Code
原因参数=“原因=“状态代码
The following value for this URI parameter is added to the existing ones:
此URI参数的以下值将添加到现有值中：
+---------------------------------+-------+
| Cause | Value |
+---------------------------------+-------+
| Service number translation | 380 |
+---------------------------------+-------+
+---------------------------------+-------+
| Cause | Value |
+---------------------------------+-------+
| Service number translation | 380 |
+---------------------------------+-------+
In order to help implementation of this solution for conveyance of the service access number, this document proposes guidance for usage of the "cause" URI parameter: guidance for the usage of the "cause" URI parameter in the request history information (in Section 3.1) and guidance for processing a service number translation service using the new "cause" URI parameter value (in Section 3.2).
为了帮助实现该服务访问号传输解决方案，本文档提出了“原因”URI参数的使用指南：请求历史信息中“原因”URI参数的使用指南（第3.1节）和使用新的“原因”URI参数值（见第3.2节）。
The History-Info header field defined in [RFC7044] specifies a means of providing the UAS and User Agent Client (UAC) with information about the retargeting of a request. This information includes the initial Request-URI and any retargeted URIs. This information is placed in History-Info headers as the request is retargeted and, upon reaching the UAS, is returned in certain responses. The History-Info header field enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user and to keep this information throughout the signaling path even when successive applications are involved.
[RFC7044]中定义的历史信息头字段指定了向UAS和用户代理客户端（UAC）提供请求重定目标信息的方法。此信息包括初始请求URI和任何重定目标URI。当请求被重定目标时，该信息被放置在历史信息头中，并且在到达UAS时，在某些响应中返回。History Info header字段通过提供关于SIP请求如何以及为什么到达特定应用程序或用户的信息，并在整个信令路径中保留该信息，即使涉及后续应用程序，从而启用许多增强的服务。
When a proxy inserts a URI containing the "cause" URI parameter defined in [RFC4458] into the Request-URI of a forwarded request (per [RFC7044]), the proxy must also copy this new Request-URI within a History-Info header field entry into the forwarded request; thus, the URI in that entry includes the "cause" URI parameter. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which can be of use to the UAS. Note that if a proxy does not support generation of the History-Info header field or
当代理将包含[RFC4458]中定义的“原因”URI参数的URI插入转发请求的请求URI（根据[RFC7044]）时，代理还必须将历史信息头字段条目中的新请求URI复制到转发请求中；因此，该条目中的URI包含“原因”URI参数。因此，即使请求URI由于下游代理的重新路由而被替换，历史信息头字段仍将包含这些参数，这些参数可用于UAS。请注意，如果代理不支持生成历史信息头字段或
if a downstream proxy removes the History-Info header fields, an application will only have access to the "cause" URI parameter if the request is not subsequently retargeted (i.e., it will be contained only in the Request-URI in the incoming request). The implications of the solution are further discussed in Section 3.2.
如果下游代理删除历史信息头字段，则如果请求随后未被重定目标（即，它将仅包含在传入请求的请求URI中），则应用程序将只能访问“原因”URI参数。第3.2节将进一步讨论解决方案的含义。
In order to be able to filter specific entries among the history information, header field parameters have been defined in [RFC7044]. In particular, the "mp" and "rc" header field parameters have the following definitions:
为了能够过滤历史信息中的特定条目，在[RFC7044]中定义了标题字段参数。特别是，“mp”和“rc”标题字段参数具有以下定义：
o When the new target was determined based on a mapping to a user other than the target user associated with the Request-URI being retargeted, the "mp" header field parameter is added. This allows the identification of retargets that are the result of an application decision on a user's behalf and also retargets that are the result of an internal decision made by an application.
o 当基于到与被重定目标的请求URI关联的目标用户以外的用户的映射确定新目标时，将添加“mp”头字段参数。这允许识别作为代表用户的应用程序决策的结果的重定目标，以及作为应用程序作出的内部决策的结果的重定目标。
o The "rc" header field parameter is added when the new target represents a change in Request-URI, while the target user remains the same.
o 当新目标表示请求URI中的更改，而目标用户保持不变时，将添加“rc”头字段参数。
These header field parameters can be used in conjunction with the new "cause" URI parameter for certain applications, an example of which is provided in Section 4.
对于某些应用程序，这些头字段参数可以与新的“原因”URI参数结合使用，第4节提供了一个示例。
When using the History-Info header field in conjunction with the "cause" URI parameter in a Request-URI, it is important to consider that the "cause" URI parameter is not the same parameter as the "cause" header field parameter included in the Reason header [RFC3326]. The "cause" header field parameter of the Reason header field should be added to a History-Info entry only when the retargeting is due to a received SIP response.
在使用历史信息头字段与请求URI中的“原因”URI参数一起使用时，重要的是要考虑“原因”URI参数不是与原因头[RFC3626]中包含的“原因”标题字段参数相同的参数。仅当重定目标是由于接收到SIP响应时，才应将原因标头字段的“原因”标头字段参数添加到历史信息条目中。
3.2. Handling and Processing the Service Number Translation "cause" URI Parameter Value
3.2. 处理和处理服务编号转换“原因”URI参数值
At the Application Server:
在应用程序服务器上：
When an application receiving a request that is addressed to a service access number changes the Request-URI into a routable number, it should insert within this new Request-URI a "cause" URI parameter value set to 380 "Service number translation". Following the process described in [RFC7044], the application server adds a new History-Info header field entry including the new Request-URI value including the "cause" URI parameter. It is
当一个应用程序接收到一个发往服务访问号码的请求时，将请求URI更改为一个可路由号码，它应该在这个新的请求URI中插入一个“原因”URI参数值，该参数值设置为380“服务号码转换”。按照[RFC7044]中描述的过程，应用程序服务器添加一个新的历史信息报头字段条目，包括新的请求URI值，包括“原因”URI参数。它是
also possible for an application server to add a "target" URI parameter as defined in [RFC4458] with the initial value of the Request-URI received by the application server.
应用服务器还可以添加[RFC4458]中定义的“target”URI参数以及应用服务器接收的请求URI的初始值。
Note that if the new Request-URI is further replaced by a downstream proxy for any reason and if the History-Info header field is not supported, the information of the service access number initially requested would be lost. Thus, it is strongly recommended to support the History-Info header field all along the signaling path.
请注意，如果出于任何原因，新的请求URI被下游代理进一步替换，并且如果不支持History Info header字段，则最初请求的服务访问号的信息将丢失。因此，强烈建议沿信令路径支持历史信息报头字段。
At the UAS:
在UAS：
When the UAS receiving the request wants to retrieve the service access number by which it has been reached, first it should look for the "cause" URI parameter value 380 in the History-Info header field. This History-Info entry should also contain an "mp" or "rc" header field parameter so that the UAS can find the requested service number in the History-Info entry having an index parameter value that matches this "mp" or "rc" header field parameter value. If, for any reason, there is no "mp" or "rc" header field parameter in the identified History-Info entry, the UAS can find the requested service number in the preceding History-Info entry.
当接收请求的UAS想要检索已到达的服务访问号时，首先应在历史信息报头字段中查找“原因”URI参数值380。此历史信息条目还应包含“mp”或“rc”头字段参数，以便UAS可以在历史信息条目中找到请求的服务编号，该历史信息条目具有与此“mp”或“rc”头字段参数值匹配的索引参数值。如果由于任何原因，在识别的历史信息条目中没有“mp”或“rc”头字段参数，UAS可以在前面的历史信息条目中找到请求的服务编号。
If the History-Info header is not supported or has been removed by a proxy for any reason, the UAS might be able to find the requested service access number before translation in either of the following ways, but there is no guarantee:
如果历史信息头不受支持或由于任何原因被代理删除，UAS可能能够在转换前通过以下任一方式找到请求的服务访问号码，但不能保证：
o If the UAS is the direct target of the request coming from the application, the UAS ought to be able to find the service access number in the "target" URI parameter of the Request-URI if there is also a "cause" URI parameter set to 380 in this Request-URI.
o 如果UAS是来自应用程序的请求的直接目标，则如果在该请求URI中还存在设置为380的“原因”URI参数，则UAS应该能够在请求URI的“目标”URI参数中找到服务访问号。
o If there is no "cause" URI parameter set to 380 in the Request-URI and there is no History-Info header field, the UAS will not be able to reliably retrieve the service access number before translation. Some existing implementations are known to extract the number from the To header field. While that approach may work in some situations, it will not work in the general case because the To header field value is sometimes changed by intermediaries, and such a change is not always detectable.
o 如果请求URI中没有设置为380的“原因”URI参数，并且没有历史信息头字段，UAS将无法在转换之前可靠地检索服务访问号。已知一些现有的实现从to头字段提取数字。虽然这种方法在某些情况下可能有效，但它在一般情况下不起作用，因为中间人有时会更改To标头字段值，并且这种更改并不总是可以检测到。
In this section, an example is provided to illustrate the application of the new cause-param value.
在本节中，提供了一个示例来说明新的原因参数值的应用。
In this example, Alice calls her bank customer care. John is the person at the call center that answers the call. John is in a call center that manages several toll-free services, and he needs to know for which service Alice is calling in order to provide the appropriate welcome speech.
在本例中，Alice称她的银行客户关怀中心为。约翰是呼叫中心接听电话的人。John所在的呼叫中心管理着多个免费服务，他需要知道Alice呼叫的是哪种服务，以便提供适当的欢迎词。
Alice Toll-Free Service Atlanta.com John
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | | INVITE F3 |
| | |------------------>|
Alice Toll-Free Service Atlanta.com John
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | | INVITE F3 |
| | |------------------>|
* Rest of flow not shown *
* 未显示流的其余部分*
Figure 1: Service Access Number Translation Example
图1：服务访问编号转换示例
Message Details
消息详细信息
F1 INVITE [2001:db8:9::2] -> Toll-Free Service
F1 INVITE [2001:db8:9::2] -> Toll-Free Service
In the initial request, the Request-URI contains the toll-free number dialed by Alice.
在初始请求中，请求URI包含Alice拨打的免费电话号码。
INVITE sip:+18005551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:+18005551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[未显示SDP]
F2 INVITE Toll-Free Service -> Atlanta.com
F2邀请免费服务->亚特兰大网站
The toll-free application receives the request and translates the service number into a routable number toward the call center. The Request-URI is changed, and, in the new Request-URI, a "cause" URI parameter set to 380 is added. As there was no History-Info header field in the received request, the application creates a History-Info header with two entries: one for the received Request-URI and one for the new Request-URI.
免费应用程序接收请求，并将服务号码转换为可路由号码，发送至呼叫中心。更改请求URI，并且在新的请求URI中，添加设置为380的“原因”URI参数。由于接收到的请求中没有历史信息头字段，应用程序将创建一个历史信息头，其中包含两个条目：一个用于接收到的请求URI，另一个用于新请求URI。
INVITE sip:+15555551002@atlanta.com;cause=380;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 69
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:+15555551002@atlanta.com;cause=380;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 69
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[未显示SDP]
F3 INVITE Atlanta.com -> John
F3邀请亚特兰大网站->约翰
The call center proxy routes the received request to John's IP address by changing the Request-URI. When changing the Request-URI, the proxy adds a new entry in the History-Info header field.
呼叫中心代理通过更改请求URI将收到的请求路由到John的IP地址。更改请求URI时，代理会在历史信息标头字段中添加一个新条目。
INVITE sip:john@[2001:db8:b::2] SIP/2.0
Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 68
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
History-Info: <sip:john@[2001:db8:b::2]>;index=1.1.1;rc=1.1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE sip:john@[2001:db8:b::2] SIP/2.0
Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 68
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
History-Info: <sip:john@[2001:db8:b::2]>;index=1.1.1;rc=1.1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[未显示SDP]
NOTE: Line breaks are for display purpose only
注：换行符仅用于显示目的
[RFC4458] defines a "cause" URI parameter specified as having predefined values. This document defines a new value for the "cause" URI parameter: 380.
[RFC4458]定义指定为具有预定义值的“原因”URI参数。本文档为“原因”URI参数定义了一个新值：380。
IANA has modified the existing row for the "cause" URI parameter to add a reference to this document under the "SIP/SIPS URI Parameters" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANA修改了“原因”URI参数的现有行，以便在“会话启动协议（SIP）参数”注册表中的“SIP/SIPS URI参数”子区域下添加对本文档的引用：
Parameter Name Predefined Values Reference
-------------- ----------------- ----------------------
cause Yes [RFC4458][RFC8119]
Parameter Name Predefined Values Reference
-------------- ----------------- ----------------------
cause Yes [RFC4458][RFC8119]
The security considerations in [RFC4458] apply.
[RFC4458]中的安全注意事项适用。
If a privacy level of 'header' is requested in the Privacy header field as described in [RFC3323], the "cause" URI parameter must be removed from the Request-URI to maintain the network-provided privacy requested. Privacy of the parameters, when they form part of a URI within the History-Info header field, is covered in [RFC7044].
如[RFC3323]所述，如果在隐私标头字段中请求“标头”的隐私级别，则必须从请求URI中删除“原因”URI参数，以维护所请求的网络提供的隐私。[RFC7044]中介绍了当参数构成历史信息头字段中URI的一部分时参数的隐私。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<http://www.rfc-editor.org/info/rfc3323>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，DOI 10.17487/RFC3326，2002年12月<http://www.rfc-editor.org/info/rfc3326>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044]Barnes，M.，Audet，F.，Schubert，S.，van Elburg，J.，和C.Holmberg，“请求历史信息会话启动协议（SIP）的扩展”，RFC 7044，DOI 10.17487/RFC70442014年2月<http://www.rfc-editor.org/info/rfc7044>.
[TS.3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 13.6.0.0, January 2015.
[TS.3GPP.24.229]3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229 13.6.0.012015年1月。
[Err1409] RFC Errata, Erratum ID 1409, RFC 4458.
[Err1409]RFC勘误表，勘误表ID 1409，RFC 4458。
[ITU-T_I.312_Q.1201] ITU-T, "Principles of Intelligent Network Architecture", ITU-T Recommendation I312/Q.1201, October 1992.
[ITU-T_I.312_Q.1201]ITU-T，“智能网络体系结构原则”，ITU-T建议I312/Q.12011992年10月。
[ITU-T_Q.1214] ITU-T, "Distributed Functional Plane For Intellignet Network CS-1", ITU-T Recommendation Q.1214, October 1995.
[ITU-T_Q.1214]ITU-T，“智能网CS-1的分布式功能平面”，ITU-T建议Q.1214，1995年10月。
[ITU-T_Q.763] ITU-T, "Signalling System No. 7 -- ISDN User Part formats and codes", ITU-T Recommendation Q.763, December 1999.
[ITU-T_Q.763]ITU-T，“第7号信令系统——ISDN用户部分格式和代码”，ITU-T建议Q.763，1999年12月。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, DOI 10.17487/RFC4458, April 2006, <http://www.rfc-editor.org/info/rfc4458>.
[RFC4458]Jennings，C.，Audet，F.，和J.Elwell，“语音邮件和交互式语音应答（IVR）等应用程序的会话启动协议（SIP）URI”，RFC 4458，DOI 10.17487/RFC4458，2006年4月<http://www.rfc-editor.org/info/rfc4458>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
Acknowledgements
致谢
The authors wish to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks also to Paul Kyzivat, Dale Worley, Jean Mahoney, Robert Sparks, Joel Halpern, and Lionel Morand for their detailed reviews of the document. Special thanks to Ben Campbell for his help to make the work progress.
作者希望感谢3GPP社区对该文档提供的指导、意见和评论。还要感谢保罗·基齐瓦特、戴尔·沃利、让·马奥尼、罗伯特·斯帕克斯、乔尔·哈尔潘和莱昂内尔·莫兰德对该文件的详细审查。特别感谢Ben Campbell对工作进展的帮助。
Authors' Addresses
作者地址
Marianne Mohali Orange 44 Avenue de la Republique Chatillon 92320 France
玛丽安·莫哈里·奥兰治法国查蒂隆共和国大道44号92320
Email: marianne.mohali@orange.com
Email: marianne.mohali@orange.com
Mary Barnes MLB@Realtime Communications TX United States of America
玛丽·巴恩斯MLB@Realtime美利坚合众国通信公司
Email: mary.ietf.barnes@gmail.com
Email: mary.ietf.barnes@gmail.com