Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 7433 Avaya
Category: Standards Track J. Rafferty
ISSN: 2070-1721 Human Communications
January 2015
Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 7433 Avaya
Category: Standards Track J. Rafferty
ISSN: 2070-1721 Human Communications
January 2015
A Mechanism for Transporting User-to-User Call Control Information in SIP
SIP中用户对用户呼叫控制信息的传输机制
Abstract
摘要
There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.
有一类应用程序受益于在会话建立期间使用SIP交换用户对用户信息（UUI）数据。此信息称为呼叫控制UUI数据，是由启动会话的应用程序插入并由接受会话的应用程序使用的一小段数据。特定应用程序使用的UUI数据的语法和语义由UUI包定义。此UUI数据对SIP是不透明的，其功能与任何基本SIP功能无关。本文档定义了一个新的SIP头字段“用户到用户”，用于传输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/rfc7433.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7433.
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. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4
4. Normative Definition . . . . . . . . . . . . . . . . . . . . 5
4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6
4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
4.3. Source Identity of UUI Data . . . . . . . . . . . . . . . 7
5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of User-to-User Header Field . . . . . . . . 11
6.2. Registration of User-to-User Header Field Parameters . . 11
6.3. Registration of UUI Packages . . . . . . . . . . . . . . 11
6.4. Registration of UUI Content Parameters . . . . . . . . . 12
6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
6.6. Registration of SIP Option Tag . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Other Possible Mechanisms . . . . . . . . . . . . . 17
A.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . 17
A.2. Why Other Protocol Encapsulation UUI Mechanisms Are Not
Used . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. MIME Body Approach . . . . . . . . . . . . . . . . . . . 17
A.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4
4. Normative Definition . . . . . . . . . . . . . . . . . . . . 5
4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6
4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
4.3. Source Identity of UUI Data . . . . . . . . . . . . . . . 7
5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of User-to-User Header Field . . . . . . . . 11
6.2. Registration of User-to-User Header Field Parameters . . 11
6.3. Registration of UUI Packages . . . . . . . . . . . . . . 11
6.4. Registration of UUI Content Parameters . . . . . . . . . 12
6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
6.6. Registration of SIP Option Tag . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Other Possible Mechanisms . . . . . . . . . . . . . 17
A.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . 17
A.2. Why Other Protocol Encapsulation UUI Mechanisms Are Not
Used . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. MIME Body Approach . . . . . . . . . . . . . . . . . . . 17
A.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document describes the transport of UUI data using SIP [RFC3261]. It defines a mechanism for the transport of general application UUI data and for the transport of the call control related ITU-T Recommendation Q.931 User-user information element [Q931] and ITU-T Recommendation Q.763 User-to-User information parameter [Q763] data in SIP. UUI data is widely used in the Public Switched Telephone Network (PSTN) today for contact centers and call centers. There is also a trend for the related applications to transition from ISDN to SIP. The UUI extension for SIP may also be used for native SIP User Agents (UAs) implementing similar services and to interwork with ISDN services. Note that in most cases, there is an a priori understanding between the UAs in regard to what to do with received UUI data. This document enables the definition of packages and related attributes that can make such understandings more explicit.
本文档描述了使用SIP[RFC3261]传输UUI数据。它定义了一种机制，用于传输一般应用UUI数据，以及传输SIP中与呼叫控制相关的ITU-T建议Q.931用户信息元素[Q931]和ITU-T建议Q.763用户对用户信息参数[Q763]数据。UUI数据目前广泛应用于公共交换电话网（PSTN）的联络中心和呼叫中心。相关应用也有从ISDN向SIP过渡的趋势。SIP的UUI扩展还可用于实现类似服务的本机SIP用户代理（UAs）以及与ISDN服务的互通。请注意，在大多数情况下，UAs之间对如何处理接收到的UUI数据有着先验的理解。本文档支持对包和相关属性的定义，从而使此类理解更加明确。
The UUI mechanism is designed to meet the use cases, requirements, and call flows for SIP call control UUI detailed in [RFC6567]. All references to requirement numbers (REQ-N) and figure numbers refer to [RFC6567].
UUI机制旨在满足[RFC6567]中详述的SIP呼叫控制UUI的用例、需求和呼叫流。所有对需求编号（REQ-N）和图号的引用均参考[RFC6567]。
The mechanism is a new SIP header field, along with a new SIP option tag. The header field carries the UUI data, along with parameters indicating the encoding of the UUI data, the UUI package, and optionally the content of the UUI data. The package definition contains details about how a particular application can utilize the UUI mechanism. The header field can be included (sometimes called "escaped") into URIs supporting referral and redirection scenarios. In these scenarios, the History-Info header field is used to indicate the inserter of the UUI data. The SIP option tag can be used to indicate support for the header field. Support for the UUI header field indicates that a UA is able to extract the information in the UUI data and pass it up the protocol stack. Individual packages using the UUI mechanism can utilize SIP media feature tags to indicate that a UA supports a particular UUI package. Guidelines for defining UUI packages are provided.
该机制是一个新的SIP头字段，以及一个新的SIP选项标记。报头字段携带UUI数据，以及指示UUI数据编码、UUI包和可选的UUI数据内容的参数。包定义包含有关特定应用程序如何利用UUI机制的详细信息。标头字段可以包含（有时称为“转义”）到支持引用和重定向场景的URI中。在这些场景中，历史信息头字段用于指示UUI数据的插入器。SIP选项标记可用于指示对标头字段的支持。对UUI头字段的支持表明UA能够提取UUI数据中的信息并将其向上传递到协议栈。使用UUI机制的各个包可以利用SIP媒体功能标签来指示UA支持特定的UUI包。提供了定义UUI包的指南。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Note that the <allOneLine> tag convention from SIP Torture Test Messages [RFC4475] is used to show that there are no line breaks in the actual message syntax.
请注意，SIP测试消息[RFC4475]中的<allOneLine>标记约定用于显示实际消息语法中没有换行符。
This section describes how the User-to-User header field meets the requirements in [RFC6567]. The header field can be included in INVITE requests and responses and BYE requests and responses, meeting REQ-1 and REQ-2.
本节介绍用户对用户标题字段如何满足[RFC6567]中的要求。标题字段可以包含在INVITE请求和响应以及BYE请求和响应中，满足REQ-1和REQ-2。
For redirection and referral use cases and REQ-3, the header field is included (escaped) within the Contact or Refer-To URI. The details of this mechanism as it applies for redirection and referral use cases are covered in Section 4.1.
对于重定向和转介用例以及REQ-3，在Contact或Refer-To URI中包含（转义）头字段。第4.1节介绍了适用于重定向和引用用例的该机制的详细信息。
Since SIP proxy forwarding and retargeting does not affect header fields, the header field meets REQ-4.
由于SIP代理转发和重定目标不影响报头字段，因此报头字段符合REQ-4。
The UUI header field will carry the UUI data and not a pointer to the data, so REQ-5 is met.
UUI头字段将携带UUI数据，而不是指向数据的指针，因此满足REQ-5。
Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols is straightforward and is documented in a separate specification [RFC7434], meeting REQ-6.
由于UUI报头字段的基本设计类似于ISDN UUI服务，因此与PSTN协议的互通非常简单，并记录在单独的规范[RFC7434]中，满足REQ-6的要求。
Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the mechanism and supported packages, and hence applications. REQ-7 relates to support of the UUI header field, while REQ-8 relates to routing based on support of the UUI header field. REQ-7 is met by defining a new SIP option tag "uui". The use of a Require:uui in a request or Supported:uui in an OPTIONS response could be used to require or discover support of the mechanism. The presence of a Supported:uui or Require:uui header field can be used by proxies to route to an appropriate UA, meeting REQ-8. However, note that only UAs are expected to understand the UUI data -- proxies and other intermediaries do not. REQ-10 is met by utilizing SIP feature tags [RFC3840]. For example, the feature tag "sip.uui-isdn" could be used to indicate support of the ISDN UUI package, or "sip.uui-pk1" could be used to indicate support for a particular package, pk1.
需求REQ-7、REQ-8和REQ-10与发现机制和支持的包以及应用程序有关。REQ-7涉及对UUI头字段的支持，而REQ-8涉及基于对UUI头字段的支持的路由。通过定义一个新的SIP选项标签“uui”来满足REQ-7。在请求中使用Require:uui或在选项响应中使用Supported:uui可用于请求或发现对该机制的支持。代理可以使用支持的：uui或Require:uui报头字段来路由到适当的UA，以满足REQ-8的要求。但是，请注意，只有UAs才能理解UUI数据——代理和其他中介机构不能理解。通过利用SIP功能标签[RFC3840]满足REQ-10的要求。例如，功能标签“sip.uui-isdn”可用于指示对isdn uui包的支持，或“sip.uui-pk1”可用于指示对特定包pk1的支持。
Proxies commonly apply policy to the presence of certain SIP header fields in requests by either passing them or removing them from requests. REQ-9 is met by allowing proxies and other intermediaries to remove UUI header fields in a request or response based on policy.
代理通常通过传递或从请求中删除某些SIP头字段，将策略应用于请求中存在的某些SIP头字段。通过允许代理和其他中介基于策略删除请求或响应中的UUI头字段来满足REQ-9。
Carrying UUI data elements of at least 129 octets is trivial in the UUI header field, meeting REQ-11. Note that avoiding having very large UUI data elements is a good idea, as SIP header fields have traditionally not been large.
在UUI报头字段中，携带至少129个八位字节的UUI数据元素是微不足道的，符合REQ-11。请注意，避免使用非常大的UUI数据元素是一个好主意，因为SIP头字段传统上并不很大。
To meet REQ-12 for the redirection and referral use cases, the History-Info header field [RFC7044] can be used. In these retargeting cases, the changed Request-URI will be recorded in the History-Info header field along with the identity of the element that performed the retargeting.
为了满足重定向和引用用例的REQ-12，可以使用历史信息头字段[RFC7044]。在这些重定目标情况下，更改的请求URI将与执行重定目标的元素的标识一起记录在历史信息头字段中。
The requirement for integrity protection in REQ-13 could be met by the use of an S/MIME signature over a subset of header fields, as defined in "SIP Header Privacy and Integrity using S/MIME: Tunneling SIP", Section 23.4 of RFC 3261. Note that the lack of deployment of S/MIME with SIP means that, in general, REQ-13 is not met. The requirement of REQ-14 for end-to-end privacy could be met using S/MIME or using encryption at the application layer. Note that the use of S/MIME to secure the UUI data will result in an additional body being added to the request. Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header field to meet REQ-15 for hop-by-hop security.
如RFC 3261第23.4节“使用S/MIME的SIP报头隐私和完整性：隧道SIP”中所定义，可通过在报头字段子集上使用S/MIME签名来满足REQ-13中的完整性保护要求。请注意，没有使用SIP部署S/MIME意味着通常不满足REQ-13。使用S/MIME或在应用层使用加密，可以满足REQ-14对端到端隐私的要求。请注意，使用S/MIME保护UUI数据将导致向请求中添加额外的主体。逐跳传输层安全性（TLS）[RFC5246]允许报头字段满足逐跳安全性的REQ-15。
This document defines a new SIP header field "User-to-User" to transport call control UUI data to meet the requirements in [RFC6567].
本文档定义了一个新的SIP头字段“用户对用户”，用于传输呼叫控制UUI数据，以满足[RFC6567]中的要求。
To help tag and identify the UUI data used with this header field, "purpose", "content", and "encoding" header field parameters are defined. The "purpose" header field parameter identifies the package that defines the generation and usage of the UUI data for a particular application. The value of the "purpose" parameter is the package name, as registered in the "UUI Packages" subregistry defined in Section 6.3. For the case of interworking with the ISDN UUI service, the ISDN UUI service interworking package is used. The default value for the "purpose" header field is "isdn-uui" as defined in [RFC7434]. If the "purpose" header field parameter is not present, the ISDN UUI MUST be used. The "content" header field parameter identifies the actual content of the UUI data. If not present, the default content defined for the package MUST be used. Newly defined UUI packages MUST define or reference at least a default "content" value. The "encoding" header field parameter indicates the method of encoding the information in the UUI data associated with a particular "content" value. This specification
为了帮助标记和识别与此标题字段一起使用的UUI数据，定义了“目的”、“内容”和“编码”标题字段参数。“目的”标头字段参数标识用于定义特定应用程序UUI数据的生成和使用的包。“purpose”参数的值是在第6.3节定义的“UUI软件包”子区域中注册的软件包名称。对于与ISDN UUI服务互通的情况，使用ISDN UUI服务互通包。“目的”报头字段的默认值为[RFC7434]中定义的“isdn uui”。如果“目的”报头字段参数不存在，则必须使用ISDN UUI。“内容”标题字段参数标识UUI数据的实际内容。如果不存在，则必须使用为包定义的默认内容。新定义的UUI包必须定义或引用至少一个默认的“内容”值。“encoding”头字段参数指示对UUI数据中与特定“content”值相关联的信息进行编码的方法。本规范
only defines "encoding=hex". If the "encoding" header field parameter is not present, the default encoding defined for the package MUST be used.
仅定义“编码=十六进制”。如果“encoding”标头字段参数不存在，则必须使用为包定义的默认编码。
UUI data is considered an opaque series of octets. This mechanism MUST NOT be used to convey a URL or URI, since the Call-Info header field in [RFC3261] already supports this use case.
UUI数据被认为是一个不透明的八位元序列。此机制不得用于传递URL或URI，因为[RFC3261]中的Call Info header字段已经支持此用例。
The UUI header field can be present in INVITE requests and responses and in BYE requests and responses. Note that when the UUI header is used in responses, it can only be utilized in end-to-end responses, e.g., 1xx (excluding 100), 2xx, and 3xx responses.
UUI头字段可以出现在INVITE请求和响应以及BYE请求和响应中。请注意，当UUI头用于响应时，它只能用于端到端响应，例如1xx（不包括100）、2xx和3xx响应。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 5234 and extends RFC 3261 (where token, quoted-string, and generic-param are defined).
以下语法规范使用RFC 5234中所述的增广Backus-Naur格式（ABNF），并扩展RFC 3261（其中定义了标记、带引号的字符串和泛型参数）。
UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
uui-value = uui-data *(SEMI uui-param)
uui-data = token / quoted-string
uui-param = pkg-param / cont-param / enc-param / generic-param
pkg-param = "purpose" EQUAL pkg-param-value
pkg-param-value = token
cont-param = "content" EQUAL cont-param-value
cont-param-value = token
enc-param = "encoding" EQUAL enc-param-value
enc-param-value = token / "hex"
UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
uui-value = uui-data *(SEMI uui-param)
uui-data = token / quoted-string
uui-param = pkg-param / cont-param / enc-param / generic-param
pkg-param = "purpose" EQUAL pkg-param-value
pkg-param-value = token
cont-param = "content" EQUAL cont-param-value
cont-param-value = token
enc-param = "encoding" EQUAL enc-param-value
enc-param-value = token / "hex"
Each package defines how many User-to-User header fields of each package may be present in a request or a response. A sender MAY include multiple User-to-User header fields, and a receiver MUST be prepared to receive multiple User-to-User header fields. Consistent with the rules of SIP syntax, the syntax defined in this document allows any combination of individual User-to-User header fields or User-to-User header fields with multiple comma separated UUI data elements. Any size limitations on the UUI data for a particular purpose are to be defined by the related UUI package.
每个包定义每个包在请求或响应中可能存在的用户对用户头字段的数量。发送方可以包括多个用户到用户的报头字段，接收方必须准备好接收多个用户到用户的报头字段。与SIP语法规则一致，本文档中定义的语法允许单个用户到用户标题字段或用户到用户标题字段与多个逗号分隔的UUI数据元素的任意组合。特定用途的UUI数据的任何大小限制都将由相关UUI包定义。
UAs SHALL ignore UUI data from packages or encoding that they do not understand.
UAs应忽略来自其不理解的包或编码的UUI数据。
For redirection use cases, the header field is included (escaped) within the Contact URI. For referral use cases, the header field is included (escaped) within the Refer-To URI. For example, if a UA supports this specification, it SHOULD include any UUI data included in a redirection URI (if the UUI data and encoding is understood).
对于重定向用例，头字段包含（转义）在联系人URI中。对于引用用例，头字段包含（转义）在引用URI中。例如，如果UA支持此规范，它应该包括重定向URI中包含的任何UUI数据（如果理解UUI数据和编码）。
Note that redirection can occur multiple times to a request. Currently, UAs that support attended transfer support the ability to include a Replaces header field [RFC3891] into a Refer-To URI, and when acting upon this URI, UAs add the Replaces header field to the triggered INVITE. This sort of logic and behavior is utilized for the UUI header field (that is, the UUI header field is included in the triggered INVITE). The UA processing the REFER [RFC3515] or the 3xx response to the INVITE SHOULD support the UUI mechanism. If the REFER or redirect target does not support UUI, the UUI header will be discarded as per [RFC3261]. However, this may limit the utility of use cases that depend upon the UUI being supported by all elements.
请注意，对请求的重定向可能会发生多次。目前，支持有人值守传输的UAs支持将Replaces header字段[RFC3891]包含到Refer-Refer URI中，并且在处理此URI时，UAs将Replaces header字段添加到触发的INVITE中。这种逻辑和行为用于UUI头字段（即，UUI头字段包含在触发的INVITE中）。处理REFER[RFC3515]或INVITE的3xx响应的UA应支持UUI机制。如果引用或重定向目标不支持UUI，将根据[RFC3261]丢弃UUI头。然而，这可能会限制依赖于所有元素支持的UUI的用例的实用性。
Here is an example of an included User-to-User header field from the redirection response F2 of Figure 2 in [RFC6567]:
以下是[RFC6567]中图2的重定向响应F2中包含的用户到用户标题字段的示例：
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar>
</allOneLine>
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar>
</allOneLine>
The resulting INVITE F4 would contain:
结果INVITE F4将包含：
User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar
User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar
This specification defines hex encoding of UUI data. When the value of "hex" is used in the "encoding" parameter of a header field, the data is encoded using base16 encoding according to Section 8 of [RFC4648]. The hex-encoded value is normally represented using the "token" construction from RFC 3261, although the "quoted-string" construction is permitted, in which case the quotes MUST be ignored.
本规范定义了UUI数据的十六进制编码。当在报头字段的“encoding”参数中使用“hex”值时，根据[RFC4648]第8节，使用base16编码对数据进行编码。十六进制编码的值通常使用RFC 3261中的“标记”结构表示，但允许使用“带引号的字符串”结构，在这种情况下，必须忽略引号。
If a canonicalized version of a normally case-insensitive hex encoded UUI data object is needed for a digital signature or integrity checking, then the base16 encoding with all upper case MUST be used.
如果数字签名或完整性检查需要标准化版本的通常不区分大小写的十六进制编码UUI数据对象，则必须使用带所有大写字母的base16编码。
It is important for the recipient of UUI data to know the identity of the UA that inserted the UUI data. In a request without a History-Info header field, the identity of the entity that inserted the UUI data will be assumed to be the source of the SIP message. For a SIP request, typically this is the UA identified by the URI in the From header field or a P-Asserted-Identity [RFC3325] header field. In a request with a History-Info header field, the recipient needs to parse the Targeted-to-URIs present (hi-targeted-to-uri defined in
UUI数据的接收者必须知道插入UUI数据的UA的身份。在没有历史信息头字段的请求中，插入UUI数据的实体的标识将被假定为SIP消息的源。对于SIP请求，通常这是由From头字段或P-Asserted-Identity[RFC3325]头字段中的URI标识的UA。在具有历史信息标头字段的请求中，收件人需要解析存在的目标uri（hi目标uri定义在中）
[RFC7044]) to see if any included User-to-User header fields are present. If an included User-to-User header field is present and matches the UUI data in the request, this indicates that redirection has taken place, resulting in the inclusion of UUI data in the request. The inserter of the UUI data will be the UA identified by the Targeted-to-URI of the History-Info element prior to the element with the included UUI data. In a response, the inserter of the UUI data will be the identity of the UA that generated the response. Typically, this is the UA identified in the To header field of the response. Note that any updates to this identity by use of the SIP connected identity extension [RFC4916] or other identity modifiers will update this information.
[RFC7044]），查看是否存在任何包含的用户到用户标题字段。如果存在包含的用户到用户标头字段并与请求中的UUI数据相匹配，则表示已发生重定向，导致请求中包含UUI数据。UUI数据的插入器将是由包含UUI数据的元素之前的History Info元素的Targeted to URI标识的UA。在响应中，UUI数据的插入器将是生成响应的UA的标识。通常，这是响应的To header字段中标识的UA。请注意，通过使用SIP连接的标识扩展[RFC4916]或其他标识修饰符对此标识进行的任何更新都将更新此信息。
For an example of History-Info and redirection, consider Figure 2 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, and the Terminating UA Alice. The INVITE F4 containing UUI data could be:
对于历史信息和重定向的例子，请考虑来自[RCF6567]的图2，其中原始UA是凯罗尔、Redirector Bob和终止UA爱丽丝。包含UUI数据的INVITE F4可以是：
INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>
INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>
Without the redirection captured in the History-Info header field, Alice would conclude that the UUI data was inserted by Carol. However, the History-Info containing UUI data (index=1.1) indicates that the inserter was Bob (index=1).
如果没有历史信息头字段中捕获的重定向，Alice会得出结论，UUI数据是由Carol插入的。但是，包含UUI数据（索引=1.1）的历史信息表明插入器是Bob（索引=1）。
To enable maintaining a record of the inserter identity of UUI data, UAs supporting this mechanism SHOULD support History-Info [RFC7044] and include Supported: histinfo in all requests and responses.
为了能够维护UUI数据插入器标识的记录，支持此机制的UAs应支持历史信息[RFC7044]，并在所有请求和响应中包括受支持的：histinfo。
If a border element such as a proxy or a Back-to-Back User Agent (B2BUA) removes a History-Info header field containing a User-to-User parameter, the UA consuming the UUI data may not be able at the SIP level to identify the source of the UUI data.
如果诸如代理或背对背用户代理（B2BUA）之类的边界元素删除了包含用户对用户参数的历史信息报头字段，则使用UUI数据的UA可能无法在SIP级别识别UUI数据的源。
UUI packages defined using this SIP UUI mechanism MUST follow the "Standards Action" guideline as defined in [RFC5226] and publish a Standards Track RFC that describes the usage. The CUSS WG chose to adopt this conservative policy while it considers other potential registration policies. Note that this mechanism is not suitable for the transport of arbitrary data between UAs. The following guidelines are provided to help determine if this mechanism is appropriate or not. The SIP UUI mechanism is applicable when all of the following conditions are met:
使用此SIP UUI机制定义的UUI包必须遵循[RFC5226]中定义的“标准操作”指南，并发布描述使用情况的标准跟踪RFC。CUSS工作组选择采用这一保守政策，同时考虑其他可能的注册政策。请注意，此机制不适用于UAs之间的任意数据传输。提供以下指南以帮助确定此机制是否合适。当满足以下所有条件时，SIP UUI机制适用：
1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily SIP aware.
1. 该信息由应用程序在使用SIP的会话设置期间生成和使用，但该应用程序不一定是SIP感知的。
2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of [RFC5727]).
2. 支持它的SIP实体的行为没有显著改变（如[RFC5727]第4节所述）。
3. UAs are the generators and consumers of the UUI data. Proxies and other intermediaries may route based on the presence of a User-to-User header field or a particular package tag but do not otherwise consume or generate the UUI data.
3. UAs是UUI数据的生成器和使用者。代理和其他中介可以基于用户到用户报头字段或特定包标签的存在进行路由，但不以其他方式使用或生成UUI数据。
4. There are no privacy issues associated with the information being transported (e.g., geolocation or emergency-related information are examples of inappropriate UUI data).
4. 不存在与正在传输的信息相关的隐私问题（例如，地理位置或与紧急情况相关的信息是不当UUI数据的示例）。
5. The UUI data is not being utilized for User-to-User Remote Procedure Calls (RPCs).
5. UUI数据未用于用户对用户远程过程调用（RPC）。
UUI packages define the semantics for a particular application usage of UUI data. The content defines the syntax of the UUI data, while the encoding defines the encoding of the UUI data for the content. Each content is defined as a stream of octets, which allows multiple encodings of that content. For example, packages may define:
UUI包定义UUI数据的特定应用程序使用的语义。内容定义UUI数据的语法，而编码定义内容的UUI数据的编码。每个内容都定义为一个八位字节流，允许对该内容进行多种编码。例如，包可以定义：
1. The SIP methods and responses in which the UUI data may be present.
1. 可能存在UUI数据的SIP方法和响应。
2. The maximum number of UUI data elements that may be inserted into a request or response. The default is one per encoding. Note that a UA may still receive a request with more than this maximum number due to redirection. The package needs to define how to handle this situation.
2. 可以插入到请求或响应中的UUI数据元素的最大数量。默认为每个编码一个。请注意，由于重定向，UA仍可能收到超过此最大数量的请求。软件包需要定义如何处理这种情况。
3. The default values for content and encoding if they are not present. If the same UUI data may be inserted multiple times with different encodings, the package needs to state this. A package may support and define multiple contents and their associated encodings and reuse contents defined by other packages.
3. 内容和编码的默认值（如果不存在）。如果相同的UUI数据可能以不同的编码多次插入，则包需要说明这一点。一个包可以支持和定义多个内容及其相关编码，并重用由其他包定义的内容。
4. Any size limitations on the UUI data. Size needs to be specified in terms of the octet stream output of the content, since the size of the resulting uui-data element will vary depending on the encoding scheme.
4. UUI数据的任何大小限制。需要根据内容的八位字节流输出指定大小，因为生成的uui数据元素的大小将根据编码方案而变化。
A package MUST define a "purpose" header field value to identify the package in the coding. A package MUST describe the new application that is utilizing the UUI data and provide some use case examples. The default "content" value MUST be defined or referenced in another document for the package. Additional allowed contents MAY also be defined or referenced. Any restrictions on the size of the UUI data MUST be described. In addition, a package MAY define a media feature tag per [RFC3840] to indicate support for this UUI package. For example, the media feature tag "sip.uui-pk1" could be defined to indicate support for a UUI package named pk1. The definition of a new SIP option tag solely to identify support for a UUI package is NOT RECOMMENDED unless there are additional SIP behaviors needed to implement this feature.
包必须定义“目的”标题字段值，以标识编码中的包。软件包必须描述使用UUI数据的新应用程序，并提供一些用例示例。默认的“内容”值必须在包的另一个文档中定义或引用。还可以定义或引用其他允许的内容。必须说明对UUI数据大小的任何限制。此外，包可根据[RFC3840]定义媒体功能标签，以指示对该UUI包的支持。例如，可以定义媒体功能标签“sip.uui-pk1”来表示对名为pk1的uui包的支持。除非实现此功能需要额外的SIP行为，否则不建议定义一个新的SIP选项标签来单独标识对UUI包的支持。
For an example UUI package definition, see [RFC7434].
有关UUI包定义的示例，请参见[RFC7434]。
New "content" values MUST describe the semantics of the UUI data and valid encodings, and give some example use cases. A previously defined UUI content value can be used in a new package. In this case, the semantics and usage of the content by the new package is defined within the new package. New UUI content types cannot be added to existing packages -- instead, a new package would need to be defined. New content values that are defined are added to the IANA registry with a Standards Track RFC, which needs to discuss the issues in this section. If no new encoding value is defined for a content, the encoding defaults to "hex" as defined in this document. In this case, the "hex" value will be explicitly stated via the encoding parameter as the encoding for the content.
新的“内容”值必须描述UUI数据和有效编码的语义，并给出一些示例用例。先前定义的UUI内容值可以在新包中使用。在这种情况下，新包对内容的语义和用法在新包中定义。新的UUI内容类型不能添加到现有包中——相反，需要定义一个新包。定义的新内容值通过标准跟踪RFC添加到IANA注册表中，这需要讨论本节中的问题。如果没有为内容定义新的编码值，则编码默认为本文档中定义的“十六进制”。在这种情况下，“十六进制”值将通过编码参数明确表示为内容的编码。
New "encoding" values associated with a new content MUST reference a specific encoding scheme (such as "hex", which is defined in this specification) or define the new encoding scheme. A previously defined UUI encoding value can be used with a newly defined content. In this case, the usage of the encoding is defined by the content
与新内容关联的新“编码”值必须引用特定的编码方案（如本规范中定义的“十六进制”）或定义新的编码方案。先前定义的UUI编码值可用于新定义的内容。在这种情况下，编码的使用由内容定义
definition. New UUI encodings cannot be added to existing contents -- instead, a new content would need to be defined. Newly defined encoding values are added to the IANA registry with a Standards Track RFC, which needs to discuss the issues in this section.
释义新的UUI编码不能添加到现有内容中——相反，需要定义新内容。新定义的编码值通过标准跟踪RFC添加到IANA注册表中，这需要讨论本节中的问题。
This document defines a new SIP header field named "User-to-User".
本文档定义了一个名为“用户对用户”的新SIP头字段。
The following row has been added to the "Header Fields" section of the SIP parameter registry:
以下行已添加到SIP参数注册表的“标题字段”部分：
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFC7433] |
+------------------+--------------+-----------+
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFC7433] |
+------------------+--------------+-----------+
This document defines the parameters for the header field defined in the preceding section. The header field "User-to-User" can contain the parameters "encoding", "content", and "purpose".
本文档定义了上一节中定义的标题字段的参数。标题字段“用户对用户”可以包含参数“编码”、“内容”和“目的”。
The following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
以下行已添加到SIP参数注册表的“标题字段参数和参数值”部分：
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User | encoding | Yes | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | content | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | purpose | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User | encoding | Yes | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | content | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | purpose | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
This specification establishes the "UUI Packages" subregistry under <http://www.iana.org/assignments/sip-parameters>.
本规范建立了以下“UUI包”子区域：<http://www.iana.org/assignments/sip-parameters>.
The descriptive text for this subregistry is:
本次区域的描述性文本为：
UUI packages provide information about the usage of the UUI data in a User-to-User header field [RFC7433].
UUI包在用户对用户标头字段[RFC7433]中提供有关UUI数据使用情况的信息。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
此注册表的注册策略为[RFC5226]中定义的“标准行动”。
+------------+------------------------------------------+-----------+
| Package | Description | Reference |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Package | Description | Reference |
+------------+------------------------------------------+-----------+
This specification establishes the "UUI Content Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters>.
本规范建立了以下“UUI内容参数”子区域：<http://www.iana.org/assignments/sip-parameters>.
The descriptive text for this subregistry is:
本次区域的描述性文本为：
UUI content provides information about the content of the UUI data in a User-to-User header field [RFC7433].
UUI内容在用户对用户标题字段[RFC7433]中提供有关UUI数据内容的信息。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
此注册表的注册策略为[RFC5226]中定义的“标准行动”。
+------------+------------------------------------------+-----------+
| Content | Description | Reference |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Content | Description | Reference |
+------------+------------------------------------------+-----------+
This specification establishes the "UUI Encoding Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters> and initiates its population with the table below.
本规范建立了以下“UUI编码参数”子区域：<http://www.iana.org/assignments/sip-parameters>并使用下表启动其人口。
The descriptive text for this subregistry is:
本次区域的描述性文本为：
UUI encoding provides information about the encoding of the UUI data in a User-to-User header field [RFC7433].
UUI编码提供有关用户对用户报头字段[RFC7433]中UUI数据编码的信息。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
此注册表的注册策略为[RFC5226]中定义的“标准行动”。
+-----------+-------------------------------------------+-----------+
| Encoding | Description | Reference |
+-----------+-------------------------------------------+-----------+
| hex | The UUI data is encoded using hexadecimal | [RFC7433] |
+-----------+-------------------------------------------+-----------+
+-----------+-------------------------------------------+-----------+
| Encoding | Description | Reference |
+-----------+-------------------------------------------+-----------+
| hex | The UUI data is encoded using hexadecimal | [RFC7433] |
+-----------+-------------------------------------------+-----------+
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261].
根据[RFC3261]第27.1节中的指南，本规范注册了一个新的SIP选项标签。
This document defines the SIP option tag "uui".
本文档定义了SIP选项标签“uui”。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| uui | This option tag is used to indicate that | [RFC7433] |
| | a UA supports and understands the | |
| | User-to-User header field. | |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| uui | This option tag is used to indicate that | [RFC7433] |
| | a UA supports and understands the | |
| | User-to-User header field. | |
+------------+------------------------------------------+-----------+
UUI data can potentially carry sensitive information that might require confidentiality protection for privacy or integrity protection from third parties that may wish to read or modify the UUI data. The three security models described in [RFC6567] may be applicable for the UUI mechanism.
UUI数据可能携带敏感信息，这些信息可能需要保密保护，以保护隐私或完整性，不受可能希望读取或修改UUI数据的第三方的影响。[RFC6567]中描述的三种安全模型可能适用于UUI机制。
One model treats the SIP layer as untrusted and requires end-to-end integrity protection and/or encryption. This model can be achieved by providing these security services at a layer above SIP. In this case, applications are encouraged to use their own integrity and/or encryption mechanisms before passing it to the SIP layer.
一种模型将SIP层视为不受信任的层，需要端到端完整性保护和/或加密。该模型可以通过在SIP之上的一层提供这些安全服务来实现。在这种情况下，鼓励应用程序在将其传递到SIP层之前使用自己的完整性和/或加密机制。
The second approach is for the application to pass the UUI without any protection to the SIP layer and require the SIP layer to provide this security. This approach is possible in theory, although its practical use would be extremely limited. To preserve multi-hop or end-to-end confidentiality and integrity of UUI data, approaches using S/MIME or IPsec can be used, as discussed in the review of REQ-13 and REQ-14 in Section 3 of this document. However, the lack of deployment of these mechanisms means that applications cannot in general rely on them being present.
第二种方法是应用程序在没有任何保护的情况下将UUI传递给SIP层，并要求SIP层提供这种安全性。这一方法在理论上是可行的，尽管其实际用途极为有限。为了保护UUI数据的多跳或端到端机密性和完整性，可以使用使用S/MIME或IPsec的方法，如本文档第3节REQ-13和REQ-14审查中所述。然而，缺乏这些机制的部署意味着应用程序通常不能依赖它们的存在。
The third model utilizes a trust domain and relies on perimeter security at the SIP layer. This is the security model of the PSTN and ISDN where UUI is commonly used today. This approach uses hop-by-hop security mechanisms and relies on border elements for
第三个模型利用信任域并依赖于SIP层的外围安全。这是目前普遍使用UUI的PSTN和ISDN的安全模型。这种方法使用逐跳安全机制，并依赖于边界元素来实现
filtering and application of policy. Standard deployed SIP security mechanisms such as TLS transport offer privacy and integrity protection properties on a hop-by-hop basis at the SIP layer.
策略的筛选和应用。标准部署的SIP安全机制（如TLS传输）在SIP层逐跳提供隐私和完整性保护属性。
If the UUI data was included by the UA originator of the SIP request or response, normal SIP mechanisms can be used to determine the identity of the inserter of the UUI data. If the UUI data was included by a UA that was not the originator of the request, a History-Info header field can be used to determine the identity of the inserter of the UUI data. UAs can apply policy based on the origin of the UUI data using this information. In short, the UUI data included in an INVITE can be trusted as much as the INVITE itself can be trusted.
如果UUI数据由SIP请求或响应的UA发起人包括，则可以使用正常的SIP机制来确定UUI数据的插入者的身份。如果UUI数据由非请求发起人的UA包含，则历史信息头字段可用于确定UUI数据插入者的身份。UAs可以使用此信息基于UUI数据的来源应用策略。简而言之，可以信任INVITE中包含的UUI数据，就像信任INVITE本身一样。
Note that it is possible that this mechanism could be used as a covert communication channel between UAs, conveying information unknown to the SIP network.
注意，该机制可以用作UAs之间的隐蔽通信信道，传输SIP网络未知的信息。
[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>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[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>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”<http://www.rfc-editor.org/info/rfc3891>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月<http://www.rfc-editor.org/info/rfc4474>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007, <http://www.rfc-editor.org/info/rfc4916>.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 49162007年6月<http://www.rfc-editor.org/info/rfc4916>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044]Barnes，M.，Audet，F.，Schubert，S.，van Elburg，J.，和C.Holmberg，“请求历史信息会话启动协议（SIP）的扩展”，RFC 70442014年2月<http://www.rfc-editor.org/info/rfc7044>.
[RFC7434] Drage, K. and A. Johnston, "Interworking ISDN Call Control User Information with SIP", RFC 7434, January 2015, <http://www.rfc-editor.org/info/rfc7434>.
[RFC7434]Drage，K.和A.Johnston，“与SIP互通ISDN呼叫控制用户信息”，RFC 7434，2015年1月<http://www.rfc-editor.org/info/rfc7434>.
[Q1980] ITU-T, "The Narrowband Signalling Syntax (NSS) - Syntax Definition", ITU-T Recommendation Q.1980.1, <http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/ q1980.1/q1980.1.html>.
[Q1980]ITU-T，“窄带信令语法（NSS）-语法定义”，ITU-T建议Q.1980.1<http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/ q1980.1/q1980.1.html>。
[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>.
[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>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 33252002年11月<http://www.rfc-editor.org/info/rfc3325>.
[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>.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006, <http://www.rfc-editor.org/info/rfc4475>.
[RFC4475]Sparks，R.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月<http://www.rfc-editor.org/info/rfc4475>.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010, <http://www.rfc-editor.org/info/rfc5727>.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月<http://www.rfc-editor.org/info/rfc5727>.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011, <http://www.rfc-editor.org/info/rfc6086>.
[RFC6086]Holmberg，C.，Burger，E.，和H.Kaplan，“会话启动协议（SIP）信息方法和包框架”，RFC 60862011年1月<http://www.rfc-editor.org/info/rfc6086>.
[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>.
Two other possible mechanisms for transporting UUI data will be described: MIME body and URI parameter transport.
将描述用于传输UUI数据的另外两种可能机制：MIME主体和URI参数传输。
Since the INFO method [RFC6086] was developed for ISDN User Part (ISUP) interworking of User-to-User Information, it might seem to be the logical choice here. For non-call control User-to-User Information, INFO can be utilized for end-to-end transport. However, for transport of call control User-to-User Information, INFO can not be used. As the call flows in [RFC6567] show, the information is related to an attempt to establish a session and needs to be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.
由于INFO方法[RFC6086]是为ISDN用户部分（ISUP）用户对用户信息的互通而开发的，因此它似乎是这里的逻辑选择。对于非呼叫控制用户对用户信息，信息可用于端到端传输。但是，对于呼叫控制用户到用户信息的传输，不能使用INFO。正如[RFC6567]中的调用流程所示，该信息与建立会话的尝试有关，需要与会话设置请求（INVITE）、对该INVITE的响应或会话终止请求一起传递。因此，在这些情况下不可能使用信息。
Other protocols have the ability to transport UUI data. For example, consider the ITU-T Recommendation Q.931 User-user information element [Q931] and the ITU-T Recommendation Q.763 User-to-User information parameter [Q763]. In addition, the Narrowband Signalling System (NSS) [Q1980] is also able to transport UUI data. Should one of these protocols be in use, and present in both User Agents, then utilizing these other protocols to transport UUI data might be a logical solution. Essentially, this is just adding an additional layer in the protocol stack. In these cases, SIP is not transporting the UUI data; it is encapsulating another protocol, and that protocol is transporting the UUI data. Once a mechanism to transport that other protocol using SIP exists, the UUI data transport function is essentially obtained without any additional effort or work.
其他协议具有传输UUI数据的能力。例如，考虑ITU-T推荐Q.931用户用户信息元素[Q931]和ITU-T推荐Q.763用户到用户信息参数[Q763]。此外，窄带信号系统（NSS）[Q1980]也能够传输UUI数据。如果这些协议中有一个正在使用，并且出现在两个用户代理中，那么利用这些其他协议来传输UUI数据可能是一个合乎逻辑的解决方案。本质上，这只是在协议栈中添加一个附加层。在这些情况下，SIP不传输UUI数据；它封装了另一个协议，该协议正在传输UUI数据。一旦存在使用SIP传输其他协议的机制，UUI数据传输功能基本上就可以获得，而无需任何额外的努力或工作。
However, the CUSS working group believes, consistent with its charter, that SIP needs to have its own native UUI data transport mechanism. It is not reasonable for a SIP UA to have to implement another entire protocol (either ISDN or NSS, for example) just to get the very simple UUI data transport service. Of course, this work does not preclude anyone from using other protocols with SIP to transport UUI data.
然而，CUSS工作组认为，根据其章程，SIP需要有自己的本地UUI数据传输机制。SIP UA仅仅为了获得非常简单的UUI数据传输服务而必须实现另一个完整的协议（例如ISDN或NSS）是不合理的。当然，这项工作并不妨碍任何人使用SIP的其他协议来传输UUI数据。
One method of transport is to use a MIME body. This is in keeping with the Session Initiation Protocol for Telephones (SIP-T) architecture [RFC3372] in which MIME bodies are used to transport ISUP information. Since the INVITE will normally have a Session
一种传输方法是使用MIME主体。这与电话会话启动协议（SIP-T）体系结构[RFC3372]一致，在该体系结构中，MIME主体用于传输ISUP信息。因为邀请通常会有一个会话
Description Protocol (SDP) message body, the resulting INVITE with SDP and UUI data will be multipart MIME. This is not ideal as many SIP UAs do not support multipart MIME INVITEs.
描述协议（SDP）消息体，生成的包含SDP和UUI数据的INVITE将是多部分MIME。这并不理想，因为许多SIP UA不支持多部分MIME邀请。
A bigger problem is the insertion of a UUI message body by a redirect server or in a REFER. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. Currently, the authors are not aware of any UAs that support this capability today for any body type. As such, the complete set of semantics for this operation would need to be determined and defined. Some issues will need to be resolved, such as, do all the Content-* header fields have to be included as well? And, what if the included Content-Length does not agree with the included body?
更大的问题是重定向服务器或引用中插入UUI消息体。正文需要在3xx响应的Contact URI或refere的refere-to URI中编码。目前，作者还不知道目前有哪种UAs支持任何体型的这种能力。因此，需要确定和定义此操作的完整语义集。有些问题需要解决，例如，是否也必须包括所有Content-*标题字段？而且，如果包含的内容长度与包含的正文不一致怎么办？
Since proxies cannot remove a body from a request or response, it is not clear how this mechanism could meet REQ-9.
由于代理无法从请求或响应中删除主体，因此不清楚该机制如何满足REQ-9。
The requirement for integrity protection could be met by the use of an S/MIME signature over the body, as defined in "Securing MIME bodies", Section 23.3 of RFC 3261. Alternatively, this could be achieved using [RFC4474]. The requirement for end-to-end privacy could be met using S/MIME encryption or using encryption at the application layer. However, note that neither S/MIME or RFC 4474 enjoys deployment in SIP today.
完整性保护的要求可以通过在主体上使用S/MIME签名来满足，如RFC 3261第23.3节“保护MIME主体”中所定义。或者，这可以使用[RFC4474]实现。使用S/MIME加密或在应用层使用加密可以满足端到端隐私的要求。但是，请注意，S/MIME或RFC4474都不适合在今天的SIP中部署。
An example:
例如：
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, although the authors do not have a specific mechanism to propose. Meeting REQ-3 is problematic but not impossible for this mechanism. However, this mechanism does not seem to be able to meet REQ-9.
因此，MIME正文方法满足REQ-1、REQ-2、REQ-4、REQ-5、REQ-7、REQ-11、REQ-13和REQ-14。满足REQ-12似乎是可能的，尽管作者没有提出具体的机制。满足REQ-3是有问题的，但对于这种机制来说并非不可能。然而，这种机制似乎不能满足REQ-9的要求。
Another proposed approach is to encode the UUI data as a URI parameter. This UUI parameter could be included in a Request-URI or in the Contact URI or Refer-To URI. It is not clear how it could be transported in a response that does not have a Request-URI, or in BYE requests or responses.
另一种建议的方法是将UUI数据编码为URI参数。此UUI参数可以包含在请求URI、联系人URI或引用URI中。不清楚如何在没有请求URI的响应中，或者在BYE请求或响应中传输它。
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT
6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT
6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
An INVITE sent to this Contact URI would contain UUI data in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter carried in a Request-URI will not survive retargeting by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is included with an Address of Record instead of a Contact URI, the URI parameter in the Request-URI will not be copied over to the Contact URI, resulting in the loss of the information. Note that if this same URI was present in a Refer-To header field, the same loss of information would occur.
发送到此联系人URI的INVITE将在INVITE的请求URI中包含UUI数据。URI参数有一个缺点，即请求URI中携带的URI参数将无法通过代理的重定目标，如[RFC6567]的图2所示。也就是说，如果URI包含在记录地址而不是联系人URI中，则请求URI中的URI参数将不会复制到联系人URI，从而导致信息丢失。请注意，如果referetoheader字段中存在相同的URI，则会发生相同的信息丢失。
The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and REQ-11. It is possible the approach could meet REQ-12 and REQ-13. The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and REQ-14.
URI参数方法将满足REQ-3、REQ-5、REQ-7、REQ-9和REQ-11。该方法可能满足REQ-12和REQ-13的要求。该机制似乎不符合REQ-1、REQ-2、REQ-4和REQ-14。
Acknowledgments
致谢
Joanne McMillen was a major contributor and coauthor of earlier versions of this document. Thanks to Paul Kyzivat for his contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura Liess for their review of the document. The authors wish to thank Roland Jesske, Celine Serrut-Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments. Thanks to Scott Kelly and Joel Halpern for their reviews.
Joanne McMillen是本文档早期版本的主要贡献者和合著者。感谢Paul Kyzivat对十六进制编码规则的贡献。感谢Spencer Dawkins、Keith Drage、Vijay Gurbani和Laura Liess对该文件的审阅。作者希望感谢罗兰·杰西克、塞琳·塞鲁特·瓦莱特、弗朗索瓦·奥德特、丹尼斯·阿列克谢采夫、保罗·基齐瓦特、卡伦·詹宁斯和马哈林根·马尼的评论。感谢Scott Kelly和Joel Halpern的评论。
Authors' Addresses
作者地址
Alan Johnston Avaya St. Louis, MO 63124 United States
美国密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63124
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com
James Rafferty Human Communications Norfolk, MA 02056 United States
美国马萨诸塞州诺福克市詹姆斯·拉弗蒂人类通信公司02056
EMail: jay@humancomm.com
EMail: jay@humancomm.com