Internet Engineering Task Force (IETF) K. Drage, Ed.
Request for Comments: 7434 Alcatel-Lucent
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
January 2015
Internet Engineering Task Force (IETF) K. Drage, Ed.
Request for Comments: 7434 Alcatel-Lucent
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
January 2015
Interworking ISDN Call Control User Information with SIP
与SIP互通ISDN呼叫控制用户信息
Abstract
摘要
The motivation and use cases for interworking and transporting User-to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.
RFC 6567中描述了从SIP中的ITU-T数字用户信令系统1号（DSS1）用户信息元素互通和传输用户对用户信息（UUI）的动机和用例。随着网络向SIP转移，需要该数据的应用程序能够继续在SIP网络中运行，并且能够与该ISDN服务互通以实现端到端的透明性，这一点非常重要。本文档定义了用户对用户报头字段的用法（称为ISDN UUI包的新包），以启用与此ISDN服务的互通。
This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.
本文件涵盖了与公共ISDN和专用ISDN功能的互通，因此也将讨论与QSIG的潜在互通。
The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.
包由“目的”标头字段参数的新值“isdn uui”标识。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7434.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7434.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of the ISDN User-to-User Service . . . . . . . . . . 3
3.1. The Service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN Service on SIP Operation . . . . . . 6
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition Away from ISDN . . . . . . . . . . . . . . . . . . 7
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC Requirements . . . . . . . . . . . . . . . . . . . . . . 8
8. UAS Requirements . . . . . . . . . . . . . . . . . . . . . . 10
9. UUI Contents . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Considerations for ISDN Interworking Gateways . . . . . . . . 12
11. Coding Requirements . . . . . . . . . . . . . . . . . . . . . 12
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of the ISDN User-to-User Service . . . . . . . . . . 3
3.1. The Service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN Service on SIP Operation . . . . . . 6
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition Away from ISDN . . . . . . . . . . . . . . . . . . 7
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC Requirements . . . . . . . . . . . . . . . . . . . . . . 8
8. UAS Requirements . . . . . . . . . . . . . . . . . . . . . . 10
9. UUI Contents . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Considerations for ISDN Interworking Gateways . . . . . . . . 12
11. Coding Requirements . . . . . . . . . . . . . . . . . . . . . 12
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This document describes a usage of the User-to-User header field defined in [RFC7433] to enable the transport of UUI in ISDN interworking scenarios using SIP [RFC3261]. Specifically, this document discusses the interworking of the following items, which are call control related: ITU-T Recommendation Q.931 DSS1 User-user information element [Q931], ITU-T Recommendation Q.957.1 DSS1 User-to-User Signalling (UUS) supplementary service [Q957.1], and ITU-T Recommendation Q.763 User-to-User information parameter [Q763] data in SIP. Today, UUI is widely used in the Public Switched Telephone Network (PSTN) in contact centers and call centers that are transitioning away from ISDN to SIP.
本文档描述了[RFC7433]中定义的用户到用户报头字段的用法，以使用SIP[RFC3261]在ISDN互通场景中启用UUI传输。具体而言，本文件讨论与呼叫控制相关的以下项目的互通：ITU-T建议Q.931 DSS1用户信息元素[Q931]、ITU-T建议Q.957.1 DSS1用户对用户信令（UUS）补充业务[Q957.1]和ITU-T建议Q.763用户对用户信息参数[Q763]SIP中的数据。如今，UUI被广泛应用于从ISDN向SIP过渡的联络中心和呼叫中心的公共交换电话网（PSTN）。
This usage is not limited to scenarios where interworking will occur. Rather it describes a usage where interworking is possible if interworking is met. That does not preclude its usage directly between two SIP terminals.
这种用法不限于将发生互通的场景。相反，它描述了在满足互通条件下可以互通的用法。这并不排除它直接在两个SIP终端之间使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ISDN defines a number of related services. Firstly, there is a user signalling bearer service that uses the information elements / parameters in the signalling channel to carry the data and does not establish a related circuit-switched connection. For DSS1, this is specified in ITU-T Recommendation Q.931, Sections 3.3 and 7 of [Q931]. Secondly, it defines a User-to-User Signalling (UUS) supplementary service that uses the information elements / parameters in the signalling channel to carry additional data but that is used in conjunction with the establishment of a related circuit-switched connection. This reuses the same information elements / parameters as the user signalling bearer service, with the addition of other signalling information, and for DSS1 this is specified in ITU-T Recommendation Q.957.1 [Q957.1].
ISDN定义了许多相关的服务。首先，存在使用信令信道中的信息元素/参数来承载数据且不建立相关电路交换连接的用户信令承载服务。对于DSS1，ITU-T建议Q.931[Q931]第3.3节和第7节对此进行了规定。其次，它定义了用户对用户信令（UUS）补充业务，该业务使用信令信道中的信息元素/参数来承载附加数据，但与建立相关电路交换连接一起使用。这将重用与用户信令承载服务相同的信息元素/参数，并添加其他信令信息，对于DSS1，这在ITU-T建议Q.957.1[Q957.1]中有规定。
ISDN defines three variants of the UUS supplementary service as follows:
ISDN定义了UUS补充业务的三种变体，如下所示：
UUS1: User-to-User Information exchanged during the setup and clearing phases of a call by transporting DSS1 User-user information elements within call control messages. This in itself has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1 implicit, it is the presence of the user signalling data itself that constitutes the request for the service. UUS1 explicit uses additional supplementary service control information to control the request and granting of the service, as in UUS2 and UUS3. As a result, UUS1 explicit also allows the requester to additionally specify whether the parallel circuit-switched connection should proceed if the UUS1 service cannot be provided (preferred or required);
UUS1：通过在呼叫控制消息中传输DSS1用户信息元素，在呼叫的设置和清除阶段交换的用户对用户信息。这本身有两个子变量，UUS1隐式和UUS1显式。在UUS1隐式中，用户信令数据本身的存在构成了对服务的请求。UUS1 explicit使用额外的补充业务控制信息来控制服务的请求和授予，如UUS2和UUS3中所述。因此，如果无法提供UUS1服务（首选或必需），UUS1 explicit还允许请求者另外指定是否应继续并行电路交换连接；
UUS2: DSS1 User-user information elements exchanged from the sender's point of view during call establishment, between the DSS1 ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION messages; and
UUS2:DSS1用户信息消息内的DSS1警报消息和DSS1连接消息之间在呼叫建立期间从发送方角度交换的DSS1用户信息元素；和
UUS3: DSS1 User-user information elements exchanged while a call is in the Active state, within DSS1 USER INFORMATION messages.
UUS3:DSS1用户信息消息中呼叫处于活动状态时交换的DSS1用户信息元素。
The service is always requested by the calling user.
服务总是由主叫用户请求的。
This document defines only the provision of the ISDN UUS1 implicit supplementary service to interworking scenarios, this being the most widely deployed and used of the various ISDN User-to-User services, and is indeed the one that matches the requirements specified in [RFC6567].
本文件仅定义了为互通场景提供ISDN UUS1隐式补充业务，这是各种ISDN用户对用户服务中部署和使用最广泛的一种，并且确实符合[RFC6567]中规定的要求。
The above comes from the ISDN specifications defined for public networks. There is a parallel set of ISDN specifications defined for private networks (QSIG). These specifications do not define a UUS1 implicit supplementary service. However, implementation of such a UUS1 implicit supplementary service for private networks can readily be constructed in a proprietary fashion based on the specifications for public networks, and evidence suggests that some vendors have done so. On this basis, there is no reason why this package cannot also be used to support interworking with such a private network service, on the assumption that the constraints are exactly the same as those for the public network.
以上内容来自为公共网络定义的ISDN规范。有一套为专用网络（QSIG）定义的ISDN规范。这些规范没有定义UUS1隐式补充服务。然而，基于公共网络的规范，可以以专有方式容易地构造用于专用网络的这种UUS1隐式补充业务的实现，并且有证据表明一些供应商已经这样做了。在此基础上，没有理由不使用此包来支持与此类专用网络服务的互通，前提是约束条件与公共网络的约束条件完全相同。
The ISDN UUS1 service has the following additional characteristics as to the data that can be transported:
ISDN UUS1服务对于可传输的数据具有以下附加特性：
The maximum number of octets of user information that can be transported is 128 octets plus a protocol discriminator. It is noted that some early ISDN implementations had a limitation of 32 octets, but it is understood that these are not currently deployed. While this package does not prohibit longer data fields, the mechanism at any interworking point discards data elements that are too long to handle. The handled length can normally be assumed to be 128 octets.
可以传输的用户信息的最大八位字节数是128个八位字节加上一个协议鉴别器。值得注意的是，一些早期的ISDN实现有32个八位字节的限制，但据了解，目前尚未部署这些八位字节。虽然此包不禁止更长的数据字段，但任何互通点的机制都会丢弃太长而无法处理的数据元素。处理长度通常可以假定为128个八位字节。
The content of the user information octets is described by a single octet protocol discriminator (see Table 4-26 of ITU-T Recommendation Q.931) [Q931]. That protocol discriminator may describe the protocol used within the user data, the structure of the user data, or leave it entirely open. Note that not all values within the protocol discriminator necessarily make sense for use in the ISDN User-to-User service, as the content is aligned with the protocol discriminator that appears at the start of all DSS1 messages (see Table 4-1 of ITU-T Recommendation Q.931) [Q931]. The protocol discriminator value has no impact on the interworking capability.
用户信息八位字节的内容由单个八位字节协议鉴别器描述（参见ITU-T建议Q.931的表4-26）[Q931]。该协议鉴别器可以描述用户数据内使用的协议、用户数据的结构，或者使其完全打开。请注意，并非协议鉴别器中的所有值都必须用于ISDN用户对用户服务，因为内容与出现在所有DSS1消息开头的协议鉴别器一致（参见ITU-T建议Q.931的表4-1）[Q931]。协议鉴别器值对互通能力没有影响。
Only a single piece of UUI data can be transported in each message.
每个消息中只能传输一段UUI数据。
The ISDN service works without encryption or integrity protection. The user trusts the intermediate network elements, and therefore the operator of those elements, not to modify the data and to deliver all the data to the remote user. On a link-by-link basis, message contents are protected at Layer 2 by standard cyclic redundancy check mechanisms -- this allows loss on a link-level basis to be detected but does not guard against fraudulent attacks on the link itself. This does not prevent the use of additional encryption or integrity protection within the UUI data itself, although the limit on the size of the UUI data (protocol discriminator plus 128 octets) will restrict this.
ISDN服务在没有加密或完整性保护的情况下工作。用户信任中间网络元素，因此信任这些元素的操作员，不会修改数据并将所有数据交付给远程用户。在逐链路的基础上，消息内容在第2层受到标准循环冗余检查机制的保护——这允许检测链路级的丢失，但不能防止链路本身的欺诈攻击。这并不妨碍在UUI数据本身内使用额外的加密或完整性保护，尽管对UUI数据大小的限制（协议鉴别器加128个八位字节）将限制这一点。
The ISDN service has the following impacts that need to be understood within the SIP environment.
ISDN服务具有以下影响，需要在SIP环境中理解这些影响。
Call transfer: ISDN call transfer cancels all ISDN User-to-User supplementary services. In the ISDN, if User-to-User data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred.
呼叫转移：ISDN呼叫转移取消所有ISDN用户对用户的补充业务。在ISDN中，如果呼叫转移后需要用户到用户的数据，则必须重新协商UUS3，这不是SIP扩展提供的。此限制对SIP环境的影响是，在发生呼叫转移后，在清除SIP对话框的事务中，无法交换UUI头字段。
Conference: ISDN conferencing allows the user to still exchange User-to-User data after the conference is created. As far as UUS1 is concerned, it is not permitted. The ISDN three-party supplementary service is similar in many ways to conferencing but is signalled using a different mechanism. This means that on clearing, the controller using UUS1 implicit does have the choice of sending data to either or both remote users. Because SIP conferencing cannot completely emulate the ISDN three-party supplementary service at the served user, UUS1 implicit is not possible.
会议：ISDN会议允许用户在创建会议后仍然交换用户间数据。就UUS1而言，这是不允许的。ISDN三方补充业务在许多方面与会议类似，但使用不同的机制发出信号。这意味着在清除时，使用UUS1 implicit的控制器可以选择向其中一个或两个远程用户发送数据。由于SIP会议无法在服务用户处完全模拟ISDN三方补充业务，因此UUS1隐式是不可能的。
Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is sent to the forwarded-to-user (assuming that the call meets requirements for providing the service -- this is impacted by the explicit service only). If the type of diversion is such that the call is also delivered to the forwarding user, they will also receive any UUS1 User-to-User data.
转移：当ISDN转移发生时，任何UUS1用户对用户数据都被发送到转发给用户（假设呼叫满足提供服务的要求——这仅受显式服务的影响）。如果转移的类型使得呼叫也被传递给转发用户，则它们还将接收任何UUS1用户对用户数据。
A method of transport of ISDN User-to-User data is to use SIP-T [RFC3372] and transport the UUI information end-to-end (as part of an ISUP message or QSIG message) as a MIME body. If the SIP-T method of encapsulation of ISDN instead of interworking is used, this is a reasonable mechanism and does not require any extensions to existing SIP-T. However, if true ISDN interworking is being done, and therefore SIP-T would not otherwise be used, this approach is not reasonable because then implementation of the many elements of the ISUP syntax would be required to understand one element of data. Instead, the better approach is to interwork the ISDN User-to-User data using the native SIP UUI transport mechanism, the User-to-User header field. The rest of this document describes this approach.
ISDN用户到用户数据的传输方法是使用SIP-T[RFC3372]并将UUI信息作为MIME主体端到端传输（作为ISUP消息或QSIG消息的一部分）。如果使用封装ISDN而不是互通的SIP-T方法，这是一种合理的机制，不需要对现有SIP-T进行任何扩展。但是，如果正在进行真正的ISDN互通，因此不会使用SIP-T，这种方法是不合理的，因为需要实现ISUP语法的许多元素才能理解一个数据元素。相反，更好的方法是使用本机SIP UUI传输机制（用户到用户报头字段）将ISDN用户到用户数据互通。本文档的其余部分描述了这种方法。
This interworking usage of the SIP UUI mechanism will likely begin with one UA as an ISDN gateway while the other UA is a native SIP endpoint. As networks transition away from ISDN, it is possible that both UAs could become native SIP endpoints. In this case, there is an opportunity to transition away from this ISDN usage to a more general usage of [RFC7433].
SIP UUI机制的这种互通使用很可能从一个UA作为ISDN网关开始，而另一个UA是本机SIP端点。随着网络从ISDN过渡，两个UAs都可能成为本机SIP端点。在这种情况下，有机会从ISDN用途过渡到[RFC7433]的更一般用途。
The SIP UUI mechanism provides a way to achieve this transition. As an endpoint moves from being an ISDN gateway to a native SIP endpoint, and a future package for some form of enhanced UUI has been standardized, the endpoint can carry the UUI data both as ISDN and as the future package in parallel and in the same messages or in different messages depending on the needs of the application. This will permit the other endpoint to use the UUI according to the ISDN UUI package if it is an ISDN gateway or according to the future package if it is a native SIP endpoint.
SIP UUI机制提供了一种实现这种转换的方法。随着端点从ISDN网关移动到本机SIP端点，并且某种形式的增强UUI的未来包已经标准化，端点可以将UUI数据作为ISDN和未来包并行地、在相同的消息中或在不同的消息中承载，具体取决于应用程序的需要。这将允许另一个端点根据ISDN UUI包（如果它是ISDN网关）使用UUI，或者根据未来包（如果它是本机SIP端点）使用UUI。
This document defines the package for the ISDN interworking of UUI that interoperates with ISDN UUS, a supplementary service in which the user is able to send/receive a limited amount of information to/ from another ISDN user over the signalling channel in association with a call to the other ISDN user.
本文件定义了与ISDN UU互操作的UUI的ISDN互通包，这是一种补充业务，其中用户能够通过信令信道向另一ISDN用户发送/接收有限数量的信息，并与对另一ISDN用户的呼叫相关联。
Two examples of ISDN UUI with redirection (transfer and diversion) are defined in [ANSII] and [ETSI].
[ANSII]和[ETSI]中定义了具有重定向（传输和转移）的ISDN UUI的两个示例。
One objective of the design of this package has been to keep the functionality at the interworking point as simple as possible. As a result, there is also only one encoding value specified.
该软件包设计的一个目标是使互通点的功能尽可能简单。因此，也只指定了一个编码值。
Responsibility for respecting the limits has been transferred to the end UA. If an interworking point is reached, and the limitations of the ISDN (see Section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked. This is rather than have the interworking point attempt to resolve the non-compliance with the limitations of ISDN.
遵守限额的责任已移交给最终UA。如果达到互通点，且ISDN的限制（见第3.1节）未得到满足，则UUI数据将不会传输，尽管SIP请求将以其他方式互通。这是不是有互通点试图解决不符合ISDN限制的问题。
The general principals of the UUI mechanism package are, therefore, as follows:
因此，UUI机制包的一般原则如下：
The sending application is expected to limit their sending requirements to the subset provided by the ISDN User-to-User service.
发送应用程序预期将其发送要求限制为ISDN用户对用户服务提供的子集。
The SIP UA will not allow the reception of more than one User-to-User header field relating to the "isdn-uui" package in the same SIP request or response; it will only allow it in a request or response of the appropriate method (INVITE or BYE). What happens to User-to-User header fields relating to other packages is outside the scope of this document.
SIP UA将不允许在同一SIP请求或响应中接收多个与“isdn uui”包相关的用户对用户报头字段；它只允许在适当方法（INVITE或BYE）的请求或响应中使用它。与其他包相关的用户对用户标题字段发生的情况超出了本文档的范围。
An interworking point trying to interwork UUI data that is too long will discard the UUI data but proceed with the interworking. There is no notification of such discard back to the sending user. If the SIP user knows that it is interworking with the ISDN, then the UUI application at the SIP endpoint should limit its communication to packets of 128 octets plus the protocol discriminator, with the knowledge that discard will occur if it does not. The UUI application at the SIP endpoint has complete control over what occurs. It should be noted that this was exactly the envisaged operation when early ISDN implementations that only supported 32 octets interworked with those supporting 128 octets. It also corresponds to the interworking with ISDNs that do not support the supplementary service at all, as discard will occur in these circumstances as well. Note that failure to include the User-to-User data into the ISDN SETUP message (when discard occurs) will result in the service being unavailable for the remainder of the call when UUS1 implicit operation is used.
试图互通过长的UUI数据的互通点将丢弃UUI数据，但继续互通。没有向发送用户发出此类放弃的通知。如果SIP用户知道它正在与ISDN互通，则SIP端点处的UUI应用程序应将其通信限制为128个八位字节加上协议鉴别器的数据包，并知道如果不这样做，将发生丢弃。SIP端点上的UUI应用程序可以完全控制发生的情况。应该注意的是，当早期的ISDN实现只支持32个八位字节，而那些支持128个八位字节时，这正是预期的操作。它还对应于与根本不支持补充业务的ISDN的互通，因为在这些情况下也会发生丢弃。请注意，在使用UUS1隐式操作时，如果未能将用户对用户数据包括在ISDN设置消息中（当发生丢弃时），将导致服务在剩余的调用中不可用。
The User Agent Client (UAC) MUST meet the requirements of [RFC7433] in addition to the requirements defined in this document.
除本文件规定的要求外，用户代理客户端（UAC）还必须满足[RFC7433]的要求。
The UAC MUST only use this UUI mechanism extension package in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog, is precluded. Usage on other methods within the INVITE dialog, and on re-INVITE transactions with the INVITE dialog, is also precluded.
UAC只能将此UUI机制扩展包与初始INVITE方法和与INVITE对话框相关的BYE方法关联使用。禁止在与任何其他类型的对话框关联的事务上使用，或在与对话框不关联的方法上使用。也不允许在INVITE对话框内的其他方法上使用，也不允许在INVITE对话框的重新邀请事务上使用。
If the UAC wishes to use or permit the sending of UUI data at any point in the dialog, the UAC MUST include in the INVITE request for that dialog a User-to-User header field. The UAC SHOULD set the "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package. This initial header field constitutes the implicit request to use the UUI service and is, therefore, included even when there is no data except the protocol discriminator octet to send at that point in time.
如果UAC希望在对话框中的任何位置使用或允许发送UUI数据，则UAC必须在该对话框的INVITE request中包含一个用户对用户标题字段。UAC应将“目的”报头字段参数设置为“isdn uui”。允许不包含“purpose”头字段参数，但这主要是为了允许早期实现支持此包。该初始报头字段构成使用UUI服务的隐式请求，因此，即使在该时间点除了要发送的协议鉴别器八位字节之外没有数据时，也包括该字段。
The UAC MUST NOT include the User-to-User header field with a "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field, either with a "purpose" header field parameter set to "isdn-uui" or with no "purpose" header field parameter included.
如果原始INVITE请求未包括用户到用户标题字段，则UAC不得在INVITE对话框的任何消息中包括“目的”标题字段参数设置为“isdn uui”或没有“目的”标题字段参数的用户到用户标题字段，或者“目的”标题字段参数设置为“isdn uui”或没有包括“目的”标题字段参数。
When sending UUI for the ISDN UUI package, if the "purpose" header field is included, the UAC MUST set the User-to-User "purpose" header field parameter to "isdn-uui". The UAC MUST NOT include more than one User-to-User header field for this package in any SIP request or response.
为ISDN UUI包发送UUI时，如果包含“目的”标头字段，UAC必须将用户对用户“目的”标头字段参数设置为“ISDN UUI”。UAC不得在任何SIP请求或响应中包含此包的多个用户对用户标头字段。
When receiving UUI, when multiple User-to-User header fields are received in the same response with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAC MUST discard all these header fields. There are no mechanisms for determining which ones are the intended UUI data, so all are discarded.
接收UUI时，如果在同一响应中接收到多个用户对用户报头字段，且“目的”报头字段参数设置为“isdn UUI”，或者没有“目的”报头字段参数，或者这些字段的组合，UAC必须丢弃所有这些报头字段。没有确定哪些是预期UUI数据的机制，因此所有这些都将被丢弃。
The application designer will need to take into account the ISDN service restrictions; failure to do so can result in information being discarded at any interworking point with the ISDN. This document makes no further normative requirements based on those constraints because those constraints may vary from one ISDN to another. It is reasonable to expect that a limitation of 128 octets (plus a protocol discriminator) can be imposed by the ISDN; therefore, UUI data longer than this will never reach the destination if such interworking occurs. Note that the 128-octet limit (plus a protocol discriminator) applies before the encoding (or after the decoding) using the "hex" encoding. The "hex" encoding is defined in [RFC7433].
应用程序设计者需要考虑ISDN服务限制；若不这样做，可能会导致在与ISDN的任何互通点丢弃信息。本文件没有基于这些约束提出进一步的规范性要求，因为这些约束可能因ISDN而异。可以合理预期ISDN可以施加128个八位字节（加上协议鉴别器）的限制；因此，如果发生这种互通，超过此长度的UUI数据将永远不会到达目的地。请注意，128八位字节限制（加上协议鉴别器）在使用“十六进制”编码之前（或解码之后）适用。[RFC7433]中定义了“十六进制”编码。
A "uui" option tag for use with the UUI mechanism extension is defined in [RFC7433]. Because the service is UUS1 implicit for the ISDN User-to-User service, the inclusion of the "uui" option tag in a Supported header field conveys no additional information over and above the presence, in the INVITE request, of the User-to-User header field with the "purpose" header field parameter set to "isdn-uui". While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. The presence of the "uui" option tag in the Require header field of an INVITE request will cause the request to fail if it reaches a UAS or ISDN interworking gateway that does not support this extension; such usage is allowed but will produce results that are inconsistent with the mechanisms defined in the ISDN UUS supplementary service.
[RFC7433]中定义了用于uui机制扩展的“uui”选项标记。由于该服务对于ISDN用户对用户服务是UUS1隐式的，因此在受支持的报头字段中包含“uui”选项标记不会在INVITE请求中用户对用户报头字段的存在（其“目的”报头字段参数设置为“ISDN uui”）之外传递任何附加信息。虽然包含“uui”选项标记没有害处，而且严格来说，如果支持扩展，则应该包含它，但它不执行任何功能。如果INVITE请求的Require header字段中存在“uui”选项标记，则当请求到达不支持此扩展的UAS或ISDN互通网关时，将导致请求失败；这种使用是允许的，但会产生与ISDN UUS补充业务中定义的机制不一致的结果。
The UAS MUST meet the requirements of [RFC7433] in addition to the requirements defined in this document.
除本文件规定的要求外，UAS还必须满足[RFC7433]的要求。
The UAS MUST only use this UUI mechanism extension package in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog, is precluded. Usage on other methods within the INVITE dialog, and on re-INVITE transactions with the INVITE dialog, is also precluded.
UAS只能将此UUI机制扩展包与初始INVITE方法和与INVITE对话框相关的BYE方法结合使用。禁止在与任何其他类型的对话框关联的事务上使用，或在与对话框不关联的方法上使用。也不允许在INVITE对话框内的其他方法上使用，也不允许在INVITE对话框的重新邀请事务上使用。
The UAS MUST NOT include the User-to-User header field with a "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field, either with a "purpose" header field parameter set to "isdn-uui" or with no "purpose" header field parameter included.
如果原始INVITE请求未包括用户到用户标题字段，则UAS不得在INVITE对话框的任何消息中包括“目的”标题字段参数设置为“isdn uui”或没有“目的”标题字段参数的用户到用户标题字段，或者“目的”标题字段参数设置为“isdn uui”或没有包括“目的”标题字段参数。
The UAS MAY include the User-to-User header field in responses to the initial INVITE request, or the BYE requests or responses for the dialog, only where the original INVITE request included a User-to-User header field with the "purpose" header field parameter set to "isdn-uui" or where no "purpose" header field parameter was included. When sending UUI for the ISDN UUI package, the UAS SHOULD set the User-to-User "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package.
UAS可在响应初始INVITE请求时包括用户对用户报头字段，或在原始INVITE请求包括用户对用户报头字段且“目的”报头字段参数设置为“isdn uui”或未包括“目的”报头字段参数的情况下，包括对话的BYE请求或响应。当发送ISDN UUI包的UUI时，UAS应将用户对用户“目的”标题字段参数设置为“ISDN UUI”。允许不包含“purpose”头字段参数，但这主要是为了允许早期实现支持此包。
When sending UUI for the ISDN UUI package, if the "purpose" header field is included, the UAS MUST set the User-to-User "purpose" header field parameter to "isdn-uui". The UAS MUST NOT include more than one User-to-User header field for this package in any SIP request or response.
为ISDN UUI包发送UUI时，如果包含“目的”报头字段，UAS必须将用户对用户“目的”报头字段参数设置为“ISDN UUI”。UAS不得在任何SIP请求或响应中包含此包的多个用户对用户标头字段。
The "isdn-interwork" value for the "purpose" header field parameter was used in documents that led to the publication of the present document. Although these documents had no other status than "Work in Progress", this value is implemented by some vendors. While not defined by this document, implementations could find it useful for interoperability purposes to support parsing and interpreting "isdn-interwork" the same way as "isdn-uui" when receiving messages.
在导致本文件出版的文件中，使用了“目的”标题字段参数的“isdn互通”值。尽管这些文件除了“正在工作”之外没有其他状态，但该值由一些供应商实现。虽然本文档没有定义，但实现可能会发现，为了互操作性目的，支持在接收消息时以与“isdn uui”相同的方式解析和解释“isdn互通”非常有用。
Where the UAS is acting as a redirect server, the UAS MUST NOT include the User-to-User header field in the header URI parameter in a 3xx response to an incoming request.
当UAS充当重定向服务器时，UAS不得在对传入请求的3xx响应中的header URI参数中包含用户到用户的header字段。
When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, the UAS MUST discard this header field.
当接收UUI时，当在非来自发起用户的请求中接收到用户对用户报头字段，且“目的”报头字段参数设置为“isdn UUI”，或没有“目的”报头字段参数时，UAS必须丢弃该报头字段。
When receiving UUI, when multiple User-to-User header fields are received from the originating user in the same request with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAS MUST discard all these header fields. There are no mechanisms for determining which ones are the intended UUI data, so all are discarded.
当接收UUI时，当在同一请求中从发起用户接收到多个用户对用户报头字段，且“目的”报头字段参数设置为“isdn UUI”，或没有“目的”报头字段参数，或具有这些参数的某些组合时，UAS必须丢弃所有这些报头字段。没有确定哪些是预期UUI数据的机制，因此所有这些都将被丢弃。
These requirements apply when the "purpose" header field parameter is set to "isdn-uui" or when there is no "purpose" header field parameter.
当“目的”报头字段参数设置为“isdn uui”或没有“目的”报头字段参数时，这些要求适用。
Processing for User-to-User header fields sent or received with values other than this value are outside the scope of this document, and the appropriate package document for that value applies.
使用此值以外的值发送或接收的用户对用户标题字段的处理超出了本文档的范围，适用于该值的相应程序包文档。
The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value than "isdn-uui".
为这个包定义的默认和唯一内容是“isdn uui”。当发送UUI时，发送SIP实体可以但不需要包括一个值设置为“isdn UUI”的“content”报头字段。如果“内容”报头字段参数存在且值不是“isdn uui”，则接收SIP实体必须忽略接收到的用户对用户报头字段。
The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value than "hex".
为这个包定义的默认和唯一编码是“十六进制”。当发送UUI时，发送SIP实体可以但不需要包括一个值设置为“hex”的“encoding”头字段。如果存在“encoding”标头字段参数，并且该值不是“hex”，则接收SIP实体必须忽略接收到的用户对用户标头字段。
When sending UUI, the sending application MUST include a protocol discriminator octet, conforming to Table 4-26 of ITU-T Recommendation Q.931 [Q931], as the first octet of the UUI data. It is up to the receiving application what it does with this value. This document places no other normative requirement on the use of the protocol discriminator; it is required at interworking gateways to allow mapping into the appropriate fields in the ISDN protocols; otherwise, the usage is entirely up to the application and is outside the scope of this document. Valid values are identified and documented by ITU-T, and there is no IANA registry for these values.
发送UUI时，发送应用程序必须包括符合ITU-T建议Q.931[Q931]表4-26的协议鉴别器八位组，作为UUI数据的第一个八位组。这取决于接收应用程序如何处理该值。本文件未对协议鉴别器的使用提出其他规范性要求；互通网关需要允许映射到ISDN协议中的适当字段；否则，用法完全取决于应用程序，不在本文档的范围内。有效值由ITU-T识别和记录，这些值没有IANA注册中心。
ISDN interworking gateways MUST support the requirements defined for UAS and UAC operation.
ISDN互通网关必须支持为UAS和UAC操作定义的要求。
ISDN interworking gateways MUST support only the "isdn-uui" package on dialogs that are interworked.
ISDN互通网关必须仅支持互通对话框上的“ISDN uui”包。
ISDN interworking gateways will take octet-structured data from the ISDN side and encode it using the "hex" encoding scheme defined in [RFC7433] for inclusion as the UUI data in the User-to-User header field. In the reverse direction, it will take valid UUI data according to the "hex" encoding scheme and decode it to octet-structured data to send to the ISDN side.
ISDN互通网关将从ISDN端获取八进制结构化数据，并使用[RFC7433]中定义的“十六进制”编码方案对其进行编码，以将其作为UUI数据包含在用户对用户报头字段中。在相反的方向上，它将根据“十六进制”编码方案获取有效的UUI数据，并将其解码为八位字节结构数据发送到ISDN侧。
When mapping data content from the ISDN to SIP signalling, or from SIP signalling to the ISDN, the gateway needs to assume that all content is octet-structured binary, irrespective of the value of the received protocol discriminator. There are no requirements in the ISDN to ensure that the content matches the value of the protocol discriminator; the application usage sorts out any discrepancy. The same applies to the ISDN protocol discriminator as the first octet of the UUI data, as defined in Table 4-26 of ITU-T Recommendation Q.931 [Q931]; the interworking gateway will not perform any additional checking of this value.
当将数据内容从ISDN映射到SIP信令，或从SIP信令映射到ISDN时，网关需要假定所有内容都是八位字节结构的二进制，而不管接收到的协议鉴别器的值如何。ISDN中没有要求确保内容与协议鉴别器的值匹配；应用程序的使用可以解决任何差异。如ITU-T建议Q.931[Q931]表4-26中所定义，这同样适用于作为UUI数据第一个八位组的ISDN协议鉴别器；互通网关不会对此值执行任何附加检查。
A "uui" option tag for use with the UUI mechanism extension is defined in [RFC7433]. The option tag is not interworked at an ISDN interworking gateway. The ISDN interworking gateways MUST NOT take the omission of the "uui" option tag in a received INVITE request to indicate that interworking of a received header field is not to be performed.
[RFC7433]中定义了用于uui机制扩展的“uui”选项标记。选项标签未在ISDN互通网关上互通。ISDN互通网关不得在接收到的INVITE请求中省略“uui”选项标记，以指示不执行接收到的报头字段的互通。
This document defines "isdn-uui" as a new value of the User-to-User "purpose" header field parameter. The following ABNF adds to the production in [RFC7433]:
本文档将“isdn uui”定义为用户对用户“目的”标头字段参数的新值。[RFC7433]中的生产增加了以下ABNF：
pkg-param-value =/ "isdn-uui"
pkg参数值=/“isdn uui”
This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. A content value of "isdn-uui" indicates that the contents have a first octet that is a protocol discriminator (see Table 4-26 of ITU-T Recommendation Q.931 [Q931]) followed by UUI data that can be subject to a length limitation (before encoding or after decoding) that is generally 128 octets.
本文档将“isdn uui”定义为用户对用户“内容”标题字段参数的新值。“isdn uui”的内容值表示内容具有作为协议鉴别器的第一个八位字节（参见ITU-T建议Q.931[Q931]的表4-26），然后是可受长度限制（编码前或解码后）的uui数据，该长度限制通常为128个八位字节。
The following ABNF adds to the production in [RFC7433].
[RFC7433]中的生产增加了以下ABNF。
cont-param-value =/ "isdn-uui"
控制参数值=/“isdn uui”
This document defines the new media feature tag "sip.uui-isdn". This feature tag indicates that this ISDN UUI package is supported by the sender, and its usage is entirely in accordance with [RFC3840]. This document makes no additional provisions for the use of this feature tag.
本文档定义了新的媒体功能标签“sip.uui isdn”。此功能标签表示发送方支持此ISDN UUI包，其使用完全符合[RFC3840]。本文件对该功能标签的使用没有其他规定。
Per this document, the following row has been added to the "UUI Packages" subregistry of the SIP parameter registry:
根据本文件，以下行已添加到SIP参数注册表的“UUI包”子区：
Value: isdn-uui
值：isdn uui
Description: The associated application is being used with constraints suitable for interworking with the ISDN User-to-User service, and therefore can be interworked at ISDN gateways.
描述：相关应用程序正与适合与ISDN用户对用户服务互通的约束一起使用，因此可以在ISDN网关上互通。
Reference: RFC 7434
参考：RFC 7434
Per this document, the following row has been added to the "UUI Content" subregistry of the SIP parameter registry:
根据本文件，以下行已添加到SIP参数注册表的“UUI内容”子区：
Value: isdn-uui
值：isdn uui
Description: The associated contents conform to the content associated with the ISDN User-to-User service. In the presence of the "purpose" header field parameter set to "isdn-uui" (or the absence of any "purpose" header field parameter), this is the default meaning and therefore need not be included in this case.
说明：相关内容符合与ISDN用户对用户服务相关的内容。如果存在设置为“isdn uui”的“目的”报头字段参数（或不存在任何“目的”报头字段参数），则这是默认含义，因此不需要包括在本例中。
Reference: RFC 7434
参考：RFC 7434
This document defines the following media feature tag, which has been added to the features.sip-tree of the Media feature tags registry:
本文档定义了以下媒体功能标签，该标签已添加到媒体功能标签注册表的features.sip-tree中：
Media feature tag name: sip.uui-isdn
媒体功能标签名称：sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x
ASN.1标识符：1.3.6.1.8.4.x
Summary of the media feature indicated by this tag: This media feature tag when used in a Contact header field of a SIP request or a SIP response indicates that the entity sending the SIP message supports the package "uui-isdn".
此标记指示的媒体功能摘要：当在SIP请求或SIP响应的联系人标头字段中使用此媒体功能标记时，表示发送SIP消息的实体支持包“uui isdn”。
Values appropriate for use with this feature tag: none
适用于此功能标记的值：无
Examples of typical use: Indicating that a mobile phone supports Single Radio Voice call Continuity (SRVCC) for calls in the alerting phase.
典型用途示例：表示移动电话在报警阶段支持呼叫的单无线电语音呼叫连续性（SRVCC）。
Related standards or documents: RFC 7434
相关标准或文件：RFC 7434
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of [RFC3840]
安全注意事项：[RFC3840]第11.1节讨论了此媒体功能标签的安全注意事项
This document contains no specific requirements in regard to security over and above those specified in [RFC7433]. However, since this capability is designed to interwork with the ISDN, the general security considerations of SIP to ISDN User Part (ISUP) interworking defined in [RFC3398] apply. Any SIP/PSTN gateway implementing the ISDN User-to-User service should not blindly trust ISUP from the PSTN. In general, the overlying use case will define the security measures required. The underlying User-to-User header field extension provides a number of tools that can meet certain security requirements.
除[RFC7433]中规定的要求外，本文件不包含关于安全性的具体要求。但是，由于该功能旨在与ISDN互通，因此[RFC3398]中定义的SIP到ISDN用户部分（ISUP）互通的一般安全考虑因素适用。任何实现ISDN用户对用户服务的SIP/PSTN网关都不应盲目信任来自PSTN的ISUP。通常，上面的用例将定义所需的安全措施。底层的用户对用户标题字段扩展提供了许多可以满足某些安全要求的工具。
Information that might otherwise reveal private information about an individual, or where a level of authenticity needs to be guaranteed, may need a higher level of protection and may indeed not be suitable for this package, particularly taking into account the statement in the following paragraph.
可能以其他方式泄露个人隐私信息的信息，或者需要保证一定程度的真实性的信息，可能需要更高级别的保护，并且可能确实不适合此包，特别是考虑到以下段落中的声明。
As this capability is defined to interwork with the ISDN, if the ISDN forms part of the route, any usage needs to be aware that the security level of the ISDN service may be lower than the security of the SIP service. The ISDN security is itself not definable on an end-to-end basis and exists on a hop-by-hop basis. This can be high in some places (e.g., it can require physical access to a secure building) and in other places it can be low (e.g., the point where an ISDN access enters a building). If this level of security is not sufficient, then either a different package or indeed a different method of data transfer needs to be selected by the application user.
由于此功能定义为与ISDN互通，如果ISDN构成路由的一部分，则任何使用都需要注意ISDN服务的安全级别可能低于SIP服务的安全级别。ISDN安全性本身不能在端到端的基础上定义，而是在逐跳的基础上存在。这在某些地方可能很高（例如，需要物理访问安全建筑），而在其他地方可能很低（例如，ISDN访问进入建筑的点）。如果此安全级别不够，则应用程序用户需要选择不同的包或不同的数据传输方法。
[Q931] ITU-T, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, <http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.
[Q931]ITU-T，“基本呼叫控制的ISDN用户网络接口第3层规范”，ITU-T建议Q.931<http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 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，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002, <http://www.rfc-editor.org/info/rfc3372>.
[RFC3372]Vemuri，A.和J.Peterson，“电话会话启动协议（SIP-T）：上下文和体系结构”，BCP 63，RFC 3372，2002年9月<http://www.rfc-editor.org/info/rfc3372>.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002, <http://www.rfc-editor.org/info/rfc3398>.
[RFC3398]Camarillo，G.，Roach，A.，Peterson，J.，和L.Ong，“综合业务数字网（ISDN）用户部分（ISUP）到会话发起协议（SIP）的映射”，RFC 33982002年12月<http://www.rfc-editor.org/info/rfc3398>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 38402004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC7433] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User-to-User Call Control Information in SIP", RFC 7433, December 2014, <http://www.rfc-editor.org/info/rfc7433>.
[RFC7433]Johnston，A.和J.Rafferty，“SIP中传输用户对用户呼叫控制信息的机制”，RFC 7433，2014年12月<http://www.rfc-editor.org/info/rfc7433>.
[ANSII] ANSI, "Integrated Services Digital Network (ISDN) - Explicit Call Transfer Supplementary Service", ANSI-T1.643A - SUP A, December 1996.
[ANSII]ANSI，“综合业务数字网（ISDN）-显式呼叫转移补充业务”，ANSI-T1.643A-附录A，1996年12月。
[ETSI] ETSI, "Integrated Services Digital Network (ISDN); Diversion supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification", ETSI ETS 300 207-1, Ed. 1, December 1994.
[ETSI]ETSI，“综合业务数字网（ISDN）；转移补充业务；数字用户信令系统第1号（DSS1）协议；第1部分：协议规范”，ETSI ETS 300 207-1，第1版，1994年12月。
[Q763] ITU-T, "Signalling System No. 7 - ISDN User Part formats and codes", ITU-T Recommendation Q.763, <http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.
[Q763]ITU-T，“第7号信令系统——ISDN用户部分格式和代码”，ITU-T建议Q.763<http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.
[Q957.1] ITU-T, "Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)", ITU-T Recommendation Q.957.1, <http://www.itu.int/rec/T-REC-Q.957.1-199607-I>.
[Q957.1]ITU-T，“第1号数字用户信令系统-使用DSS 1的补充业务的第3阶段说明；使用DSS 1的附加信息传输补充业务的第3阶段说明：用户对用户信令（UUS）”，ITU-T建议Q.957.1<http://www.itu.int/rec/T-REC-Q.957.1-199607-I>.
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP", RFC 6567, April 2012, <http://www.rfc-editor.org/info/rfc6567>.
[RFC6567]Johnston，A.和L.Liess，“SIP中传输用户对用户呼叫控制信息的问题陈述和要求”，RFC 6567，2012年4月<http://www.rfc-editor.org/info/rfc6567>.
Acknowledgments
致谢
Joanne McMillen was a major contributor and coauthor of earlier versions of this document.
Joanne McMillen是本文档早期版本的主要贡献者和合著者。
Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland Jesske for their reviews of this document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, Mahalingam Mani, and Celine Serrut-Valette for their comments.
感谢Spencer Dawkins、Vijay Gurbani、Laura Liess和Roland Jeske对本文档的审阅。作者希望感谢弗朗索瓦·奥德特、丹尼斯·阿列克谢采夫、保罗·基齐瓦特、卡伦·詹宁斯、马哈林根·马尼和塞琳·塞鲁特·瓦莱特的评论。
The death of Francois Audet occurred before this document was finalized, and the authors would like to identify the significant contribution of Francois to this and a number of important RFCs and to express their condolences to his family. It was always a pleasure to work with Francois.
弗朗索瓦·奥德特的死亡发生在本文件定稿之前，作者希望确定弗朗索瓦对本文件和一些重要的区域渔业委员会的重大贡献，并向他的家人表示哀悼。与弗朗索瓦共事总是一件愉快的事。
Authors' Addresses
作者地址
Keith Drage (editor) Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon United Kingdom
基思·德拉奇（编辑）阿尔卡特-朗讯象限，斯通希尔格林，威斯特利亚斯温顿英国
EMail: keith.drage@alcatel-lucent.com
EMail: keith.drage@alcatel-lucent.com
Alan Johnston Avaya St. Louis, MO United States
美国密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com