Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 7081 Jitsi
Category: Informational P. Saint-Andre
ISSN: 2070-1721 Cisco Systems, Inc.
E. Marocco
Telecom Italia
November 2013
Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 7081 Jitsi
Category: Informational P. Saint-Andre
ISSN: 2070-1721 Cisco Systems, Inc.
E. Marocco
Telecom Italia
November 2013
CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
CUSAX：会话启动协议（SIP）和可扩展消息和状态协议（XMPP）的组合使用
Abstract
摘要
This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.
本文档建议在面向用户的客户端和部署的服务器中结合使用会话启动协议（SIP）和可扩展消息和状态协议（XMPP）的一些策略。这些策略主要包括对现有客户机和服务器的配置更改和最低限度的软件修改，旨在通过使用SIP和XMPP的补充功能子集来提供单一、全功能、实时通信服务。通常，这些子集包括来自SIP的电话功能和来自XMPP的即时消息和状态显示功能。本文档没有为SIP或XMPP定义任何新的协议或语法，无意将“最佳当前实践”标准化。相反，它的目的只是为那些对结合使用SIP和XMPP进行实时通信感兴趣的人提供实用指导。
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/rfc7081.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7081.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Client Bootstrap ................................................5
3. Operation .......................................................6
3.1. Server-Side Setup ..........................................7
3.2. Service Management .........................................7
3.3. Client-Side Discovery and Usability ........................8
3.4. Indicating a Relationship between SIP and XMPP Accounts ....9
3.5. Matching Incoming SIP Calls to XMPP JIDs ..................10
4. Multi-Party Interactions .......................................11
5. Federation .....................................................12
6. Summary of Suggested Strategies ................................13
7. Security Considerations ........................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Appendix A. Acknowledgements ......................................18
1. Introduction ....................................................2
2. Client Bootstrap ................................................5
3. Operation .......................................................6
3.1. Server-Side Setup ..........................................7
3.2. Service Management .........................................7
3.3. Client-Side Discovery and Usability ........................8
3.4. Indicating a Relationship between SIP and XMPP Accounts ....9
3.5. Matching Incoming SIP Calls to XMPP JIDs ..................10
4. Multi-Party Interactions .......................................11
5. Federation .....................................................12
6. Summary of Suggested Strategies ................................13
7. Security Considerations ........................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Appendix A. Acknowledgements ......................................18
Historically, SIP [RFC3261] and XMPP [RFC6120] have often been implemented and deployed with different purposes: from its very start, SIP's primary goal has been to provide a means of conducting "Internet telephone calls". On the other hand, XMPP has, from its Jabber days, been mostly used for instant messaging, presence [RFC6121], and related services such as groupchat rooms [XEP-0045].
从历史上看，SIP[RFC3261]和XMPP[RFC6120]的实现和部署通常有不同的目的：从一开始，SIP的主要目标就是提供一种进行“互联网电话呼叫”的方法。另一方面，XMPP从其喋喋不休的日子起，主要用于即时消息、状态[RFC6121]和相关服务，如群组聊天室[XEP-0045]。
For various reasons, these trends have continued through the years, even after each of the protocols had been equipped to provide the features it was initially lacking:
由于各种原因，这些趋势多年来一直持续，即使在每一个协议都配备了提供其最初缺乏的功能之后：
o In the context of the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) working group, the IETF has defined a number of protocols and protocol extensions that not only allow for SIP to be used for regular instant messaging and presence but that also provide mechanisms for related features such as multi-party chat, server-stored contact lists, and file transfer [RFC6914].
o 在SIP for Instant Messaging and Presence Bleeringing Extensions（SIMPLE）工作组的背景下，IETF定义了许多协议和协议扩展，这些协议和协议扩展不仅允许SIP用于常规即时消息和状态，而且还为相关功能（如多方聊天）提供机制，服务器存储的联系人列表和文件传输[RFC6914]。
o Similarly, the XMPP community and the XMPP Standards Foundation have worked on defining a number of XMPP Extension Protocols (XEPs) that provide XMPP implementations with the means of establishing end-to-end sessions. These extensions are often jointly referred to as Jingle [XEP-0166], and arguably their most popular use case is audio and video calling [XEP-0167].
o 类似地，XMPP社区和XMPP标准基金会致力于定义一些XMPP扩展协议（XEPS），这些协议提供XMPP实现，并提供建立端到端会话的方法。这些扩展通常统称为叮当[XEP-0166]，可以说它们最流行的用例是音频和视频通话[XEP-0167]。
However, although SIP has been extended for messaging and presence and XMPP has been extended for voice and video, the reality is that SIP remains the protocol of choice for telephony-like services, and XMPP remains the protocol of choice for IM and presence services. As a result, a number of adopters have found themselves needing features that are not offered by any single-protocol solution, but ones that separately exist in SIP and XMPP implementations. The idea of seamlessly using both protocols together would hence often appeal to service providers and users. Most often, such a service would employ SIP exclusively for audio, video, and telephony services and rely on XMPP for anything else varying from chat, contact-list management, and presence to whiteboarding and exchanging files. Because these services and clients involve the combined use of SIP and XMPP, we label them "CUSAX" for short.
然而，尽管SIP已扩展到消息传递和状态，XMPP已扩展到语音和视频，但现实情况是，SIP仍然是类似电话的服务的首选协议，XMPP仍然是IM和状态服务的首选协议。因此，许多采用者发现自己需要的特性不是任何单一协议解决方案提供的，而是SIP和XMPP实现中分别存在的特性。因此，无缝地同时使用这两个协议的想法通常会吸引服务提供商和用户。最常见的情况是，这样的服务将专门为音频、视频和电话服务使用SIP，并依赖XMPP来完成从聊天、联系人列表管理、状态到白板和交换文件的任何其他工作。因为这些服务和客户机涉及SIP和XMPP的组合使用，所以我们将它们简称为“CUSAX”。
+------------+ +-------------+
| SIP Server | | XMPP Server |
+------------+ +-------------+
\ /
media \ / instant messaging,
signaling \ / presence, etc.
\ /
+--------------+
| CUSAX Client |
+--------------+
+------------+ +-------------+
| SIP Server | | XMPP Server |
+------------+ +-------------+
\ /
media \ / instant messaging,
signaling \ / presence, etc.
\ /
+--------------+
| CUSAX Client |
+--------------+
Figure 1: Division of Responsibilities
图1：职责分工
This document suggests different configuration options and minimal modifications to existing software so that clients and servers can offer these hybrid services while providing an optimal user experience. It covers server discovery, determining a SIP Address of Record (AOR) while using XMPP, and determining an XMPP Jabber Identifier (JID) from incoming SIP requests. Most of the text here pertains to client behavior, but we also suggest certain server-side configurations and operational strategies. The document also discusses significant security considerations that can arise when offering a dual-protocol solution and provides advice for avoiding security mismatches that would result in degraded communications security for end users.
本文档建议对现有软件进行不同的配置选项和最小的修改，以便客户端和服务器可以提供这些混合服务，同时提供最佳的用户体验。它包括服务器发现、在使用XMPP时确定SIP记录地址（AOR）以及从传入SIP请求中确定XMPP Jabber标识符（JID）。这里的大部分内容都与客户端行为有关，但我们也建议使用某些服务器端配置和操作策略。本文件还讨论了在提供双协议解决方案时可能出现的重要安全注意事项，并提供了避免可能导致最终用户通信安全降级的安全不匹配的建议。
Note that this document is focused on coexistence of SIP and XMPP functionality in end-user-oriented clients. By intent, it does not define methods for protocol-level mapping between SIP and XMPP, as might be used within a server-side gateway between a SIP network and an XMPP network (a separate series of documents has been produced that defines such mappings). More generally, this document does not describe service policies for inter-domain communication (often called "federation") between service providers (e.g., how a service provider that offers a CUSAX service might communicate with a SIP-only or XMPP-only service), nor does it describe the reasons why a service provider might choose SIP or XMPP for various features.
请注意，本文档主要关注面向最终用户的客户端中SIP和XMPP功能的共存。出于意图，它没有定义SIP和XMPP之间协议级映射的方法，这可能在SIP网络和XMPP网络之间的服务器端网关中使用（已经生成了一系列单独的文档来定义此类映射）。更一般而言，本文档不描述服务提供商之间域间通信（通常称为“联合”）的服务策略（例如，提供CUSAX服务的服务提供商如何与仅SIP或仅XMPP服务通信），它也没有描述为什么服务提供商可能会选择SIP或XMPP来实现各种功能。
This document concentrates on use cases where the SIP services and XMPP services are controlled by one and the same provider, since that assumption greatly simplifies both client implementation and server-side deployment (e.g., a single service provider can enforce common or coordinated policies across both the SIP and XMPP aspects of a CUSAX service, which is not possible if a SIP service is offered by one provider and an XMPP service is offered by another provider). Since this document is of an informational nature, it is not unreasonable for clients to apply some of the guidelines here even in cases where there is no established relationship between the SIP and the XMPP services (for example, it is reasonable for a client to provide a way for its users to easily start a call to a phone number or SIP URI found in a vCard or obtained from a user directory). However, the strategies to pursue in such cases are left to application developers.
本文档集中讨论SIP服务和XMPP服务由同一个提供者控制的用例，因为这种假设大大简化了客户端实现和服务器端部署（例如，单个服务提供商可以在CUSAX服务的SIP和XMPP两个方面强制执行公共或协调策略，如果一个提供商提供SIP服务，而另一个提供商提供XMPP服务，则不可能执行）。由于本文件具有信息性，因此，即使在SIP和XMPP服务之间没有建立关系的情况下，客户也可以在此处应用一些指导原则（例如，客户机提供一种方式，让其用户可以轻松地拨打vCard中的电话号码或SIP URI，或从用户目录中获取的电话号码或SIP URI），这是合理的。但是，在这种情况下需要采取的策略留给了应用程序开发人员。
This document makes a further simplifying assumption by discussing only the use of a single client, not use of and coordination among multiple endpoints controlled by the same user (e.g., user agents running simultaneously on a laptop computer, tablet, and mobile phone). Although user agents running on separate endpoints might themselves be CUSAX clients or might engage in different aspects of an interaction (e.g., a user might employ her mobile phone for audio
本文档通过仅讨论单个客户端的使用，而不是同一用户控制的多个端点（例如，在笔记本电脑、平板电脑和移动电话上同时运行的用户代理）的使用和协调，进一步简化了假设。尽管在不同端点上运行的用户代理本身可能是CUSAX客户端，或者可能参与交互的不同方面（例如，用户可能使用其移动电话进行音频）
and her tablet for video and text chat), such usage complicates the guidelines for developers of user agents and therefore is left as a matter of implementation for now.
她的平板电脑（用于视频和文本聊天），这种用法使用户代理开发人员的指导方针复杂化，因此现在只剩下实现问题了。
It is important to note that this document does not attempt to standardize "best current practices" in the sense defined in the Internet Standards Process [RFC2026]. Instead, it collects together informational documentation about some strategies that might prove helpful to those who implement and deploy combined SIP/XMPP software and services. With sufficient use and appropriate modification to incorporate the lessons of experience, these strategies might someday form the basis for standardization of best current practices.
需要注意的是，本文件并未试图标准化互联网标准流程[RFC2026]中定义的“当前最佳实践”。相反，它收集了一些策略的信息文档，这些策略可能对实现和部署组合SIP/XMPP软件和服务的人有所帮助。在充分利用和适当修改以吸收经验教训的情况下，这些战略有朝一日可能会成为当前最佳做法标准化的基础。
One of the main problems of using two distinct protocols when providing one service is the impact on usability. Email services, for example, have long been affected by the mixed use of SMTP for outgoing mail and Post Office Protocol version 3 (POP3) or IMAP for incoming mail. Although standard service discovery methods (such as the proper DNS records) make it possible for a user agent to locate the right host(s) for connect purposes, they do not provide the kind of detailed information that is needed to actually configure the user agent for use with the service. As a result, it is rather complicated for inexperienced users to configure a mail client and start using it with a new service; and as a result, Internet service providers often need to provide configuration instructions for various mail clients. Client developers and communication device manufacturers, on the other hand, often ship with a number of so-called "wizard" interfaces that enable users to easily configure accounts with a number of popular email services. Although this may improve the situation to some extent, the user experience is still clearly suboptimal.
在提供一个服务时使用两个不同协议的主要问题之一是对可用性的影响。例如，电子邮件服务长期以来受到混合使用SMTP发送邮件和邮局协议版本3（POP3）或IMAP接收邮件的影响。尽管标准服务发现方法（如正确的DNS记录）使用户代理能够定位用于连接目的的正确主机，但它们不提供实际配置用户代理以用于服务所需的详细信息。因此，对于没有经验的用户来说，配置邮件客户机并开始使用新服务是相当复杂的；因此，Internet服务提供商通常需要为各种邮件客户端提供配置说明。另一方面，客户机开发人员和通信设备制造商通常附带许多所谓的“向导”界面，使用户能够轻松地使用许多流行的电子邮件服务配置帐户。虽然这在一定程度上可以改善这种情况，但用户体验显然仍不理想。
While it should be possible for CUSAX users to manually configure their separate SIP and XMPP accounts (often using "wizards"), service providers offering CUSAX services to users of dual-stack SIP/XMPP clients ought to provide methods for online provisioning, typically by means of a web-based service at an HTTPS URL (naturally, single-purpose SIP services or XMPP services could offer such methods as well, but they can be especially helpful where the two aspects of the CUSAX service need to have several configuration options in common). Although the specifics of such mechanisms are outside the scope of this document, they should make it possible for a service provider to remotely configure the clients based on minimal user input (e.g., only a user ID and password). As far as the authors are aware, no open protocol for endpoint configuration is yet available and
虽然CUSAX用户可以手动配置各自的SIP和XMPP帐户（通常使用“向导”），但向双堆栈SIP/XMPP客户端用户提供CUSAX服务的服务提供商应该提供在线资源调配方法，通常是通过HTTPS URL上的基于web的服务（当然，单用途SIP服务或XMPP服务也可以提供此类方法，但当CUSAX服务的两个方面需要有几个共同的配置选项时，它们可能特别有用）。尽管此类机制的细节不在本文档的范围内，但它们应使服务提供商能够基于最少的用户输入（例如，仅用户ID和密码）远程配置客户端。据作者所知，目前还没有用于端点配置的开放协议，并且
adopted; however, application developers are encouraged to explore the potential for future progress in this space (e.g., perhaps based on technologies such as WebFinger [RFC7033]).
采用但是，鼓励应用程序开发人员探索该领域未来发展的潜力（例如，可能基于WebFinger[RFC7033]等技术）。
By default, when a CUSAX client is used in concert with SIP and XMPP accounts that have a CUSAX relationship (see Section 3.4), the client should disable audio and video calling over XMPP and disable instant messaging and presence over SIP. (It is a matter of implementation whether a CUSAX client allows a user to override these defaults in various ways, e.g., by domain, by individual contact, or by device.) The main advantage of this approach is that a client would employ the most relevant features from both SIP and XMPP when used in the context of a CUSAX service. Note that this default configuration does not apply to stand-alone SIP accounts or XMPP accounts, for which other settings are likely to be more appropriate (see Section 3.4 for details).
默认情况下，当CUSAX客户端与具有CUSAX关系的SIP和XMPP帐户配合使用时（请参见第3.4节），客户端应禁用通过XMPP进行的音频和视频呼叫，并禁用通过SIP进行的即时消息传递和显示。（CUSAX客户端是否允许用户以各种方式（例如，通过域、个人联系人或设备）覆盖这些默认值是一个实现问题。）这种方法的主要优点是，当在CUSAX服务上下文中使用时，客户端将采用SIP和XMPP中最相关的功能。请注意，此默认配置不适用于独立SIP帐户或XMPP帐户，对于这些帐户，其他设置可能更合适（有关详细信息，请参阅第3.4节）。
Once a client has been provisioned, it needs to independently log into the SIP account and XMPP account that make up the CUSAX "service" and then maintain both connections.
一旦配置了客户端，它就需要独立地登录到组成CUSAX“服务”的SIP帐户和XMPP帐户，然后维护这两个连接。
In order to improve the user experience, when reporting connection status, a CUSAX client may wish to present the XMPP connection as an "instant messaging" or a "chat" account and the SIP connection as a "Voice and Video" or a "Telephony" connection. The exact naming is of course entirely up to implementers. The point is that, in cases where SIP and XMPP are components of a service offered by a single provider, such presentation could help users better understand why they are being shown two different connections for what they perceive as a single service (especially when one of the connections is disrupted while the other one is still active). Alternatively, the developers of a CUSAX client or the providers of a CUSAX service might decide to force a client to completely disconnect unless both aspects are successfully connected.
为了改善用户体验，当报告连接状态时，CUSAX客户端可能希望将XMPP连接呈现为“即时消息”或“聊天”帐户，并将SIP连接呈现为“语音和视频”或“电话”连接。确切的命名当然完全取决于实现者。关键是，如果SIP和XMPP是由单个提供商提供的服务的组件，那么这种演示可以帮助用户更好地理解为什么为他们认为的单个服务向他们显示两个不同的连接（特别是当一个连接中断而另一个连接仍处于活动状态时）。或者，CUSAX客户端的开发人员或CUSAX服务的提供者可能会决定强制客户端完全断开连接，除非两个方面都成功连接。
Clients may also choose to delay their XMPP connection until they have been successfully registered on SIP. This would help avoid the situation where a user appears online to her contacts but calling the user's client would fail because the user's client is still connecting to the SIP aspect of the CUSAX service.
客户机还可以选择延迟其XMPP连接，直到在SIP上成功注册。这将有助于避免出现这样的情况：用户对其联系人在线，但调用用户的客户端将失败，因为用户的客户端仍在连接到CUSAX服务的SIP方面。
Once a CUSAX client has been provisioned and authorized to connect to the corresponding SIP and XMPP services, it would proceed by retrieving its XMPP roster.
一旦CUSAX客户机被配置并授权连接到相应的SIP和XMPP服务，它将通过检索其XMPP花名册来继续。
The client should use XMPP for most forms of communication with the contacts from this roster, which will occur naturally because they were retrieved through XMPP. Audio/video features, however, would typically be disabled in the XMPP stack, so media-related communication based on these features (e.g., direct calls, conferences, desktop streaming, etc.) would happen over SIP. The rest of this section describes deployment, discovery, usability, and linking semantics that enable CUSAX clients to seamlessly use SIP for these features.
客户机应该使用XMPP与该名册中的联系人进行大多数形式的通信，这将自然发生，因为他们是通过XMPP检索的。但是，音频/视频功能通常在XMPP堆栈中被禁用，因此基于这些功能（例如，直接呼叫、会议、桌面流等）的媒体相关通信将通过SIP进行。本节的其余部分描述了部署、发现、可用性和链接语义，这些语义使CUSAX客户端能够无缝地使用SIP实现这些功能。
In order for CUSAX to function properly, XMPP service administrators should make sure that at least one of the vCard [RFC6350] "tel" fields for each contact is properly populated with a SIP URI for the user's address at the SIP audio/video service provided by the CUSAX server. There are no limitations as to the form of that number. For example, while it is desirable to maintain a certain consistency between SIP AORs and XMPP JIDs, that is by no means required. It is quite important, however, that the phone number or SIP AOR stored in the vCard be reachable through the SIP aspect of this CUSAX service. (The same considerations apply even if the directory storage format is not vCard storage over XMPP as described by [XEP-0054] or [XEP-0292].)
为了使CUSAX正常工作，XMPP服务管理员应确保每个联系人的vCard[RFC6350]“tel”字段中至少有一个正确填充了用户地址的SIP URI，地址位于CUSAX服务器提供的SIP音频/视频服务中。该数字的形式没有限制。例如，虽然希望在SIPAOR和XMPP JID之间保持一定的一致性，但这绝不是必需的。但是，通过此CUSAX服务的SIP方面可以访问vCard中存储的电话号码或SIP AOR，这一点非常重要。（即使目录存储格式不是[XEP-0054]或[XEP-0292]所述的XMPP上的vCard存储，同样的注意事项也适用。）
Administrators may also choose to include the "video" tel type defined in [RFC6350] for accounts that would be capable of handling video communication.
管理员还可以选择将[RFC6350]中定义的“视频”电话类型包括在能够处理视频通信的帐户中。
To ensure that the foregoing approach is always respected, service providers might consider validating the values of vCard "tel" fields before storing changes. Of course, such validation would be feasible only in cases where a single provider controls both the XMPP and the SIP service since such providers would "know" (e.g., based on use of a common user database for both services) what SIP AOR corresponds to a given XMPP user.
为了确保上述方法始终受到尊重，服务提供商可能会考虑在存储更改之前验证VCART“TEL”字段的值。当然，这种验证只有在单个提供商同时控制XMPP和SIP服务的情况下才可行，因为这样的提供商“知道”（例如，基于对两个服务使用公共用户数据库）什么SIP AOR对应于给定的XMPP用户。
The task of operating and managing a stand-alone SIP service or XMPP service is not always easy. Combining the two into a unified service introduces additional challenges, including:
操作和管理独立的SIP服务或XMPP服务并不总是容易的。将两者结合到一个统一的服务中会带来更多的挑战，包括：
o The necessity of opening additional ports on the client side if SIP functionality is added to an existing XMPP deployment, or vice versa.
o 如果将SIP功能添加到现有XMPP部署中，则需要在客户端打开其他端口，反之亦然。
o The potential for important differences in security posture across SIP and XMPP (e.g., SIP servers and XMPP servers might support different Transport Layer Security (TLS) ciphersuites).
o SIP和XMPP之间的安全态势可能存在重大差异（例如，SIP服务器和XMPP服务器可能支持不同的传输层安全（TLS）密码套件）。
o The need for, ideally, a common authentication backend and other infrastructure that is shared across the SIP and XMPP aspects of the combined service.
o 理想情况下，需要在组合服务的SIP和XMPP方面共享公共身份验证后端和其他基础设施。
o Coordinated monitoring and logging of the SIP and XMPP servers to enable the correlation of incidents and the pinpointing of problems.
o 协调监控和记录SIP和XMPP服务器，以实现事件关联和问题定位。
o The difficulty of troubleshooting client-side issues, e.g., if the client loses connectivity for XMPP but maintains its SIP connection.
o 排除客户端问题的困难，例如，如果客户端失去XMPP的连接，但仍保持其SIP连接。
Although separation of functionality (SIP for media and XMPP for IM and presence) can help to ease the operational burden to some extent, service providers are urged to address the foregoing challenges and similar issues when preparing to launch a CUSAX service.
尽管功能分离（SIP用于媒体，XMPP用于IM和状态）在一定程度上有助于减轻运营负担，但在准备启动CUSAX服务时，服务提供商应解决上述挑战和类似问题。
Beyond the issues listed above, service providers might want to be aware of more subtle operational issues that can arise. For example, if a service provider uses different network operators for the SIP service and the XMPP service, end-to-end connectivity might be more reliable or consistent in one service than in the other service. Similar issues can arise when the media path and the signaling path go over different networks, even in stand-alone SIP or XMPP services. Providers of CUSAX services are advised to consider the potential for such topologies to cause operational challenges.
除了上面列出的问题之外，服务提供商可能还希望了解可能出现的更微妙的操作问题。例如，如果服务提供商为SIP服务和XMPP服务使用不同的网络运营商，则一个服务中的端到端连接可能比另一个服务中的端到端连接更可靠或一致。当媒体路径和信令路径通过不同的网络时，甚至在独立的SIP或XMPP服务中，也会出现类似的问题。建议Cuxax服务的提供者考虑这样的拓扑结构可能导致操作上的挑战。
When rendering the roster for a particular XMPP account, CUSAX clients should make sure that users are presented with a "Call" option for each roster entry that has a properly set "tel" field. This is the case even if calling features have been disabled for that particular XMPP account, as advised by this document. The usefulness of such a feature is not limited to CUSAX. After all, numbers are entered in vCards or stored in directories in order to be dialed and called. Hence, as long as an XMPP client has any means of conducting a call, it may wish to make it possible for the user to easily dial any numbers that it learned through whatever means.
当呈现特定XMPP帐户的花名册时，CUSAX客户端应确保为每个花名册条目提供一个“调用”选项，该选项具有一个正确设置的“tel”字段。即使按照本文档的建议，已为特定的XMPP帐户禁用了调用功能，情况也是如此。这种特性的用途不仅限于CUSAX。毕竟，数字是输入到vCard或存储在目录中以便拨号和呼叫的。因此，只要XMPP客户机有任何方式进行呼叫，它就可能希望用户能够轻松拨打通过任何方式获知的任何号码。
Clients that have separate triggers (e.g., buttons) for audio calls and video calls may choose to use the presence or absence of the "video" tel type defined in [RFC6350] as the basis for choosing
对于音频通话和视频通话，具有单独触发器（例如按钮）的客户端可以选择是否存在[RFC6350]中定义的“视频”电话类型作为选择的基础
whether to enable or disable the possibility for starting video calls (i.e., if there is no "video" tel type for a particular contact, the client could disable the "video call" button for that contact).
是否启用或禁用启动视频通话的可能性（即，如果特定联系人没有“视频”电话类型，客户端可以禁用该联系人的“视频通话”按钮）。
In addition to discovering phone numbers from vCards or user directories, clients may also check for alternative communication methods as advertised in XMPP presence broadcasts and Personal Eventing Protocol nodes as described in "XEP-0152: Reachability Addresses" [XEP-0152]. However, these indications are merely hints, and a receiving client ought not associate a SIP address and an XMPP address unless it has some way to verify the relationship (e.g., the vCard of the XMPP account lists the SIP address and the vCard of the SIP account lists the XMPP address, or the relationship is made explicit in a record provided by a trusted directory). Alternatively, or in cases where vCard or directory data is not available, a CUSAX client could take the user's own address book as the canonical source for contact addresses.
除了从vCard或用户目录中查找电话号码外，客户机还可以检查XMPP状态广播和“XEP-0152：可达性地址”[XEP-0152]中所述的个人事件协议节点中公布的替代通信方法。然而，这些指示仅仅是提示，接收客户端不应该将SIP地址和XMPP地址关联起来，除非它有某种方法来验证这种关系（例如，XMPP帐户的vCard列出SIP地址，SIP帐户的vCard列出XMPP地址，或者在受信任目录提供的记录中明确关系）。或者，在vCard或目录数据不可用的情况下，CUSAX客户端可以将用户自己的通讯簿作为联系人地址的规范源。
In order to improve usability, in cases where clients are provisioned with only a single telephony-capable account they ought to initiate calls immediately upon user request without asking users to indicate an account that the call should go through. This way, CUSAX users (whose only account with calling capabilities is usually the SIP part of their service) would have a better experience, since from the user's perspective calls "just work at the click of a button".
为了提高可用性，如果客户端只提供了一个具有电话功能的帐户，那么他们应该在用户请求时立即发起呼叫，而不要求用户指示呼叫应通过的帐户。这样，CUSAX用户（其唯一具有呼叫功能的帐户通常是其服务的SIP部分）将有更好的体验，因为从用户的角度来看，呼叫“只需点击按钮即可工作”。
In some cases, however, clients will be configured with more than the two XMPP and SIP accounts provisioned by the CUSAX provider. Users are likely to add additional stand-alone XMPP or SIP accounts (or accounts for other communications protocols), any of which might have both telephony and instant messaging capabilities. Such situations can introduce additional ambiguity since all of the telephony-capable accounts could be used for calling the numbers the client has learned from vCards or directories.
但是，在某些情况下，客户端将配置由CUSAX提供程序提供的两个以上的XMPP和SIP帐户。用户可能会添加额外的独立XMPP或SIP帐户（或其他通信协议的帐户），其中任何帐户都可能同时具有电话和即时消息功能。这种情况可能会带来额外的歧义，因为所有支持电话的帐户都可以用于呼叫客户从vCard或目录中了解到的号码。
To avoid such confusion, client implementers and CUSAX service providers may choose to indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service. For example, let's say that Alice's service provider has opened both an XMPP account and a SIP account for her. During or after provisioning, her client could indicate that alice@xmpp.example.com has a CUSAX relationship to alice@sip.example.com (i.e., that they are two aspects of the same service). This way, whenever Alice triggers a call to a contact in her XMPP roster, the client would preferentially initiate this call through her example.com SIP account even if other possibilities exist (such as the XMPP account where the
为了避免这种混淆，客户机实现者和CUSAX服务提供者可以选择指示CUSAX服务的SIP和XMPP帐户之间存在特殊关系。例如，假设Alice的服务提供商为她同时打开了一个XMPP帐户和一个SIP帐户。在资源调配期间或之后，她的客户可能会指出alice@xmpp.example.com与客户有CUSAX关系alice@sip.example.com（即，它们是同一服务的两个方面）。这样，每当Alice触发对其XMPP花名册中联系人的呼叫时，客户机将优先通过她的example.com SIP帐户发起此呼叫，即使存在其他可能性（例如
vCard was obtained or a SIP account with another provider). Similarly, the client would preferentially initiate textual chat sessions using her XMPP account.
已获得vCard或其他提供商的SIP帐户）。类似地，客户端将优先使用她的XMPP帐户启动文本聊天会话。
If, on the other hand, no relationship has been configured or discovered between a SIP account and an XMPP account, and the client is aware of multiple telephony-capable accounts, it ought to present the user with the option of using XMPP Jingle as one method for engaging in audio and video interactions with a contact who has an XMPP address. This can help to ensure that a CUSAX user can complete audio and video calls with XMPP users who are not part of a CUSAX deployment.
另一方面，如果在SIP帐户和XMPP帐户之间没有配置或发现任何关系，并且客户端知道有多个支持电话的帐户，那么它应该向用户提供使用XMPP铃声作为与具有XMPP地址的联系人进行音频和视频交互的一种方法的选项。这有助于确保CUSAX用户可以与不属于CUSAX部署的XMPP用户完成音频和视频通话。
When receiving a SIP call, a CUSAX client may wish to determine the identity of the caller and a corresponding XMPP roster entry so that the receiving user could revert to chatting or other forms of communication that require XMPP. To do so, a CUSAX client could search the user's roster for an entry whose vCard has a "tel" field matching the originator of the call. In addition, in order to avoid the effort of iterating over the entire roster of the user and retrieving vCards for all of the user's contacts, the receiving client may guess at the identity of the caller based a SIP Call-Info header whose 'purpose' header field parameter has a value of "impp" as described in [RFC6993]. To enable this usage, a sending client would need to include such a Call-Info header in the SIP messages that it sends when initiating a call. An example follows.
当接收SIP呼叫时，CUSAX客户端可能希望确定呼叫者的身份和相应的XMPP花名册条目，以便接收用户可以恢复到聊天或需要XMPP的其他形式的通信。要做到这一点，CUSAX客户端可以在用户的名册中搜索一个条目，该条目的vCard上有一个与呼叫发起人匹配的“tel”字段。此外，为了避免迭代整个用户名册并检索用户所有联系人的vCard，接收客户端可以根据SIP呼叫信息报头猜测呼叫者的身份，其“目的”报头字段参数的值为[RFC6993]中所述的“impp”。要启用此用法，发送客户端需要在发起呼叫时发送的SIP消息中包含这样的呼叫信息头。下面是一个例子。
Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=impp
Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=impp
Note that the information from the Call-Info header should only be used as a cue: the actual AOR-to-JID binding would still need to be confirmed by the vCard of a contact in the receiving user's roster or through some other trusted means (such as an enterprise directory). If this confirmation succeeds, the client would not need to search the entire roster and retrieve all vCards. Not performing the check might enable any caller (including malicious ones) to employ someone else's identity and perform various scams or Man-in-the-Middle attacks.
请注意，来自Call Info报头的信息应仅用作提示：实际的AOR到JID绑定仍需要由接收用户名册中联系人的vCard或通过一些其他受信任的方式（如企业目录）确认。如果确认成功，客户将不需要搜索整个名册并检索所有vCard。不执行检查可能会使任何调用方（包括恶意调用方）利用其他人的身份执行各种欺诈或中间人攻击。
However, although an AOR-to-JID binding can be a helpful hint to the user, nothing in the foregoing paragraph ought to be construed as necessarily discouraging users, clients, or service providers from accepting calls originated by entities that are not established contacts of the user (e.g., as reflected in the user's roster); that is a policy matter for the user, client, or service provider.
然而，尽管AOR-to-JID绑定可以是对用户的有益提示，但上述段落中的任何内容都不应被解释为一定会阻止用户、客户或服务提供商接受非用户联系人实体发起的呼叫（例如，如用户名册中反映的）；这是用户、客户机或服务提供商的策略问题。
It is also worth noting that callers preferring to remain anonymous as per [RFC3325] would not provide Call-Info information.
还值得注意的是，根据[RFC3325]的规定，愿意保持匿名的呼叫者不会提供呼叫信息。
CUSAX clients that support the SIP conferencing framework [RFC4353] can detect when a call they are participating in is actually a conference and can then subscribe to conference state updates as per [RFC4575]. A regular SIP user agent might also use the same conference URI for text communication with the Message Session Relay Protocol (MSRP). However, given that SIP's instant messaging capabilities would normally be disabled (or simply not supported) in CUSAX deployments, an XMPP Multi-User Chat (MUC) room [XEP-0045] associated with the conference can be announced/discovered through <service-uris> bearing the "grouptextchat" purpose [GROUPTEXTCHAT]. Similarly, an XMPP MUC room can advertise the SIP URI of an associated service for audio/video interactions using the 'audio-video-uri' field of the "muc#roominfo" data form [XEP-0004] to include extended information [XEP-0128] about the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] for an example. These methods would enable a CUSAX-aware SIP conference server to advertise the existence of an associated XMPP chat room and for a CUSAX-aware XMPP chat room to advertise the existence of an associated SIP conference server.
支持SIP会议框架[RFC4353]的CUSAX客户端可以检测到他们正在参与的呼叫何时实际上是一个会议，然后可以根据[RFC4575]订阅会议状态更新。常规SIP用户代理也可以使用相同的会议URI与消息会话中继协议（MSRP）进行文本通信。但是，考虑到在CUSAX部署中SIP的即时消息功能通常会被禁用（或根本不受支持），与会议相关联的XMPP多用户聊天室[XEP-0045]可以通过带有“grouptextchat”目的[grouptextchat]的<service URI>来宣布/发现。类似地，XMPP MUC室可以使用“MUC#roominfo”数据表单[XEP-0004]的“音频视频URI”字段，在XMPP服务发现[XEP-0030]中包含关于MUC室的扩展信息[XEP-0128]，为音频/视频交互发布关联服务的SIP URI；有关示例，请参见[XEP-0045]。这些方法将使具有CUSAX意识的SIP会议服务器能够通告关联的XMPP聊天室的存在，并使具有CUSAX意识的XMPP聊天室能够通告关联的SIP会议服务器的存在。
If a CUSAX client joins the MUC room associated with a particular call, it should not rely on any synchronization between the two. Both the SIP conference and the XMPP MUC room would function independently, each issuing and delivering its own state updates. Hence, it is possible that certain peers would temporarily or permanently be reachable in only one of the two conferences. This would typically be the case with single-stack clients that have only joined the SIP call or the XMPP MUC room. It is therefore important for CUSAX clients to provide a clear indication to users as to the level of involvement of the various participants: i.e., a user needs to be able to easily understand whether a certain participant can receive text messages, audio/video, or both.
如果CUSAX客户端加入与特定调用关联的MUC室，则不应依赖于两者之间的任何同步。SIP会议室和XMPP MUC会议室都将独立运行，各自发布和交付自己的状态更新。因此，有可能在两次会议中的一次会议上临时或永久地联系到某些对等方。对于仅加入SIP调用或XMPP MUC室的单堆栈客户端，通常会出现这种情况。因此，对于CUSAX客户端来说，向用户提供关于各种参与者参与程度的明确指示是很重要的：即，用户需要能够轻松理解某个参与者是否可以接收文本消息、音频/视频或两者。
At the level of the CUSAX service, it is also possible to enforce tighter integration between the XMPP MUC room and the SIP conference. Permissions, roles, kicks, and bans that are granted and performed in the MUC room can easily be imitated by the conference focus/mixer into the SIP call. If, for example, a certain MUC member is muted, the conference mixer can choose to also apply the mute on the media stream corresponding to that participant. However, the details and exact level of such integration are entirely up to implementers and service providers.
在CUSAX服务级别，还可以在XMPP MUC室和SIP会议室之间实施更紧密的集成。在MUC会议室中授予和执行的权限、角色、踢击和禁止可以很容易地被会议焦点/混音器模仿到SIP呼叫中。例如，如果某个MUC成员被静音，则会议混合器可以选择也对对应于该参与者的媒体流应用静音。然而，这种集成的细节和确切级别完全取决于实现者和服务提供者。
The approach above describes one relatively lightweight possibility of combining SIP and XMPP multi-party interaction semantics without requiring tight integration between the two. As with the rest of this document, this approach is by no means normative. Implementations and future documents may define other methods or provide other suggestions for improving the unified communications user experience in cases of multi-user chats and conference calling.
上述方法描述了一种相对轻量级的可能性，即结合SIP和XMPP多方交互语义，而不需要两者之间的紧密集成。与本文件其余部分一样，这种方法绝不是规范性的。在多用户聊天和电话会议的情况下，实现和未来的文档可能会定义其他方法或提供其他建议来改进统一通信用户体验。
In theory, there are no technical reasons why federation (i.e., inter-domain communication) would require special behavior from CUSAX clients. However, it is worth noting that differences in administration policies may sometimes lead to potentially confusing user experiences.
从理论上讲，联邦（即域间通信）需要CUSAX客户端的特殊行为并没有任何技术原因。但是，值得注意的是，管理策略的差异有时可能会导致潜在的用户体验混乱。
For example, let's say atlanta.example.com observes the CUSAX policies described in this document. All XMPP users at atlanta.example.com are hence configured to have vCards that match their SIP identities. Alice is therefore used to making free, high-quality SIP calls to all the people in her roster. Alice can also make calls to the Public Switched Telephone Network (PSTN) by simply dialing numbers. She may even be used to these calls being billed to her online account, so she would be careful about how long they last. This is not a problem for her since she can easily distinguish between a free SIP call (one that she made by calling one of her roster entries) from a paid PSTN call that she dialed as a number.
例如，假设atlanta.example.com遵守本文档中描述的CUSAX策略。因此，atlanta.example.com上的所有XMPP用户都配置有与其SIP身份匹配的vCard。因此，Alice习惯于向她的花名册中的所有人拨打免费、高质量的SIP电话。Alice还可以通过拨打电话号码拨打公共交换电话网（PSTN）。她甚至可能习惯于将这些电话计费到自己的在线账户，因此她会注意这些电话的通话时间。这对她来说不是一个问题，因为她可以很容易地区分免费SIP呼叫（她通过拨打她的一个花名册条目进行的呼叫）和作为号码拨打的付费PSTN呼叫。
Then, Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only has an XMPP service. There is no SIP server and Bob uses an XMPP-only client. However, Bob has added his mobile number to his vCard in order to make it easily accessible to his contacts. Alice's client would pick up this number and make it possible for Alice to start a call to Bob's mobile phone number.
然后，Alice添加了xmpp：bob@biloxi.example.com. Biloxi域只有一个XMPP服务。没有SIP服务器，Bob只使用XMPP客户端。然而，Bob已经将他的手机号码添加到他的vCard中，以便他的联系人能够轻松访问。Alice的客户会拿起这个号码，让Alice可以拨打Bob的手机号码。
This could be a problem because, other than the fact that Bob's address is from a different domain, Alice would have no obvious and straightforward cues telling her that this is in fact a call to the PSTN. In addition to the potentially lower audio quality, Alice may also end up incurring unexpected charges for such calls.
这可能是一个问题，因为除了Bob的地址来自不同的域之外，Alice没有明显而直接的线索告诉她这实际上是一个PSTN呼叫。除了潜在的较低的音频质量外，Alice还可能因此类通话而招致意外费用。
In order to avoid such issues, providers maintaining a CUSAX service for the users in their domain may choose to provide additional cues (e.g., a service-generated signal that triggers a user-interface warning in a CUSAX client, an auditory tone, or a spoken message) indicating that a call would incur unexpected charges.
为了避免此类问题，为其域中的用户维护CUSAX服务的提供商可以选择提供额外提示（例如，触发CUSAX客户端中的用户界面警告的服务生成信号、听觉音调或语音消息），指示呼叫将招致意外费用。
Another scenario arises when a SIP service allows communication only with intra-domain numbers; here, Alice might be prevented from establishing a call with Bob's mobile phone. Providers should therefore make sure that calls to inter-domain numbers are flagged with an appropriate audio or textual warning.
当SIP服务仅允许与域内号码通信时，出现另一种情况；在这里，可能会阻止Alice用Bob的手机拨打电话。因此，提供商应确保对域间号码的呼叫标记有适当的音频或文本警告。
The following strategies are suggested for CUSAX user agents:
建议CUSAX用户代理采用以下策略：
1. By default, prefer SIP for audio and video and XMPP for messaging and presence.
1. 默认情况下，音频和视频首选SIP，消息和状态首选XMPP。
2. Use XMPP for all forms of communication with the contacts from the XMPP roster, with the exception of features that are based on establishing real-time sessions (e.g., audio/video calls) for which SIP should be used.
2. 使用XMPP与XMPP名册中的联系人进行所有形式的通信，但基于建立实时会话（例如音频/视频通话）的功能除外，应使用SIP。
3. Provide online provisioning options for providers to remotely set up SIP and XMPP accounts so that users wouldn't need to go through a multi-step configuration process.
3. 为提供商提供在线资源调配选项，以远程设置SIP和XMPP帐户，这样用户就不需要经历多步骤配置过程。
4. Provide online provisioning options for providers to completely disable features for an account associated with a given protocol (SIP or XMPP) if the features are preferred in another protocol (XMPP or SIP).
4. 如果在另一个协议（XMPP或SIP）中首选与给定协议（SIP或XMPP）关联的帐户的功能，则为提供商提供在线资源调配选项，以完全禁用这些功能。
5. Present a "Call" option for each roster entry that has a properly set "tel" field in the vCard or equivalent.
5. 为每个名册条目提供一个“呼叫”选项，该名册条目在vCard或同等文件中有一个正确设置的“电话”字段。
6. If the client is provisioned with only a single telephony-capable account, initiate calls immediately upon user request without asking users to indicate an account that the call should go through.
6. 如果客户端仅配置了一个支持电话功能的帐户，则在用户请求时立即启动呼叫，而不要求用户指示呼叫应通过的帐户。
7. If no relationship has been configured or discovered between a SIP account and an XMPP account, and the client is aware of multiple telephony-capable accounts, present the user with the choice of reaching the contact through any of those accounts.
7. 如果没有在SIP帐户和XMPP帐户之间配置或发现任何关系，并且客户端知道有多个支持电话的帐户，则向用户提供通过这些帐户中的任何一个联系联系人的选择。
8. If known, indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service.
8. 如果已知，则表明CUSAX服务的SIP和XMPP帐户之间存在特殊关系。
9. Optionally, present the XMPP connection as an "instant messaging" or a "chat" account and the SIP connection as a "Voice and Video" or a "Telephony" account.
9. 可选地，将XMPP连接显示为“即时消息”或“聊天”帐户，将SIP连接显示为“语音和视频”或“电话”帐户。
10. Optionally, determine the identity of the audio/video caller and a corresponding XMPP roster entry so that the user could use textual chatting or other forms of communication that require XMPP.
10. 可选地，确定音频/视频呼叫方的身份和相应的XMPP花名册条目，以便用户可以使用文本聊天或其他需要XMPP的通信形式。
11. Optionally, delay the XMPP connection until after a SIP connection has been successfully registered.
11. （可选）延迟XMPP连接，直到成功注册SIP连接。
12. Optionally, check for alternative communication methods (SIP addresses advertised over XMPP and XMPP addresses advertised over SIP).
12. 或者，检查其他通信方法（通过XMPP公布的SIP地址和通过SIP公布的XMPP地址）。
The following strategies are suggested for CUSAX services:
针对CUSAX服务建议以下策略：
1. Use online provisioning and configuration of accounts so that users won't need to set up two separate accounts for the CUSAX service.
1. 使用在线资源调配和帐户配置，这样用户就不需要为CUSAX服务设置两个单独的帐户。
2. Use online provisioning so that calling features are disabled for all XMPP accounts.
2. 使用联机资源调配，以便对所有XMPP帐户禁用调用功能。
3. Ensure that at least one of the vCard "tel" fields for each XMPP user is properly populated with a SIP URI that is reachable through the SIP service.
3. 确保每个XMPP用户的vCard“tel”字段中至少有一个正确填充了可通过SIP服务访问的SIP URI。
4. Optionally, include the "video" tel type for accounts that are capable of handling video communication.
4. 可选地，为能够处理视频通信的帐户包括“视频”电话类型。
5. Optionally, provision clients with information indicating that specific SIP and XMPP accounts are related in a CUSAX service.
5. 或者，为客户端提供指示特定SIP和XMPP帐户在CUSAX服务中相关的信息。
6. Optionally, attach a "Call-Info" header with an "impp" purpose to all SIP INVITE messages, so that clients can more rapidly associate a caller with a roster entry and display a "Caller ID".
6. 可选地，将带有“impp”目的的“Call Info”头附加到所有SIP INVITE消息，以便客户端可以更快速地将呼叫者与花名册条目关联并显示“呼叫者ID”。
Use of the same user agent with two different accounts providing complementary features introduces the possibility of mismatches between the security profiles of those accounts or features. Two security mismatches of particular concern are:
将同一用户代理与提供互补功能的两个不同帐户一起使用，可能会导致这些帐户或功能的安全配置文件不匹配。特别令人关注的两个安全不匹配是：
o The SIP aspect and XMPP aspect of a CUSAX service might offer different authentication options (e.g., digest authentication for SIP as specified in [RFC3261] and Salted Challenge Response Authentication Mechanism (SCRAM) authentication [RFC5802] for XMPP as specified in [RFC6120]). Because SIP uses a password-based method (digest) and XMPP uses a pluggable framework for
o CUSAX服务的SIP方面和XMPP方面可能提供不同的身份验证选项（例如，[RFC3261]中规定的SIP摘要身份验证和[RFC6120]中规定的XMPP盐质询响应身份验证机制（SCRAM）身份验证[RFC5802]）。因为SIP使用基于密码的方法（摘要），而XMPP使用可插拔的框架来
authentication via the Simple Authentication and Security Layer (SASL) technology [RFC4422], it is also possible that the XMPP connection could be authenticated using a password-free method such as client certificates with SASL EXTERNAL, even though a username and password is used for the SIP connection.
通过简单身份验证和安全层（SASL）技术进行身份验证[RFC4422]，XMPP连接也可以使用无密码方法进行身份验证，例如使用SASL外部客户端证书，即使SIP连接使用用户名和密码。
o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered or negotiated on the XMPP side might be different from those on the SIP side because of implementation or configuration differences between the SIP server and the XMPP server. Even more seriously, a CUSAX client might successfully negotiate TLS when connecting to the XMPP aspect of the service but not when connecting to the SIP aspect, or vice versa. In this situation, an end user might think that the combined CUSAX session with the service is protected by TLS, even though only one aspect is protected.
o 由于SIP服务器和XMPP服务器之间的实现或配置差异，XMPP端提供或协商的传输层安全性（TLS）[RFC5246]密码套件可能与SIP端不同。更严重的是，CUSAX客户端在连接到服务的XMPP方面时可能会成功协商TLS，但在连接到SIP方面时可能不会，反之亦然。在这种情况下，最终用户可能会认为与服务组合的CUSAX会话受TLS保护，即使只有一个方面受到保护。
Security mismatches such as these (as well as others related to end-to-end encryption of messages or media) introduce the possibility of downgrade attacks, eavesdropping, information leakage, and other security vulnerabilities. User agent developers and service providers must ensure that such mismatches are avoided as much as possible (e.g., by enforcing common and strong security configurations and policies across protocols). Specifically, if both protocols are not safeguarded by similar levels of cryptographic protection, the user must be informed of that fact and given the opportunity to bring both up to the same level.
此类安全不匹配（以及与消息或媒体的端到端加密相关的其他安全不匹配）会导致降级攻击、窃听、信息泄漏和其他安全漏洞。用户代理开发人员和服务提供商必须确保尽可能避免此类不匹配（例如，通过跨协议强制实施通用和强大的安全配置和策略）。具体地说，如果两个协议都没有受到类似级别的加密保护，则必须通知用户这一事实，并给用户机会将两个协议提升到相同级别。
Section 5 discusses potential issues that may arise due to a mismatch between client capabilities, such as calls being initiated with costs that are not expected by the end user. Such issues could be triggered maliciously, as well as by accident. Implementers therefore need to provide necessary cues to raise user awareness as suggested in Section 5.
第5节讨论了由于客户机功能之间的不匹配而可能出现的潜在问题，例如使用最终用户不期望的成本发起呼叫。这些问题可能是恶意触发的，也可能是偶然触发的。因此，实施者需要提供必要的提示，以提高用户意识，如第5节所述。
Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client.
有关适用于CUSAX客户端中每个“堆栈”的详细安全注意事项，请参阅相关SIP和XMPP功能的规范。
[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月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121]圣安德烈，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC61212011年3月。
[GROUPTEXTCHAT] Ivov, E., "A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State", Work in Progress, June 2013.
[GROUPTEXTCHAT]Ivov，E.，“会议状态会话启动协议（SIP）事件包中用于会议和服务URI的组文本聊天”，正在进行的工作，2013年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5802]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，2010年7月。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350]Perreault，S.，“vCard格式规范”，RFC 63502011年8月。
[RFC6914] Rosenberg, J., "SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)", RFC 6914, April 2013.
[RFC6914]Rosenberg，J.“简单变得简单：使用会话启动协议（SIP）的即时消息和状态的IETF规范概述”，RFC 6914，2013年4月。
[RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", RFC 6993, July 2013.
[RFC6993]Saint Andre，P.，“会话启动协议（SIP）中呼叫信息报头字段的即时消息和存在目的”，RFC 6993，2013年7月。
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, September 2013.
[RFC7033]Jones，P.，Salgueiro，G.，Jones，M.，和J.Smarr，“网络手指”，RFC 70332013年9月。
[XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
[XEP-0004]Eatmon，R.，Hildebrand，J.，Miller，J.，Muldowney，T.，和P.Saint Andre，“数据表格”，XSF XEP 0004，2007年8月。
[XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, June 2008.
[XEP-0030]Hildebrand，J.，Millard，P.，Eatmon，R.，和P.Saint Andre，“服务发现”，XSF XEP 0030，2008年6月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452012年2月。
[XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008.
[XEP-0054]圣安德烈，P.，“vcard temp”，XSF XEP 0054，2008年7月。
[XEP-0128] Saint-Andre, P., "Service Discovery Extensions", XSF XEP 0128, October 2004.
[XEP-0128]圣安德烈，P.，“服务发现扩展”，XSF XEP 0128，2004年10月。
[XEP-0152] Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability Addresses", XEP XEP-0152, September 2013.
[XEP-0152]Hildebrand，J.和P.Saint Andre，“XEP-0152：可达性地址”，XEP XEP-0152，2013年9月。
[XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 2009.
[XEP-0166]路德维希，S.，贝达，J.，圣安德烈，P.，麦昆，R.，伊根，S.，和J.希尔德布兰德，“叮当声”，XSF XEP 0166，2009年12月。
[XEP-0167] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, December 2009.
[XEP-0167]路德维希，S.，圣安德烈，P.，伊根，S.，麦昆，R.，和D.乔努，“叮当声RTP会议”，XSF XEP 0167，2009年12月。
[XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 0292, September 2013.
[XEP-0292]Saint Andre，P.和S.Mizzi，“XMPP上的vCard4”，XSF XEP 0292，2013年9月。
This document is inspired by the "SIXPAC" work of Markus Isomaki and Simo Veikkolainen. Markus also provided various suggestions for improving the document.
本文件的灵感来源于Markus Isomaki和Simo Veikkolainen的“SIXPAC”作品。Markus还为改进该文件提供了各种建议。
The authors would also like to thank the following people for their reviews and suggestions: Sebastien Couture, Dan-Christian Bogos, Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy, Spencer MacDonald, Murray Mar, Daniel Pocock, Travis Reitter, and Gonzalo Salgueiro.
作者还想感谢以下人士的评论和建议：塞巴斯蒂安·库图尔、丹·克里斯蒂安·博格斯、理查德·布雷迪、奥利弗·克里特、艾伦·埃文斯、凯文·加拉赫、阿德里安·乔治斯库、索尔·伊巴拉·科雷奇、大卫·拉班、格格利·卢卡西、斯宾塞·麦克唐纳、莫里·马尔、丹尼尔·波科克、特拉维斯·雷特和冈萨洛·萨尔盖罗。
Brian Carpenter, Ted Hardie, Paul Hoffman, and Benson Schliesser reviewed the document on behalf of the General Area Review Team, the Applications Area Directorate, the Security Directorate, and the Operations and Management Directorate, respectively.
Brian Carpenter、Ted Hardie、Paul Hoffman和Benson Schliesser分别代表一般区域审查小组、应用区域董事会、安全董事会和运营管理董事会审查了该文件。
Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and substantive feedback during IESG review.
Benoit Claise、Barry Leiba和Pete Resnick在IESG审查期间提供了有用的实质性反馈。
The document shepherd was Mary Barnes. The sponsoring Area Director was Gonzalo Camarillo.
文件管理员是玛丽·巴恩斯。赞助区域主任是冈萨罗·卡马里洛。
Authors' Addresses
作者地址
Emil Ivov Jitsi Strasbourg 67000 France
埃米尔·伊沃夫·吉茨·斯特拉斯堡67000法国
Phone: +33-177-624-330
EMail: emcho@jitsi.org
Phone: +33-177-624-330
EMail: emcho@jitsi.org
Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA
Peter Saint Andre Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy
Enrico Marocco Telecom Italia Via G.Reiss Romoli，274意大利都灵10148
EMail: enrico.marocco@telecomitalia.it
EMail: enrico.marocco@telecomitalia.it