[要約] RFC 7081は、SIPとXMPPの組み合わせに関するガイドラインです。このRFCの目的は、SIPとXMPPを組み合わせて効果的に通信を行うための方法を提供することです。
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：Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（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.
このドキュメントでは、ユーザー指向のクライアントと展開されたサーバーの両方で、Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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は、Jabber時代から、インスタントメッセージング、プレゼンス[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 Leveraging 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実装に提供する多数のXMPP拡張プロトコル（XEP）の定義に取り組んできました。これらの拡張機能は、しばしばJingle [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 |
+--------------+
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ジャバー識別子（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サービスが1つの同じプロバイダーによって制御されるユースケースに焦点を当てています。これは、この仮定により、クライアントの実装とサーバー側の展開の両方が大幅に簡略化されるためです（たとえば、単一のサービスプロバイダーが両方に共通または調整されたポリシーを適用できるため） CUSAXサービスのSIPおよびXMPPの側面。これは、SIPサービスが1つのプロバイダーによって提供され、XMPPサービスが別のプロバイダーによって提供される場合は不可能です）。このドキュメントは情報を提供するものであるため、SIPとXMPPサービスの間に確立された関係がない場合でも、クライアントがここにガイドラインの一部を適用することは不合理ではありません（たとえば、クライアントがユーザーがvCardにある、またはユーザーディレクトリから取得した電話番号または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 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.
このドキュメントでは、同じユーザーが制御する複数のエンドポイント（ラップトップコンピューター、タブレット、携帯電話で同時に実行されているユーザーエージェントなど）の使用と調整についてではなく、単一のクライアントの使用についてのみ説明することで、さらに単純化した仮定を行います。個別のエンドポイントで実行されているユーザーエージェントは、それ自体がCUSAXクライアントであるか、インタラクションのさまざまな側面に従事している可能性があります（たとえば、ユーザーはオーディオに携帯電話を使用し、ビデオとテキストチャットにタブレットを使用する場合があります）。ユーザーエージェントの数、したがって、今のところ実装の問題として残されています。
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.
1つのサービスを提供するときに2つの異なるプロトコルを使用する場合の主な問題の1つは、ユーザビリティへの影響です。たとえば、電子メールサービスは、送信メールにSMTPを使用し、受信メールにPost Office Protocolバージョン3（POP3）またはIMAPを使用することで長い間影響を受けてきました。標準のサービス検出方法（適切なDNSレコードなど）により、ユーザーエージェントは接続のために適切なホストを見つけることができますが、ユーザーエージェントを実際に構成するために必要な種類の詳細情報は提供されませんサービスで使用します。その結果、経験の浅いユーザーがメールクライアントを構成して新しいサービスで使い始めるのはかなり複雑です。その結果、インターネットサービスプロバイダーは多くの場合、さまざまなメールクライアントに構成手順を提供する必要があります。一方、クライアント開発者や通信デバイスメーカーは、多くのいわゆる「ウィザード」インターフェースを同梱しており、ユーザーは多くの一般的なメールサービスでアカウントを簡単に設定できます。これにより、状況はある程度改善される可能性がありますが、ユーザーエクスペリエンスは依然として明らかに最適ではありません。
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 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]).
CUSAXユーザーが個別のSIPおよびXMPPアカウントを手動で構成することは可能ですが（多くの場合「ウィザード」を使用）、デュアルスタックSIP / XMPPクライアントのユーザーにCUSAXサービスを提供するサービスプロバイダーは、通常、オンラインプロビジョニングの方法を提供する必要がありますHTTPS URLでのWebベースのサービスの手段（当然、単一目的のSIPサービスまたはXMPPサービスもそのようなメソッドを提供できますが、CUSAXサービスの2つの側面にいくつかの構成オプションが必要な場合に特に役立ちます。一般）。このようなメカニズムの詳細はこのドキュメントの範囲外ですが、サービスプロバイダーが最小限のユーザー入力（たとえば、ユーザーIDとパスワードのみ）に基づいてリモートでクライアントを構成できるようにする必要があります。著者が知る限り、エンドポイント構成用のオープンプロトコルはまだ利用可能で採用されていません。ただし、アプリケーション開発者は、この分野における将来の進歩の可能性を探ることをお勧めします（たとえば、おそらく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関係（セクション3.4を参照）を持つSIPおよびXMPPアカウントと連携して使用される場合、クライアントは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が単一のプロバイダーによって提供されるサービスのコンポーネントである場合、そのような表示は、単一のサービスとして認識されるものに対して2つの異なる接続が表示される理由をユーザーがよりよく理解するのに役立ちます（特に、他の接続がまだアクティブである間、接続は中断されます。または、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.
クライアントは、SIPに正常に登録されるまでXMPP接続を遅らせることもできます。これにより、ユーザーがオンラインで連絡先に表示されても、ユーザーのクライアントが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」フィールドの少なくとも1つに、提供されたSIPオーディオ/ビデオサービスでユーザーのアドレスのSIP URIが適切に入力されていることを確認する必要があります。 CUSAXサーバーによって。その数の形式に関して制限はありません。たとえば、SIP AORとXMPP JIDの間で一定の一貫性を維持することが望ましいのですが、これは決して必要なことではありません。ただし、vCardに格納されている電話番号またはSIP AORが、このCUSAXサービスのSIPアスペクトを介して到達可能であることが非常に重要です。 （[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]で定義されている「ビデオ」telタイプを、ビデオ通信を処理できるアカウントに含めることもできます。
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.
前述のアプローチが常に尊重されるようにするために、サービスプロバイダーは、変更を保存する前にvCardの「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サービスを操作および管理する作業は、必ずしも容易ではありません。 2つを1つの統合サービスに結合すると、次のような課題が発生します。
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、IMとプレゼンスの場合はXMPP）は、運用上の負担をある程度軽減するのに役立ちますが、サービスプロバイダーは、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サービスに異なるネットワークオペレーターを使用している場合、エンドツーエンド接続は、他のサービスよりも1つのサービスの方が信頼性が高く、一貫性があります。スタンドアロンのSIPまたはXMPPサービスであっても、メディアパスとシグナリングパスが異なるネットワークを経由する場合、同様の問題が発生する可能性があります。 CUSAXサービスのプロバイダーは、このようなトポロジが運用上の課題を引き起こす可能性を検討することをお勧めします。
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」フィールドを持つ各名簿エントリの「Call」オプションがユーザーに表示されることを確認する必要があります。これは、このドキュメントで推奨されているように、特定の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 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).
オーディオコールとビデオコールに別々のトリガー（ボタンなど）があるクライアントは、[RFC6350]で定義されている「ビデオ」電話タイプの有無を、開始の可能性を有効にするか無効にするかを選択する基準として使用することを選択できます。ビデオ通話（つまり、特定の連絡先に「ビデオ」電話タイプがない場合、クライアントはその連絡先の「ビデオ通話」ボタンを無効にすることができます）。
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.
「XEP-0152：到達可能性アドレス」[XEP-0152]で説明されているように、クライアントはvCardまたはユーザーディレクトリから電話番号を検出するだけでなく、XMPPプレゼンスブロードキャストおよびPersonal Eventing Protocolノードでアドバタイズされる代替通信方法をチェックすることもできます。ただし、これらの表示は単なるヒントであり、関係を確認する何らかの方法がない限り、受信側クライアントは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プロバイダーによってプロビジョニングされた3つ以上の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 vCard was obtained or a SIP account with another provider). Similarly, the client would preferentially initiate textual chat sessions using her XMPP account.
このような混乱を避けるために、クライアントの実装者とCUSAXサービスプロバイダーは、CUSAXサービスのSIPアカウントとXMPPアカウントの間に特別な関係があることを示すことを選択できます。たとえば、アリスのサービスプロバイダーが彼女のXMPPアカウントとSIPアカウントの両方を開設したとします。プロビジョニング中またはプロビジョニング後に、クライアントはalice@xmpp.example.comがalice@sip.example.comとのCUSAX関係を持っていることを示す可能性があります（つまり、これらは同じサービスの2つの側面であることを意味します）。このように、アリスがXMPP名簿の連絡先への呼び出しをトリガーするときはいつでも、クライアントは他の可能性が存在する場合でも（vCardが取得されたXMPPアカウントやSIPアカウントなど）、優先的に彼女のexample.com 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ジングルを1つとして使用するオプションをユーザーに提示する必要があります。 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クライアントは、発信者のIDと対応するXMPP名簿エントリを確認して、受信ユーザーがチャットまたはXMPPを必要とする他の形式の通信に戻れるようにする場合があります。これを行うには、CUSAXクライアントは、vCardに通話の発信者と一致する「tel」フィールドがあるエントリをユーザーの名簿から検索します。さらに、ユーザーの名簿全体を反復して、ユーザーのすべての連絡先のvCardを取得する手間を省くために、受信側クライアントは、「目的」のSIP Call-Infoヘッダーに基づいて発信者のIDを推測する場合があります。 [RFC6993]で説明されているように、ヘッダーフィールドパラメータの値は「impp」です。この使用法を有効にするには、送信側クライアントは、通話を開始するときに送信するSIPメッセージにそのようなCall-Infoヘッダーを含める必要があります。以下に例を示します。
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を取得する必要はありません。チェックを実行しないと、発信者（悪意のあるものを含む）が他の誰かのIDを使用して、さまざまな詐欺や中間者攻撃を実行できる可能性があります。
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からJIDへのバインドはユーザーにとって役立つヒントになる可能性がありますが、前述の段落のいずれも、ユーザー、クライアント、またはサービスプロバイダーが連絡先の確立されていないエンティティから発信された呼び出しを受け入れることを必ずしも阻止するものではありません。ユーザー（たとえば、ユーザーの名簿に反映されている）。これは、ユーザー、クライアント、またはサービスプロバイダーのポリシーの問題です。
It is also worth noting that callers preferring to remain anonymous as per [RFC3325] would not provide Call-Info information.
[RFC3325]のように匿名のままにすることを好む発信者はCall-Info情報を提供しないことにも注意する価値があります。
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ユーザーエージェントも、メッセージセッションリレープロトコル（MSRP）とのテキスト通信に同じ会議URIを使用する場合があります。ただし、CUSAX展開では通常SIPのインスタントメッセージング機能が無効になる（または単にサポートされない）ため、会議に関連付けられたXMPPマルチユーザーチャット（MUC）ルーム[XEP-0045]は、<service- uris>「grouptextchat」の目的[GROUPTEXTCHAT]。同様に、XMPP MUCルームは、「muc＃roominfo」データフォームの「audio-video-uri」フィールド[XEP-0004]を使用して、オーディオ/ビデオインタラクションの関連サービスのSIP URIをアドバタイズし、拡張情報[XEP -0128] XMPPサービス検出[XEP-0030]内のMUCルームについて;例については、[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ルームに参加する場合、2つの間の同期に依存するべきではありません。 SIP会議とXMPP MUCルームの両方が独立して機能し、それぞれが独自の状態更新を発行および配信します。したがって、特定のピアが2つの会議のうちの1つだけで一時的または永続的に到達可能である可能性があります。これは通常、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のマルチパーティ相互作用セマンティクスを2つを緊密に統合することなく組み合わせるという比較的軽量な可能性について説明しています。このドキュメントの他の部分と同様に、このアプローチは決して規範的ではありません。実装と将来のドキュメントは、他の方法を定義したり、マルチユーザーチャットや電話会議の場合にユニファイドコミュニケーションのユーザーエクスペリエンスを改善するための他の提案を提供したりすることがあります。
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 IDと一致するvCardを持つように構成されています。したがって、アリスは、名簿に登録されているすべての人々に無料で高品質のSIP通話を発信することに慣れています。アリスは、番号をダイヤルするだけで公衆交換電話網（PSTN）に電話をかけることもできます。彼女は、オンラインアカウントに請求されるこれらの通話に慣れている可能性があるため、通話時間の長さに注意する必要があります。彼女は、無料のSIPコール（名簿エントリの1つを呼び出すことによって行われたもの）と番号としてダイヤルした有料の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.
次に、アリスはxmpp：bob@biloxi.example.comを追加します。 BiloxiドメインにはXMPPサービスのみがあります。 SIPサーバーはなく、ボブはXMPPのみのクライアントを使用しています。ただし、ボブは連絡先が簡単にアクセスできるように、vCardに携帯電話番号を追加しました。アリスのクライアントはこの番号を取得し、アリスがボブの携帯電話番号への通話を開始できるようにします。
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.
これは問題になる可能性があります。ボブのアドレスが別のドメインからのものであるという事実を除いて、アリスはこれが実際にはPSTNへの呼び出しであることを彼女に告げる明白で簡単な手掛かりを持っていないからです。音声品質が低下する可能性があることに加えて、アリスはこのような通話に対して予期しない料金を請求することになる場合もあります。
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サービスがドメイン内番号のみとの通信を許可する場合、別のシナリオが発生します。ここでは、アリスがボブの携帯電話との通話を確立できない場合があります。したがって、プロバイダーは、ドメイン間番号への呼び出しに、適切な音声またはテキストによる警告のフラグが立てられていることを確認する必要があります。
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. SIPを使用する必要があるリアルタイムセッション（オーディオ/ビデオコールなど）の確立に基づく機能を除いて、XMPP名簿の連絡先とのすべての形式の通信にXMPPを使用します。
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または同等のものに適切に設定された「tel」フィールドがある各名簿エントリの「通話」オプションを提示します。
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. 必要に応じて、オーディオ/ビデオの発信者のIDと対応するXMPP名簿エントリを確認し、ユーザーがテキストチャットまたはXMPPを必要とするその他の形式の通信を使用できるようにします。
11. Optionally, delay the XMPP connection until after a SIP connection has been successfully registered.
11. オプションで、SIP接続が正常に登録されるまで、XMPP接続を遅らせます。
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つの個別のアカウントを設定する必要がないように、アカウントのオンラインプロビジョニングと構成を使用します。
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ユーザーの少なくとも1つの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. 必要に応じて、すべてのSIP INVITEメッセージに「impp」目的の「Call-Info」ヘッダーを添付して、クライアントが発信者を名簿エントリにすばやく関連付けて「発信者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:
補完的な機能を提供する2つの異なるアカウントで同じユーザーエージェントを使用すると、それらのアカウントまたは機能のセキュリティプロファイルが一致しない可能性があります。特に懸念される2つのセキュリティの不一致は次のとおりです。
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 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.
o CUSAXサービスのSIPアスペクトとXMPPアスペクトは、異なる認証オプション（[RFC3261]で指定されているSIPのダイジェスト認証と[RFC6120]で指定されているXMPPのソルトチャレンジレスポンス認証メカニズム（SCRAM）認証[RFC5802]を提供する場合があります。 ）。 SIPはパスワードベースの方法（ダイジェスト）を使用し、XMPPはプラグイン可能なフレームワークを使用して、Simple Authentication and Security Layer（SASL）テクノロジー[RFC4422]による認証を行うため、XMPP接続がパスワードなしで認証される可能性もあります。 SIP接続にユーザー名とパスワードが使用されている場合でも、SASL EXTERNALを使用したクライアント証明書などの方法。
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 XMPP側で提供またはネゴシエートされたトランスポート層セキュリティ（TLS）[RFC5246]暗号群は、SIPサーバーとXMPPサーバー間の実装または構成の違いにより、SIP側のものと異なる場合があります。さらに真剣に、CUSAXクライアントは、サービスのXMPPアスペクトに接続するときにTLSを正常にネゴシエートする可能性がありますが、SIPアスペクトに接続する場合はその可能性があります。この状況では、1つの側面しか保護されていなくても、エンドユーザーは、サービスと結合された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。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、2011年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、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年11月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「Session Initiation Protocol（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、「Simple Authentication and Security Layer（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、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、2006年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、「The Transport Layer Security（TLS）Protocol Version 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]ニューマン、C。、メノンセン、A。、メルニコフ、A。、およびN.ウィリアムズ、「ソルトチャレンジレスポンス認証メカニズム（SCRAM）SASLおよびGSS-APIメカニズム」、RFC 5802、2010年7月。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350] Perreault、S。、「vCard Format Specification」、RFC 6350、2011年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。、「SIMPLE Made Simple：A Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol（SIP）」、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。、「Session Initiation Protocol（SIP）のCall-Infoヘッダーフィールドのインスタントメッセージングとプレゼンスの目的」、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、「WebFinger」、RFC 7033、2013年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、「Data Forms」、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、「Service Discovery」、XSF XEP 0030、2008年6月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012.
[XEP-0045] Saint-Andre、P。、「マルチユーザーチャット」、XSF XEP 0045、2012年2月。
[XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008.
[XEP-0054] Saint-Andre、P。、「vcard-temp」、XSF XEP 0054、2008年7月。
[XEP-0128] Saint-Andre, P., "Service Discovery Extensions", XSF XEP 0128, October 2004.
[XEP-0128] Saint-Andre、P。、「Service Discovery Extensions」、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：Reachability Addresses」、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] Ludwig、S.、Beda、J.、Saint-Andre、P.、McQueen、R.、Egan、S.、and J. Hildebrand、 "Jingle"、XSF XEP 0166、December 2009。
[XEP-0167] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, December 2009.
[XEP-0167] Ludwig、S.、Saint-Andre、P.、Egan、S.、McQueen、R.、and D. Cionoiu、 "Jingle RTP Sessions"、XSF XEP 0167、December 2009。
[XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 0292, September 2013.
[XEP-0292] Saint-Andre、P。およびS. Mizzi、「vCard4 Over XMPP」、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は、それぞれGeneral Area Review Team、Applications Area Directorate、Security Directorate、およびOperations and Management Directorateに代わってドキュメントをレビューしました。
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
Emil Ivov Jitsiストラスブール67000フランス
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 Wynkoop Street、Suite 600 Denver、CO 80202 USA
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy
Enrico Morocco TelecomイタリアVia G. Reiss Romoli、274トリノ10148イタリア
EMail: enrico.marocco@telecomitalia.it