Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 6567 Avaya
Category: Informational L. Liess
ISSN: 2070-1721 Deutsche Telekom AG
April 2012
Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 6567 Avaya
Category: Informational L. Liess
ISSN: 2070-1721 Deutsche Telekom AG
April 2012
Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP
SIP中传输用户对用户呼叫控制信息的问题陈述和要求
Abstract
摘要
This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI.
本文档介绍了使用会话发起协议（SIP）传输呼叫控制用户到用户信息（UUI），并对新的SIP机制提出了若干要求。一些SIP会话由非SIP应用程序建立或与之相关。此应用程序可能具有会话建立期间需要在SIP用户代理之间传输的信息。除了与综合业务数字网（ISDN）UUI服务互通外，此扩展还将用于需要应用UUI的本机SIP端点。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6567.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6567.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview ........................................................2
2. Use Cases .......................................................3
2.1. User Agent to User Agent ...................................3
2.2. Proxy Retargeting ..........................................4
2.3. Redirection ................................................4
2.4. Referral ...................................................5
3. Requirements ....................................................6
4. Security Considerations .........................................8
5. Acknowledgements ...............................................10
6. Informative References .........................................10
1. Overview ........................................................2
2. Use Cases .......................................................3
2.1. User Agent to User Agent ...................................3
2.2. Proxy Retargeting ..........................................4
2.3. Redirection ................................................4
2.4. Referral ...................................................5
3. Requirements ....................................................6
4. Security Considerations .........................................8
5. Acknowledgements ...............................................10
6. Informative References .........................................10
This document describes the transport of User-to-User Information (UUI) during SIP [RFC3261] session setup. This section introduces UUI and explains how it relates to SIP.
本文档描述了SIP[RFC3261]会话设置期间用户到用户信息（UUI）的传输。本节介绍UUI并解释它与SIP的关系。
We define SIP UUI data as application-specific information that is related to a session being established using SIP. It is assumed that the application is running in both endpoints in a two-party session. That is, the application interacts with both the User Agents in a SIP session. In order to function properly, the application needs a small piece of information, the UUI, to be transported at the time of session establishment. This information is essentially opaque data to SIP -- it is unrelated to SIP routing, authentication, or any other SIP function. This application can be considered to be operating at a higher layer on the protocol stack. As a result, SIP should not interpret, understand, or perform any operations on the UUI. Should this not be the case, then the information being transported is not considered UUI, and another SIP-specific mechanism will be needed to transport the information (such as a new header field). In particular, this mechanism creates no requirements on intermediaries such as proxies, Back-to-Back User Agents, and Session Border Controllers.
我们将SIP UUI数据定义为与使用SIP建立的会话相关的特定于应用程序的信息。假定应用程序在两方会话的两个端点中运行。也就是说，应用程序在SIP会话中与两个用户代理交互。为了正常运行，应用程序需要在会话建立时传输一小段信息，即UUI。该信息对于SIP来说本质上是不透明的数据——它与SIP路由、身份验证或任何其他SIP功能无关。可以认为此应用程序在协议栈的更高层运行。因此，SIP不应解释、理解或执行UUI上的任何操作。如果不是这种情况，则传输的信息不被视为UUI，需要另一种特定于SIP的机制来传输信息（例如新的报头字段）。特别是，该机制对代理、背对背用户代理和会话边界控制器等中介体没有任何要求。
UUI is defined this way for two reasons. First, this definition supports a strict layering of protocols and data. Providing information and understanding of the UUI to the transport layer (SIP in this case) would not provide any benefits and instead could create cross-layer coupling. Second, it is neither feasible nor desirable
UUI以这种方式定义有两个原因。首先，此定义支持协议和数据的严格分层。向传输层（本例中为SIP）提供UUI的信息和理解不会带来任何好处，反而会产生跨层耦合。其次，它既不可行也不可取
for a SIP User Agent (UA) to understand the information; instead, the goal is for the UA to simply pass the information as efficiently as possible to the application that does understand the information.
让SIP用户代理（UA）理解该信息；相反，UA的目标是尽可能高效地将信息传递给理解信息的应用程序。
An important application is the interworking with User-to-User Information (UUI) in ISDN, specifically the transport of the call-control-related ITU-T Q.931 User-to-User Information Element (UUIE) [Q931] and ITU-T Q.763 User-to-User Information Parameter [Q763] data in SIP. ISDN UUI is widely used in the Public Switched Telephone Network (PSTN) today in contact centers and call centers. These applications are currently transitioning away from using ISDN for session establishment to using SIP. Native SIP endpoints will need to implement a similar service and be able to interwork with this ISDN service.
一个重要的应用是ISDN中用户对用户信息（UUI）的互通，特别是SIP中与呼叫控制相关的ITU-T Q.931用户对用户信息元素（UUIE）[Q931]和ITU-T Q.763用户对用户信息参数[Q763]数据的传输。ISDN UUI广泛应用于公共交换电话网（PSTN）中的联络中心和呼叫中心。这些应用程序目前正在从使用ISDN建立会话过渡到使用SIP。本机SIP端点将需要实现类似的服务，并能够与此ISDN服务互通。
Note that the distinction between call control UUI and non-call-control UUI is very important. SIP already has a mechanism for sending arbitrary UUI data between UAs during a session or dialog -- the SIP INFO [RFC6086] method. Call control UUI, in contrast, must be exchanged at the time of setup and needs to be carried in the INVITE and a few other methods and responses. Applications that exchange UUI but do not have a requirement that it be transported and processed during call setup can simply use SIP INFO and do not need a new SIP extension.
请注意，呼叫控制UUI和非呼叫控制UUI之间的区别非常重要。SIP已经有了在会话或对话期间在UAs之间发送任意UUI数据的机制——SIP INFO[RFC6086]方法。相反，调用控制UUI必须在设置时交换，并且需要在INVITE和其他一些方法和响应中携带。交换UUI但不要求在呼叫设置期间传输和处理UUI的应用程序可以简单地使用SIP信息，而不需要新的SIP扩展。
In this document, four different use case call flows are discussed. Next, the requirements for call control UUI transport are discussed.
在本文档中，讨论了四种不同的用例调用流。接下来，讨论了呼叫控制UUI传输的需求。
This section discusses four use cases for the transport of call control User-to-User Information. These use cases will help motivate the requirements for SIP call control UUI.
本节讨论呼叫控制用户到用户信息传输的四个用例。这些用例将有助于激发SIP呼叫控制UUI的需求。
In this scenario, the originating UA includes UUI in the INVITE sent through a proxy to the terminating UA. The terminating UA can use the UUI in any way. If it is an ISDN gateway, it could map the UUI into the appropriate DSS1 [Q933] information element, QSIG [QSIG] information element, or ISDN User Part (ISUP) parameter. Alternatively, the using application might render the information to the user or use it during alerting or as a lookup for a screen pop. In this case, the proxy does not need to understand the UUI mechanism, but normal proxy rules should result in the UUI being forwarded without modification. This call flow is shown in Figure 1.
在此场景中，发起UA在通过代理发送给终止UA的INVITE中包括UUI。终端UA可以以任何方式使用UUI。如果是ISDN网关，它可以将UUI映射到适当的DSS1[Q933]信息元素、QSIG[QSIG]信息元素或ISDN用户部件（ISUP）参数中。或者，正在使用的应用程序可能会将信息呈现给用户，或者在发出警报或查找屏幕弹出窗口时使用它。在这种情况下，代理不需要了解UUI机制，但是正常的代理规则应该会导致UUI在不修改的情况下被转发。此调用流如图1所示。
Originating UA Proxy Terminating UA
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Originating UA Proxy Terminating UA
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 1: Call Flow with UUI Exchanged between Originating and Terminating UAs
图1：发起和终止UAs之间交换UUI的呼叫流
In this scenario, the originating UA includes UUI in the INVITE request sent through a proxy to the terminating UA. The proxy retargets the INVITE request, changing its Request-URI to a URI that addresses the terminating UA. The UUI data is then received and processed by the terminating UA. This call flow is identical to Figure 1 except that the proxy retargets the request, i.e., changes the Request-URI as directed by some unspecified process. The UUI in the INVITE request needs to be passed unchanged through this proxy retargeting operation. Note that the contents of the UUI is not used by the proxy for routing, as the UUI has only end-to-end significance between UAs.
在此场景中，发起UA在通过代理发送给终止UA的INVITE请求中包括UUI。代理重新确定INVITE请求的目标，将其请求URI更改为寻址终止UA的URI。UUI数据随后由终端UA接收和处理。该调用流与图1相同，不同之处在于代理重新定位请求，即根据某个未指定进程的指示更改请求URI。INVITE请求中的UUI需要通过此代理重定目标操作原封不动地传递。请注意，代理不使用UUI的内容进行路由，因为UUI在UAs之间只有端到端的重要性。
In this scenario, UUI is inserted by an application that utilizes a SIP Redirect Server. The UUI is then included in the INVITE request sent by the originating UA to the terminating UA. In this case, the originating UA does not necessarily need to support the UUI mechanism but does need to support the SIP redirection mechanism used to include the UUI data. Two examples of UUI with redirection (transfer and diversion) are defined in [ANSI] and [ETSI].
在此场景中，UUI由利用SIP重定向服务器的应用程序插入。然后，UUI包括在发起UA发送给终止UA的INVITE请求中。在这种情况下，发起UA不一定需要支持UUI机制，但需要支持用于包括UUI数据的SIP重定向机制。[ANSI]和[ETSI]中定义了具有重定向（传输和转移）的UUI的两个示例。
Note that this case may not precisely map to an equivalent ISDN service use case. This is because there is no one-to-one mapping between elements in a SIP network and elements in an ISDN network. Also, there is not an exact one-to-one mapping between SIP call control and ISDN call control. However, this should not prevent the usage of SIP call control UUI in these cases. Instead, these slight differences between the SIP UUI mechanism and the ISDN service need to be carefully noted and discussed in an interworking specification.
请注意，这种情况可能无法精确映射到等效的ISDN服务用例。这是因为SIP网络中的元素与ISDN网络中的元素之间没有一对一的映射。此外，SIP呼叫控制和ISDN呼叫控制之间没有精确的一对一映射。但是，这不应阻止在这些情况下使用SIP呼叫控制UUI。相反，SIP UUI机制和ISDN服务之间的这些细微差异需要在互通规范中仔细注意和讨论。
Figure 2 shows this scenario, with the Redirect Server inserting UUI that is then included in the INVITE request F4 sent to the terminating UA.
图2显示了这个场景，重定向服务器插入UUI，UUI随后包含在发送给终止UA的INVITE请求F4中。
Originating UA Redirect Server Terminating UA
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Originating UA Redirect Server Terminating UA
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Figure 2: Call Flow with UUI Exchanged between Redirect Server and Terminating UA
图2：重定向服务器和终止UA之间交换UUI的调用流
A common example application of this call flow is an Automatic Call Distributer (ACD) in a PSTN contact center. The originator would be a PSTN gateway. The ACD would act as a Redirect Server, inserting UUI based on called number, calling number, time of day, and other information. The resulting UUI would be passed to the agent's handset which acts as the terminating UA. The UUI could be used to lookup information for rendering to the agent at the time of call answering.
此呼叫流的一个常见示例应用是PSTN呼叫中心中的自动呼叫分配器（ACD）。发起者将是一个PSTN网关。ACD将充当重定向服务器，根据被叫号码、主叫号码、一天中的时间和其他信息插入UUI。产生的UUI将被传递到代理的手持设备，作为终端UA。UUI可用于查找信息，以便在应答呼叫时呈现给代理。
This redirection scenario and the referral scenario in the next section are the most important scenarios for contact center applications. Incoming calls to a contact center almost always are redirected or referred to a final destination, sometimes multiple times, based on collected information and business logic. The ability to pass along UUI in these call redirection scenarios is critical.
下一节中的重定向场景和转诊场景是呼叫中心应用程序最重要的场景。根据收集的信息和业务逻辑，呼叫中心的来电几乎总是被重定向或转介到最终目的地，有时是多次。在这些调用重定向场景中传递UUI的能力至关重要。
In this scenario, the application uses a UA to initiate a referral, which causes an INVITE request to be generated between the originating UA and terminating UA with UUI data inserted by the referrer UA. Note that this REFER method [RFC3515] could be part of a transfer operation, or it might be unrelated to an existing call, such as out-of-dialog REFER request. In some cases, this call flow
在该场景中，应用程序使用UA来发起转介，这导致在发起UA和终止UA之间生成INVITE请求，其中UUI数据由转介UA插入。请注意，此REFER方法[RFC3515]可能是传输操作的一部分，也可能与现有调用无关，例如对话框外REFER请求。在某些情况下，此调用流
is used in place of the redirection call flow: the referrer immediately answers the call and then sends the REFER request. This scenario is shown in Figure 3.
用于代替重定向呼叫流：推荐人立即应答呼叫，然后发送推荐请求。此场景如图3所示。
Originating UA Referrer Terminating UA
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| INVITE (UUI) F3 | |
|---------------------------------------->|
| NOTIFY (100 Trying) F4 |
|------------------->| |
| 200 OK F5 | |
|<-------------------| |
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
Originating UA Referrer Terminating UA
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| INVITE (UUI) F3 | |
|---------------------------------------->|
| NOTIFY (100 Trying) F4 |
|------------------->| |
| 200 OK F5 | |
|<-------------------| |
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
Figure 3: Call Flow with Referral and UUI
图3：带转诊和UUI的呼叫流
This section states the requirements for the transport of call control User-to-User Information (UUI).
本节说明了呼叫控制用户对用户信息（UUI）传输的要求。
REQ-1: The mechanism will allow UAs to insert and receive UUI data in SIP call setup requests and responses.
REQ-1：该机制将允许UAs在SIP呼叫设置请求和响应中插入和接收UUI数据。
SIP messages covered by this include INVITE requests and end-to-end responses to the INVITE, i.e., 18x and 200 responses. UUI data may also be inserted in 3xx responses to an INVITE. However, if a 3xx response is recursed on by an intermediary proxy, the resulting INVITE will not contain the UUI data from the 3xx response. In a scenario where a proxy forks an INVITE to multiple UAS who include UUI data in 3xx responses, if a 3xx response is the best response sent upstream by the proxy, it will contain the UUI data from only one 3xx response.
本节涵盖的SIP消息包括INVITE请求和对INVITE的端到端响应，即18x和200响应。UUI数据也可以插入到对邀请的3xx响应中。但是，如果3xx响应由中间代理递归，则生成的INVITE将不包含来自3xx响应的UUI数据。在代理向多个UAS发出邀请的场景中，这些UAS在3xx响应中包含UUI数据，如果3xx响应是代理向上游发送的最佳响应，则它将只包含一个3xx响应中的UUI数据。
REQ-2: The mechanism will allow UAs to insert and receive UUI data in SIP dialog terminating requests and responses.
REQ-2：该机制将允许UAs在终止请求和响应的SIP对话框中插入和接收UUI数据。
Q.931 UUI supports inclusion in release and release completion messages. SIP messages covered by this include BYE and 200 OK responses to a BYE.
Q.931 UUI支持包含在发布和发布完成消息中。本节涵盖的SIP消息包括BYE和对BYE的200个OK响应。
REQ-3: The mechanism will allow UUI to be inserted and retrieved in SIP redirects and referrals.
REQ-3：该机制将允许在SIP重定向和引用中插入和检索UUI。
SIP messages covered by this include REFER requests and 3xx responses to INVITE requests.
本节涵盖的SIP消息包括REFER请求和INVITE请求的3xx响应。
REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting or redirection of the request.
REQ-4：该机制将允许UUI能够在代理重定目标或请求重定向后生存。
Retargeting is a common method of call routing in SIP and must not result in the loss of User-to-User Information.
重定目标是SIP中一种常见的呼叫路由方法，不能导致用户间信息的丢失。
REQ-5: The mechanism should not require processing entities to dereference a URL in order to retrieve the UUI data.
REQ-5：该机制不应要求处理实体为了检索UUI数据而取消对URL的引用。
Passing a pointer or link to the UUI data will not meet the real-time processing considerations and would complicate interworking with the PSTN.
将指针或链接传递到UUI数据将不符合实时处理考虑，并将使与PSTN的互通变得复杂。
REQ-6: The mechanism will support interworking with call-control-related DSS1 information elements or QSIG information elements and ISUP parameters.
REQ-6：该机制将支持与呼叫控制相关的DSS1信息元素或QSIG信息元素和ISUP参数的互通。
REQ-7: The mechanism will allow a UAC to learn that a UAS understands the UUI mechanism.
REQ-7：该机制将允许UAC了解UAS了解UUI机制。
REQ-8: The mechanism will allow a UAC to require that a UAS understands the call control UUI mechanism and have a request routed based on this information. If the request cannot be routed to a UAS that understands the UUI mechanism, the request will fail.
REQ-8：该机制将允许UAC要求UAS了解呼叫控制UUI机制，并根据该信息路由请求。如果请求无法路由到理解UUI机制的UAS，则请求将失败。
This could be useful in ensuring that a request destined for the PSTN is routed to a gateway that supports the UUI mechanism rather than an otherwise equivalent PSTN gateway that does not support the ISDN mechanism. Note that support of the UUI mechanism does not, by itself, imply that a particular application is supported (see REQ-10).
这有助于确保发送给PSTN的请求路由到支持UUI机制的网关，而不是不支持ISDN机制的其他等效PSTN网关。请注意，UUI机制的支持本身并不意味着支持特定的应用程序（请参阅REQ-10）。
REQ-9: The mechanism will allow proxies to remove a particular application usage of UUI data from a request or response.
REQ-9：该机制将允许代理从请求或响应中删除UUI数据的特定应用程序使用。
This is a common security function provided by border elements to header fields such as Alert-Info or Call-Info URIs. There is no requirement for UAs to be able to determine if a particular usage of UUI data has been removed from a request or response.
这是一个常见的安全功能，由边界元素提供给标题字段，如警报信息或呼叫信息URI。UAs不需要能够确定UUI数据的特定用途是否已从请求或响应中删除。
REQ-10: The mechanism will provide the ability for a UA to discover which application usages of UUI another UA understands or supports.
REQ-10：该机制将为UA提供发现其他UA理解或支持的UUI应用程序用法的能力。
The creation of a registry of application usages for the UUI mechanism is implied by this requirement. The ISDN service utilizes a field known as the protocol discriminator, which is the first octet of the ISDN UUI data, for this purpose.
此要求暗示了为UUI机制创建应用程序用法注册表。为此，ISDN服务使用称为协议鉴别器的字段，该字段是ISDN UUI数据的第一个八位组。
REQ-11: The UUI is a sequence of octets. The solution will provide a mechanism of transporting at least 128 octets of user data and a one-octet protocol discriminator, i.e., 129 octets in total.
REQ-11:UUI是一个八位字节序列。该解决方案将提供传输至少128个八位字节的用户数据的机制和一个八位字节协议鉴别器，即总共129个八位字节。
There is the potential for non-ISDN services to allow UUI to be larger than 128 octets. However, users of the mechanism will need be cognizant of the size of SIP messages and the ability of parsers to handle extremely large values.
非ISDN业务有可能允许UUI大于128个八位字节。但是，该机制的用户需要了解SIP消息的大小以及解析器处理超大值的能力。
REQ-12: The recipient of UUI will be able to determine the entity that inserted the UUI. It is acceptable that this is performed implicitly where it is known that there is only one other end UA involved in the dialog. Where that does not exist, some other mechanism will need to be provided. The UUI mechanism does not introduce stronger authorization requirements for SIP; instead, the mechanism needs to be able to utilize existing SIP approaches for request and response identity.
REQ-12：UUI的接收者将能够确定插入UUI的实体。如果已知对话框中只涉及另一端UA，则可以隐式执行此操作。如果不存在，则需要提供其他一些机制。UUI机制没有为SIP引入更强的授权要求；相反，该机制需要能够利用现有的SIP方法进行请求和响应标识。
This requirement comes into play during redirection, retargeting, and referral scenarios.
这一要求在重定向、重定目标和引用场景中发挥作用。
The security requirements for the UUI mechanism are described in this section. It is important to note that UUI security is jointly provided at the application layer and at the SIP layer. As such, is important for application users of the UUI mechanism to know the level of security used and deployed in their particular SIP environments and not to assume that a standardized (but perhaps rarely deployed) security mechanism is in place.
本节描述了UUI机制的安全要求。需要注意的是，UUI安全性是在应用层和SIP层共同提供的。因此，UUI机制的应用程序用户必须了解在其特定SIP环境中使用和部署的安全级别，而不是假设标准化（但可能很少部署）安全机制已经到位。
There are three main security models that need to be addressed by the UUI mechanism. 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, the application integrity protects and/or encrypts the UUI data before passing it to the SIP layer. This method has two advantages: it does not assume or rely on end-to-end security mechanisms in SIP, which have virtually no deployment, and it allows an application that understands the contents of the UUI to apply a proper level of security.
UUI机制需要解决三个主要的安全模型。一种模型将SIP层视为不受信任的层，需要端到端完整性保护和/或加密。该模型可以通过在SIP之上的一层提供这些安全服务来实现。在这种情况下，应用程序完整性在将UUI数据传递到SIP层之前对其进行保护和/或加密。此方法有两个优点：它不假设或依赖SIP中的端到端安全机制（实际上没有部署），并且它允许理解UUI内容的应用程序应用适当的安全级别。
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.
第二种方法是应用程序在没有任何保护的情况下将UUI传递给SIP层，并要求SIP层提供这种安全性。这一方法在理论上是可行的，尽管其实际用途极为有限。
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 filtering and application of policy. This approach is used today in UUI deployments. Within this approach, there is a requirement that intermediary elements can detect and remove a UUI element based on policy, but there is no requirement that an intermediary element be able to read or interpret the UUI (as the UUI contents only have end-to-end significance).
第三个模型利用信任域并依赖于SIP层的外围安全。这是目前普遍使用UUI的PSTN和ISDN的安全模型。这种方法使用逐跳安全机制，并依赖于边界元素来过滤和应用策略。这种方法目前在UUI部署中使用。在这种方法中，要求中间元素可以基于策略检测和删除UUI元素，但不要求中间元素能够读取或解释UUI（因为UUI内容仅具有端到端的重要性）。
The next three requirements capture the UUI security requirements.
接下来的三个需求捕获UUI安全需求。
REQ-13: The mechanism will allow integrity protection of the UUI.
REQ-13：该机制将允许UUI的完整性保护。
This allows the UAS to be able to know that the UUI has not been modified or tampered with by intermediaries. Note that there are tradeoffs between this requirement and requirement REQ-9 for proxies and border elements to remove UUI. One possible way to satisfy both of these requirements is to utilize hop-by-hop protection. This property is not guaranteed by the protocol in the ISDN application.
这使UAS能够知道UUI未被中介修改或篡改。请注意，此要求与REQ-9要求之间存在折衷，即代理和边界元素需要删除UUI。满足这两个要求的一种可能方法是利用逐跳保护。ISDN应用程序中的协议不保证此属性。
REQ-14: The mechanism will allow end-to-end privacy of the UUI.
REQ-14：该机制将允许UUI的端到端隐私。
Some UUI may contain private or sensitive information and may require different security handling from the rest of the SIP message. Note that this property is not available in the ISDN application.
某些UUI可能包含私有或敏感信息，并且可能需要与SIP消息其余部分不同的安全处理。请注意，此属性在ISDN应用程序中不可用。
REQ-15: The mechanism will allow both end-to-end and hop-by-hop security models.
REQ-15：该机制将允许端到端和逐跳安全模型。
The hop-by-hop model is required by the ISDN UUI service.
ISDN UUI服务需要逐跳模式。
Thanks to Joanne McMillen, who was a co-author of earlier draft versions of this specification. Thanks to Spencer Dawkins, Keith Drage, Dale Worley, and Vijay Gurbani for their review of earlier draft versions of this document. The authors wish to thank Christer Holmberg, Frederique Forestie, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments on this topic.
感谢Joanne McMillen，她是本规范早期草案的共同作者。感谢Spencer Dawkins、Keith Drage、Dale Worley和Vijay Gurbani对本文件早期草案版本的审查。作者希望感谢克里斯特·霍姆伯格、弗雷德里克·福里斯蒂、弗朗索瓦·奥德特、丹尼斯·阿列克谢采夫、保罗·基齐瓦特、卡伦·詹宁斯和马哈林根·马尼对这一主题的评论。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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>.
[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>.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
[RFC6086]Holmberg，C.，Burger，E.，和H.Kaplan，“会话初始化协议（SIP）信息方法和包框架”，RFC 6086，2011年1月。
[Q933] ITU-T, "ISDN Digital Subscriber Signalling System No. 1 (DSS1) - Signalling specifications for frame mode switched and permanent virtual connection control and status monitoring", ITU-T Recommendation Q.933, <http://www.itu.int/rec/T-REC-Q.933/en>.
[Q933]ITU-T，“ISDN数字用户信令系统第1号（DSS1）-帧模式交换和永久虚拟连接控制和状态监测的信令规范”，ITU-T建议Q.933<http://www.itu.int/rec/T-REC-Q.933/en>.
[QSIG] ECMA, "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-BC)", Standard ECMA-143, December 2001.
[QSIG]ECMA，“专用综合业务网（PISN）-电路模式承载业务-交换间信令程序和协议（QSIG-BC）”，标准ECMA-143，2001年12月。
[ANSI] ANSI, "Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service", ANSI T1.643-1995.
[ANSI]ANSI，“电信综合业务数字网（ISDN）-显式呼叫转移补充业务”，ANSI T1.643-1995。
[ETSI] ETSI, "Integrated Services Digital Network (ISDN); Diversion supplementary services", ETSI ETS 300 207-1, Ed. 1, 1994.
[ETSI]ETSI，“综合业务数字网（ISDN）；分流补充业务”，ETSI ETS 300 207-1，第1版，1994年。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
Authors' Addresses
作者地址
Alan Johnston Avaya St. Louis, MO 63124
密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63124
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com
Laura Liess Deutsche Telekom AG
劳拉莱斯德国电信公司
EMail: laura.liess.dt@gmail.com
EMail: laura.liess.dt@gmail.com