[要約] RFC 7434は、ISDN呼制御ユーザ情報をSIPと相互運用するためのガイドラインです。このRFCの目的は、ISDNとSIPの間での呼制御ユーザ情報の相互運用性を向上させることです。
Internet Engineering Task Force (IETF) K. Drage, Ed.
Request for Comments: 7434 Alcatel-Lucent
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
January 2015
Interworking ISDN Call Control User Information with SIP
ISDNコール制御ユーザー情報とSIPのインターワーキング
Abstract
概要
The motivation and use cases for interworking and transporting User-to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.
ITU-TデジタルサブスクライバーシグナリングシステムNo. 1（DSS1）からのユーザー間情報（UUI）のインターワーキングおよびトランスポートの動機と使用例は、SIP内のユーザーユーザー情報要素がRFC 6567で説明されています。 SIP、このデータを必要とするアプリケーションがSIPネットワークで機能し続けることができ、エンドツーエンドの透過性のためにこのISDNサービスと相互作用することができることが重要です。このドキュメントでは、ユーザー間ヘッダーフィールドの使用法（ISDN UUIパッケージと呼ばれる新しいパッケージ）を定義して、このISDNサービスとの相互作用を可能にします。
This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.
このドキュメントでは、パブリックISDN機能とプライベートISDN機能の両方とのインターワーキングについて説明しているため、QSIGとのインターワーキングの可能性についても取り上げます。
The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.
パッケージは、「purpose」ヘッダーフィールドパラメータの新しい値「isdn-uui」で識別されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7434.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7434で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of the ISDN User-to-User Service . . . . . . . . . . 3
3.1. The Service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN Service on SIP Operation . . . . . . 6
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition Away from ISDN . . . . . . . . . . . . . . . . . . 7
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC Requirements . . . . . . . . . . . . . . . . . . . . . . 8
8. UAS Requirements . . . . . . . . . . . . . . . . . . . . . . 10
9. UUI Contents . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Considerations for ISDN Interworking Gateways . . . . . . . . 12
11. Coding Requirements . . . . . . . . . . . . . . . . . . . . . 12
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This document describes a usage of the User-to-User header field defined in [RFC7433] to enable the transport of UUI in ISDN interworking scenarios using SIP [RFC3261]. Specifically, this document discusses the interworking of the following items, which are call control related: ITU-T Recommendation Q.931 DSS1 User-user information element [Q931], ITU-T Recommendation Q.957.1 DSS1 User-to-User Signalling (UUS) supplementary service [Q957.1], and ITU-T Recommendation Q.763 User-to-User information parameter [Q763] data in SIP. Today, UUI is widely used in the Public Switched Telephone Network (PSTN) in contact centers and call centers that are transitioning away from ISDN to SIP.
このドキュメントでは、[RFC7433]で定義されているUser-to-Userヘッダーフィールドを使用して、SIP [RFC3261]を使用するISDNインターワーキングシナリオでUUIを転送できるようにします。具体的には、このドキュメントでは、コール制御に関連する次の項目のインターワーキングについて説明します。ITU-T勧告Q.931 DSS1ユーザー-ユーザー情報要素[Q931]、ITU-T勧告Q.957.1 DSS1ユーザー-ユーザーシグナリング（ UUS）補足サービス[Q957.1]、およびITU-T勧告Q.763 SIPのユーザー間情報パラメーター[Q763]データ。現在、UUIは、ISDNからSIPに移行するコンタクトセンターやコールセンターの公衆交換電話網（PSTN）で広く使用されています。
This usage is not limited to scenarios where interworking will occur. Rather it describes a usage where interworking is possible if interworking is met. That does not preclude its usage directly between two SIP terminals.
この使用法は、インターワーキングが発生するシナリオに限定されません。むしろ、インターワーキングが満たされた場合にインターワーキングが可能な使用法について説明します。これは、2つのSIP端末間での直接の使用を排除するものではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
ISDN defines a number of related services. Firstly, there is a user signalling bearer service that uses the information elements / parameters in the signalling channel to carry the data and does not establish a related circuit-switched connection. For DSS1, this is specified in ITU-T Recommendation Q.931, Sections 3.3 and 7 of [Q931]. Secondly, it defines a User-to-User Signalling (UUS) supplementary service that uses the information elements / parameters in the signalling channel to carry additional data but that is used in conjunction with the establishment of a related circuit-switched connection. This reuses the same information elements / parameters as the user signalling bearer service, with the addition of other signalling information, and for DSS1 this is specified in ITU-T Recommendation Q.957.1 [Q957.1].
ISDNはいくつかの関連サービスを定義しています。まず、シグナリングチャネルの情報要素/パラメータを使用してデータを伝送し、関連する回線交換接続を確立しないユーザーシグナリングベアラサービスがあります。 DSS1の場合、これはITU-T勧告Q.931、[Q931]のセクション3.3および7で指定されています。次に、シグナリングチャネルの情報要素/パラメータを使用して追加のデータを伝送するが、関連する回線交換接続の確立と併せて使用される、ユーザー間シグナリング（UUS）補足サービスを定義します。これは、他のシグナリング情報を追加して、ユーザーシグナリングベアラーサービスと同じ情報要素/パラメーターを再利用します。DSS1の場合、これはITU-T勧告Q.957.1 [Q957.1]で指定されています。
ISDN defines three variants of the UUS supplementary service as follows:
ISDNは、UUS補足サービスの3つのバリアントを次のように定義しています。
UUS1: User-to-User Information exchanged during the setup and clearing phases of a call by transporting DSS1 User-user information elements within call control messages. This in itself has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1 implicit, it is the presence of the user signalling data itself that constitutes the request for the service. UUS1 explicit uses additional supplementary service control information to control the request and granting of the service, as in UUS2 and UUS3. As a result, UUS1 explicit also allows the requester to additionally specify whether the parallel circuit-switched connection should proceed if the UUS1 service cannot be provided (preferred or required);
UUS1：コール制御メッセージ内のDSS1ユーザー-ユーザー情報要素を転送することにより、コールのセットアップおよびクリアフェーズ中に交換されるユーザー間情報。これ自体、2つのサブバリアント、暗黙的なUUS1と明示的なUUS1があります。 UUS1インプリシットでは、サービスの要求を構成するのは、ユーザーシグナリングデータ自体の存在です。 UUS1は、UUS2やUUS3と同様に、追加のサービス制御情報を使用して、サービスの要求と許可を制御します。その結果、UUS1エクスプリシットを使用すると、リクエスターはUUS1サービスを提供できない場合（推奨または必須）に並列回線交換接続を続行するかどうかをさらに指定できます。
UUS2: DSS1 User-user information elements exchanged from the sender's point of view during call establishment, between the DSS1 ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION messages; and
UUS2：DSS1 USER INFORMATIONメッセージ内のDSS1 ALERTINGメッセージとDSS1 CONNECTメッセージの間で、コールの確立中に送信者の視点から交換されるDSS1ユーザーユーザー情報要素。そして
UUS3: DSS1 User-user information elements exchanged while a call is in the Active state, within DSS1 USER INFORMATION messages.
UUS3：呼び出しがアクティブ状態のときにDSS1 USER INFORMATIONメッセージ内で交換されるDSS1ユーザーユーザー情報要素。
The service is always requested by the calling user.
サービスは常に呼び出し元のユーザーによって要求されます。
This document defines only the provision of the ISDN UUS1 implicit supplementary service to interworking scenarios, this being the most widely deployed and used of the various ISDN User-to-User services, and is indeed the one that matches the requirements specified in [RFC6567].
このドキュメントでは、インターワーキングシナリオに対するISDN UUS1暗黙的補足サービスのプロビジョニングのみを定義しています。これは、さまざまなISDNユーザー間サービスの中で最も広く展開および使用されており、[RFC6567]で指定されている要件に実際に一致するサービスです。 。
The above comes from the ISDN specifications defined for public networks. There is a parallel set of ISDN specifications defined for private networks (QSIG). These specifications do not define a UUS1 implicit supplementary service. However, implementation of such a UUS1 implicit supplementary service for private networks can readily be constructed in a proprietary fashion based on the specifications for public networks, and evidence suggests that some vendors have done so. On this basis, there is no reason why this package cannot also be used to support interworking with such a private network service, on the assumption that the constraints are exactly the same as those for the public network.
上記は、パブリックネットワーク用に定義されたISDN仕様に基づいています。プライベートネットワーク（QSIG）用に定義されたISDN仕様の並列セットがあります。これらの仕様は、UUS1暗黙の補足サービスを定義していません。ただし、プライベートネットワーク用のこのようなUUS1暗黙的補足サービスの実装は、パブリックネットワークの仕様に基づいて独自の方法で簡単に構築でき、一部のベンダーがそうしたことを示す証拠があります。これに基づいて、制約がパブリックネットワークの制約とまったく同じであるという前提で、このパッケージをそのようなプライベートネットワークサービスとのインターワーキングのサポートに使用できない理由はありません。
The ISDN UUS1 service has the following additional characteristics as to the data that can be transported:
ISDN UUS1サービスには、転送可能なデータに関して、次の特徴があります。
The maximum number of octets of user information that can be transported is 128 octets plus a protocol discriminator. It is noted that some early ISDN implementations had a limitation of 32 octets, but it is understood that these are not currently deployed. While this package does not prohibit longer data fields, the mechanism at any interworking point discards data elements that are too long to handle. The handled length can normally be assumed to be 128 octets.
転送できるユーザー情報の最大オクテット数は、128オクテットとプロトコル識別子です。一部の初期のISDN実装には32オクテットの制限がありましたが、これらは現在展開されていません。このパッケージはより長いデータフィールドを禁止していませんが、インターワーキングポイントのメカニズムは、長すぎて処理できないデータ要素を破棄します。処理される長さは、通常128オクテットと見なすことができます。
The content of the user information octets is described by a single octet protocol discriminator (see Table 4-26 of ITU-T Recommendation Q.931) [Q931]. That protocol discriminator may describe the protocol used within the user data, the structure of the user data, or leave it entirely open. Note that not all values within the protocol discriminator necessarily make sense for use in the ISDN User-to-User service, as the content is aligned with the protocol discriminator that appears at the start of all DSS1 messages (see Table 4-1 of ITU-T Recommendation Q.931) [Q931]. The protocol discriminator value has no impact on the interworking capability.
ユーザー情報オクテットの内容は、単一のオクテットプロトコル弁別子によって記述されます（ITU-T勧告Q.931の表4-26を参照）[Q931]。そのプロトコル弁別子は、ユーザーデータ内で使用されるプロトコル、ユーザーデータの構造を記述したり、完全にオープンのままにしたりできます。コンテンツはすべてのDSS1メッセージの先頭に表示されるプロトコル識別子と整合しているため、プロトコル識別子内のすべての値がISDNユーザー間サービスでの使用に必ずしも意味があるわけではないことに注意してください（ITUの表4-1を参照） -T勧告Q.931）[Q931]。プロトコル識別子の値は、インターワーキング機能に影響を与えません。
Only a single piece of UUI data can be transported in each message.
各メッセージで転送できるUUIデータは1つだけです。
The ISDN service works without encryption or integrity protection. The user trusts the intermediate network elements, and therefore the operator of those elements, not to modify the data and to deliver all the data to the remote user. On a link-by-link basis, message contents are protected at Layer 2 by standard cyclic redundancy check mechanisms -- this allows loss on a link-level basis to be detected but does not guard against fraudulent attacks on the link itself. This does not prevent the use of additional encryption or integrity protection within the UUI data itself, although the limit on the size of the UUI data (protocol discriminator plus 128 octets) will restrict this.
ISDNサービスは、暗号化または整合性保護なしで機能します。ユーザーは、データを変更せずにすべてのデータをリモートユーザーに配信するために、中間ネットワーク要素、したがってそれらの要素のオペレーターを信頼します。リンクごとに、メッセージの内容は標準の巡回冗長検査メカニズムによってレイヤー2で保護されます。これにより、リンクレベルでの損失を検出できますが、リンク自体への不正な攻撃を防ぐことはできません。これは、UUIデータ自体の中での追加の暗号化または整合性保護の使用を妨げませんが、UUIデータ（プロトコル識別子と128オクテット）のサイズの制限によって制限されます。
The ISDN service has the following impacts that need to be understood within the SIP environment.
ISDNサービスには、SIP環境内で理解する必要がある次の影響があります。
Call transfer: ISDN call transfer cancels all ISDN User-to-User supplementary services. In the ISDN, if User-to-User data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred.
通話転送：ISDN通話転送は、すべてのISDNユーザー間補足サービスをキャンセルします。 ISDNでは、コール転送後にユーザー間データが必要な場合、UUS3を再ネゴシエートする必要があります。これは、このSIP拡張では提供されません。 SIP環境に対するこの制限の影響は、コール転送が発生した後にSIPダイアログをクリアするトランザクションでUUIヘッダーフィールドを交換できないことです。
Conference: ISDN conferencing allows the user to still exchange User-to-User data after the conference is created. As far as UUS1 is concerned, it is not permitted. The ISDN three-party supplementary service is similar in many ways to conferencing but is signalled using a different mechanism. This means that on clearing, the controller using UUS1 implicit does have the choice of sending data to either or both remote users. Because SIP conferencing cannot completely emulate the ISDN three-party supplementary service at the served user, UUS1 implicit is not possible.
会議：ISDN会議では、ユーザーは会議の作成後もユーザー間データを交換できます。 UUS1に関する限り、これは許可されていません。 ISDN 3者補足サービスは、多くの点で会議と似ていますが、別のメカニズムを使用して通知されます。つまり、クリア時に、UUS1を暗黙的に使用するコントローラーは、どちらか一方または両方のリモートユーザーにデータを送信することを選択できます。 SIP会議では、サービスを受けるユーザーのISDN 3者補足サービスを完全にエミュレートできないため、暗黙的なUUS1は不可能です。
Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is sent to the forwarded-to-user (assuming that the call meets requirements for providing the service -- this is impacted by the explicit service only). If the type of diversion is such that the call is also delivered to the forwarding user, they will also receive any UUS1 User-to-User data.
宛先変更：ISDN宛先変更が発生すると、UUS1ユーザー間データが転送先ユーザーに送信されます（呼び出しがサービスを提供するための要件を満たしていると想定します-これは明示的なサービスのみの影響を受けます）。転送のタイプが、コールが転送ユーザにも配信されるようなものである場合、それらは、UUS1ユーザ間データも受信します。
A method of transport of ISDN User-to-User data is to use SIP-T [RFC3372] and transport the UUI information end-to-end (as part of an ISUP message or QSIG message) as a MIME body. If the SIP-T method of encapsulation of ISDN instead of interworking is used, this is a reasonable mechanism and does not require any extensions to existing SIP-T. However, if true ISDN interworking is being done, and therefore SIP-T would not otherwise be used, this approach is not reasonable because then implementation of the many elements of the ISUP syntax would be required to understand one element of data. Instead, the better approach is to interwork the ISDN User-to-User data using the native SIP UUI transport mechanism, the User-to-User header field. The rest of this document describes this approach.
ISDNユーザー間データの転送方法は、SIP-T [RFC3372]を使用し、UUI情報をエンドツーエンドで（ISUPメッセージまたはQSIGメッセージの一部として）MIME本文として転送することです。インターワーキングの代わりにISDNをカプセル化するSIP-T方式を使用する場合、これは合理的なメカニズムであり、既存のSIP-Tへの拡張は必要ありません。ただし、真のISDNインターワーキングが行われているためにSIP-Tを使用しない場合は、データの1つの要素を理解するためにISUP構文の多くの要素の実装が必要になるため、このアプローチは妥当ではありません。代わりに、ネイティブのSIP UUIトランスポートメカニズムであるユーザー間ヘッダーフィールドを使用して、ISDNのユーザー間データをインターワークする方法がより適切です。このドキュメントの残りの部分では、このアプローチについて説明します。
This interworking usage of the SIP UUI mechanism will likely begin with one UA as an ISDN gateway while the other UA is a native SIP endpoint. As networks transition away from ISDN, it is possible that both UAs could become native SIP endpoints. In this case, there is an opportunity to transition away from this ISDN usage to a more general usage of [RFC7433].
SIP UUIメカニズムのこのインターワーキングの使用法は、ISDNゲートウェイとしての1つのUAから始まる可能性が高く、もう1つのUAはネイティブSIPエンドポイントです。ネットワークがISDNから離れるにつれて、両方のUAがネイティブSIPエンドポイントになる可能性があります。この場合、このISDNの使用から[RFC7433]のより一般的な使用に移行する機会があります。
The SIP UUI mechanism provides a way to achieve this transition. As an endpoint moves from being an ISDN gateway to a native SIP endpoint, and a future package for some form of enhanced UUI has been standardized, the endpoint can carry the UUI data both as ISDN and as the future package in parallel and in the same messages or in different messages depending on the needs of the application. This will permit the other endpoint to use the UUI according to the ISDN UUI package if it is an ISDN gateway or according to the future package if it is a native SIP endpoint.
SIP UUIメカニズムは、この移行を実現する方法を提供します。エンドポイントがISDNゲートウェイからネイティブSIPエンドポイントに移行し、何らかの形の拡張UUIの将来のパッケージが標準化されたため、エンドポイントはUDNデータをISDNとしても将来のパッケージとしても並行して同じように運ぶことができますメッセージまたはアプリケーションのニーズに応じて異なるメッセージ。これにより、ISDNゲートウェイの場合はISDN UUIパッケージ、ネイティブSIPエンドポイントの場合は将来のパッケージに従って、他のエンドポイントがUUIを使用できるようになります。
This document defines the package for the ISDN interworking of UUI that interoperates with ISDN UUS, a supplementary service in which the user is able to send/receive a limited amount of information to/ from another ISDN user over the signalling channel in association with a call to the other ISDN user.
このドキュメントでは、ISDN UUSと相互運用するUUIのISDNインターワーキング用のパッケージを定義します。ISDNUUSは、ユーザーがコールに関連してシグナリングチャネルを介して別のISDNユーザーとの間で限られた量の情報を送受信できる補足サービスです。他のISDNユーザーに。
Two examples of ISDN UUI with redirection (transfer and diversion) are defined in [ANSII] and [ETSI].
[ANSI]と[ETSI]では、リダイレクト（転送と迂回）を伴うISDN UUIの2つの例が定義されています。
One objective of the design of this package has been to keep the functionality at the interworking point as simple as possible. As a result, there is also only one encoding value specified.
このパッケージの設計の目的の1つは、インターワーキングポイントでの機能をできるだけシンプルに保つことです。その結果、エンコード値も1つしか指定されません。
Responsibility for respecting the limits has been transferred to the end UA. If an interworking point is reached, and the limitations of the ISDN (see Section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked. This is rather than have the interworking point attempt to resolve the non-compliance with the limitations of ISDN.
制限を尊重する責任はエンドUAに移されました。インターワーキングポイントに到達し、ISDNの制限（セクション3.1を参照）が満たされていない場合、UUIデータは転送されませんが、SIP要求はインターワークされます。これは、インターワーキングポイントがISDNの制限への非準拠を解決しようとするのではありません。
The general principals of the UUI mechanism package are, therefore, as follows:
したがって、UUIメカニズムパッケージの一般的な原則は次のとおりです。
The sending application is expected to limit their sending requirements to the subset provided by the ISDN User-to-User service.
送信アプリケーションは、ISDNユーザー間サービスによって提供されるサブセットに送信要件を制限することが期待されています。
The SIP UA will not allow the reception of more than one User-to-User header field relating to the "isdn-uui" package in the same SIP request or response; it will only allow it in a request or response of the appropriate method (INVITE or BYE). What happens to User-to-User header fields relating to other packages is outside the scope of this document.
SIP UAは、同じSIP要求または応答内の「isdn-uui」パッケージに関連する複数のユーザー間ヘッダーフィールドの受信を許可しません。適切なメソッド（INVITEまたはBYE）の要求または応答でのみ許可されます。他のパッケージに関連するユーザー間ヘッダーフィールドの処理は、このドキュメントの範囲外です。
An interworking point trying to interwork UUI data that is too long will discard the UUI data but proceed with the interworking. There is no notification of such discard back to the sending user. If the SIP user knows that it is interworking with the ISDN, then the UUI application at the SIP endpoint should limit its communication to packets of 128 octets plus the protocol discriminator, with the knowledge that discard will occur if it does not. The UUI application at the SIP endpoint has complete control over what occurs. It should be noted that this was exactly the envisaged operation when early ISDN implementations that only supported 32 octets interworked with those supporting 128 octets. It also corresponds to the interworking with ISDNs that do not support the supplementary service at all, as discard will occur in these circumstances as well. Note that failure to include the User-to-User data into the ISDN SETUP message (when discard occurs) will result in the service being unavailable for the remainder of the call when UUS1 implicit operation is used.
長すぎるUUIデータをインターワークしようとするインターワーキングポイントは、UUIデータを破棄しますが、インターワークを続行します。送信ユーザーへのそのような破棄の通知はありません。 SIPユーザーがISDNと相互作用していることをSIPユーザーが知っている場合、SIPエンドポイントのUUIアプリケーションは、通信を128オクテットのパケットとプロトコル識別子に制限する必要があります。そうしないと、破棄が発生することがわかります。 SIPエンドポイントのUUIアプリケーションは、発生することを完全に制御します。これは、32オクテットのみをサポートする初期のISDN実装が、128オクテットをサポートするものと相互に作用するときに想定されていた動作であったことに注意してください。また、これらの状況でも破棄が発生するため、補足サービスをまったくサポートしないISDNとのインターワーキングに対応しています。ユーザー間データをISDNセットアップメッセージに含めることに失敗した場合（破棄が発生した場合）、UUS1の暗黙の操作が使用されている場合、残りの呼び出しでサービスを利用できなくなることに注意してください。
The User Agent Client (UAC) MUST meet the requirements of [RFC7433] in addition to the requirements defined in this document.
ユーザーエージェントクライアント（UAC）は、このドキュメントで定義されている要件に加えて、[RFC7433]の要件を満たす必要があります。
The UAC MUST only use this UUI mechanism extension package in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog, is precluded. Usage on other methods within the INVITE dialog, and on re-INVITE transactions with the INVITE dialog, is also precluded.
UACは、最初のINVITEメソッドと、INVITEダイアログに関連するBYEメソッドに関連してのみ、このUUIメカニズム拡張パッケージを使用する必要があります。他のタイプのダイアログに関連付けられているトランザクション、またはダイアログに関連付けられていないメソッドでの使用は禁止されています。 INVITEダイアログ内の他のメソッド、およびINVITEダイアログを使用したre-INVITEトランザクションでの使用も除外されます。
If the UAC wishes to use or permit the sending of UUI data at any point in the dialog, the UAC MUST include in the INVITE request for that dialog a User-to-User header field. The UAC SHOULD set the "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package. This initial header field constitutes the implicit request to use the UUI service and is, therefore, included even when there is no data except the protocol discriminator octet to send at that point in time.
UACがダイアログの任意の時点でUUIデータの送信を使用または許可したい場合、UACはそのダイアログのINVITE要求にユーザー間ヘッダーフィールドを含める必要があります。 UACは、「目的」ヘッダーフィールドパラメーターを「isdn-uui」に設定する必要があります（SHOULD）。 「目的」ヘッダーフィールドパラメータを含めないことは許可されていますが、これは主に、以前の実装でこのパッケージをサポートできるようにするためです。この初期ヘッダーフィールドは、UUIサービスを使用するための暗黙的な要求を構成するため、その時点で送信するプロトコル識別子オクテット以外のデータがない場合でも含まれます。
The UAC MUST NOT include the User-to-User header field with a "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field, either with a "purpose" header field parameter set to "isdn-uui" or with no "purpose" header field parameter included.
UACは、「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定された、または「目的」ヘッダーフィールドパラメーターがないユーザー間ヘッダーフィールドを、元のINVITEの場合のINVITEダイアログのメッセージに含めてはなりません（MUST NOT）。リクエストにUser-to-Userヘッダーフィールドが含まれていません。「purpose」ヘッダーフィールドパラメータが「isdn-uui」に設定されているか、「purpose」ヘッダーフィールドパラメータが含まれていません。
When sending UUI for the ISDN UUI package, if the "purpose" header field is included, the UAC MUST set the User-to-User "purpose" header field parameter to "isdn-uui". The UAC MUST NOT include more than one User-to-User header field for this package in any SIP request or response.
ISDN UUIパッケージのUUIを送信するときに、「目的」ヘッダーフィールドが含まれている場合、UACはユーザー間「目的」ヘッダーフィールドパラメーターを「isdn-uui」に設定する必要があります。 UACは、SIP要求または応答にこのパッケージの複数のユーザー間ヘッダーフィールドを含めてはなりません（MUST NOT）。
When receiving UUI, when multiple User-to-User header fields are received in the same response with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAC MUST discard all these header fields. There are no mechanisms for determining which ones are the intended UUI data, so all are discarded.
UUIを受信するとき、「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定されているか、「目的」ヘッダーフィールドパラメーターがないか、またはいくつかの組み合わせで、同じ応答で複数のユーザー間ヘッダーフィールドが受信された場合これらの場合、UACはこれらすべてのヘッダーフィールドを破棄する必要があります。どのデータが意図したUUIデータであるかを判別するメカニズムがないため、すべて破棄されます。
The application designer will need to take into account the ISDN service restrictions; failure to do so can result in information being discarded at any interworking point with the ISDN. This document makes no further normative requirements based on those constraints because those constraints may vary from one ISDN to another. It is reasonable to expect that a limitation of 128 octets (plus a protocol discriminator) can be imposed by the ISDN; therefore, UUI data longer than this will never reach the destination if such interworking occurs. Note that the 128-octet limit (plus a protocol discriminator) applies before the encoding (or after the decoding) using the "hex" encoding. The "hex" encoding is defined in [RFC7433].
アプリケーション設計者は、ISDNサービスの制限を考慮する必要があります。そうしないと、ISDNとのインターワーキングポイントで情報が破棄される可能性があります。これらの制約はISDNごとに異なる可能性があるため、このドキュメントでは、これらの制約に基づいてこれ以上の規範的な要件を作成しません。 ISDNによって128オクテット（およびプロトコル識別子）の制限が課される可能性があることを期待するのは妥当です。したがって、このようなインターワーキングが発生した場合、これより長いUUIデータは宛先に到達しません。 128オクテットの制限（およびプロトコル識別子）は、「hex」エンコーディングを使用したエンコーディングの前（またはデコーディングの後に）に適用されることに注意してください。 「hex」エンコーディングは[RFC7433]で定義されています。
A "uui" option tag for use with the UUI mechanism extension is defined in [RFC7433]. Because the service is UUS1 implicit for the ISDN User-to-User service, the inclusion of the "uui" option tag in a Supported header field conveys no additional information over and above the presence, in the INVITE request, of the User-to-User header field with the "purpose" header field parameter set to "isdn-uui". While there is no harm in including the "uui" option tag, and strictly it should be included if the extension is supported, it performs no function. The presence of the "uui" option tag in the Require header field of an INVITE request will cause the request to fail if it reaches a UAS or ISDN interworking gateway that does not support this extension; such usage is allowed but will produce results that are inconsistent with the mechanisms defined in the ISDN UUS supplementary service.
UUIメカニズム拡張で使用する「uui」オプションタグは、[RFC7433]で定義されています。サービスはISDN User-to-Userサービスに暗黙的なUUS1であるため、Supportedヘッダーフィールドに「uui」オプションタグを含めても、User-toのINVITEリクエストの存在に加えて、追加情報は伝達されません。 -「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定されたユーザーヘッダーフィールド。 「uui」オプションタグを含めても害はありませんが、拡張機能がサポートされている場合は厳密に含める必要がありますが、機能しません。 INVITE要求のRequireヘッダーフィールドに「uui」オプションタグが存在すると、この拡張をサポートしないUASまたはISDNインターワーキングゲートウェイに到達すると、要求が失敗します。このような使用は許可されますが、ISDN UUS補足サービスで定義されたメカニズムと一致しない結果が生成されます。
The UAS MUST meet the requirements of [RFC7433] in addition to the requirements defined in this document.
UASは、このドキュメントで定義されている要件に加えて、[RFC7433]の要件を満たす必要があります。
The UAS MUST only use this UUI mechanism extension package in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog, is precluded. Usage on other methods within the INVITE dialog, and on re-INVITE transactions with the INVITE dialog, is also precluded.
UASは、初期のINVITEメソッドと、INVITEダイアログに関連するBYEメソッドに関連してのみ、このUUIメカニズム拡張パッケージを使用する必要があります。他のタイプのダイアログに関連付けられているトランザクション、またはダイアログに関連付けられていないメソッドでの使用は禁止されています。 INVITEダイアログ内の他のメソッド、およびINVITEダイアログを使用したre-INVITEトランザクションでの使用も除外されます。
The UAS MUST NOT include the User-to-User header field with a "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field, either with a "purpose" header field parameter set to "isdn-uui" or with no "purpose" header field parameter included.
UASは、「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定された、または「目的」ヘッダーフィールドパラメーターがないユーザー間ヘッダーフィールドを、元のINVITEの場合のINVITEダイアログのメッセージに含めてはなりません（MUST NOT）。リクエストにUser-to-Userヘッダーフィールドが含まれていません。「purpose」ヘッダーフィールドパラメータが「isdn-uui」に設定されているか、「purpose」ヘッダーフィールドパラメータが含まれていません。
The UAS MAY include the User-to-User header field in responses to the initial INVITE request, or the BYE requests or responses for the dialog, only where the original INVITE request included a User-to-User header field with the "purpose" header field parameter set to "isdn-uui" or where no "purpose" header field parameter was included. When sending UUI for the ISDN UUI package, the UAS SHOULD set the User-to-User "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package.
UASは、最初のINVITEリクエストへの応答、またはダイアログのBYEリクエストまたは応答にUser-to-Userヘッダーフィールドを含めることができます。元のINVITEリクエストに「目的」を持つUser-to-Userヘッダーフィールドが含まれていた場合のみ「isdn-uui」に設定されたヘッダーフィールドパラメーター、または「目的」ヘッダーフィールドパラメーターが含まれていない場所。 ISDN UUIパッケージのUUIを送信するとき、UASはユーザーからユーザーへの「目的」ヘッダーフィールドパラメーターを「isdn-uui」に設定する必要があります（SHOULD）。 「目的」ヘッダーフィールドパラメータを含めないことは許可されていますが、これは主に、以前の実装でこのパッケージをサポートできるようにするためです。
When sending UUI for the ISDN UUI package, if the "purpose" header field is included, the UAS MUST set the User-to-User "purpose" header field parameter to "isdn-uui". The UAS MUST NOT include more than one User-to-User header field for this package in any SIP request or response.
ISDN UUIパッケージのUUIを送信するときに、「目的」ヘッダーフィールドが含まれている場合、UASはユーザー間「目的」ヘッダーフィールドパラメーターを「isdn-uui」に設定する必要があります。 UASは、SIP要求または応答にこのパッケージの複数のユーザー間ヘッダーフィールドを含めてはなりません（MUST NOT）。
The "isdn-interwork" value for the "purpose" header field parameter was used in documents that led to the publication of the present document. Although these documents had no other status than "Work in Progress", this value is implemented by some vendors. While not defined by this document, implementations could find it useful for interoperability purposes to support parsing and interpreting "isdn-interwork" the same way as "isdn-uui" when receiving messages.
「目的」ヘッダーフィールドパラメータの「isdn-interwork」値は、現在のドキュメントの発行につながったドキュメントで使用されました。これらのドキュメントには「Work in Progress」以外のステータスはありませんでしたが、この値は一部のベンダーによって実装されています。このドキュメントでは定義されていませんが、実装は、メッセージの受信時に「isdn-uui」と同じ方法で「isdn-interwork」の解析と解釈をサポートすると、相互運用性の目的に役立つことがあります。
Where the UAS is acting as a redirect server, the UAS MUST NOT include the User-to-User header field in the header URI parameter in a 3xx response to an incoming request.
UASがリダイレクトサーバーとして機能している場合、UASは、着信要求に対する3xx応答のヘッダーURIパラメーターにユーザー間ヘッダーフィールドを含めてはなりません（MUST NOT）。
When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, the UAS MUST discard this header field.
UUIを受信するとき、「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定されている、または「目的」ヘッダーフィールドパラメーターが設定されていない、発信元ユーザーからのリクエストではないユーザー間ヘッダーフィールドを受信した場合、UASはこのヘッダーフィールドを破棄する必要があります。
When receiving UUI, when multiple User-to-User header fields are received from the originating user in the same request with the "purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter, or with some combination of these, the UAS MUST discard all these header fields. There are no mechanisms for determining which ones are the intended UUI data, so all are discarded.
UUIを受信するとき、「目的」ヘッダーフィールドパラメーターを「isdn-uui」に設定して、または「目的」ヘッダーフィールドパラメーターを指定せずに、同じ要求で発信ユーザーから複数のユーザー間ヘッダーフィールドを受信した場合、またはこれらのいくつかの組み合わせで、UASはこれらすべてのヘッダーフィールドを破棄する必要があります。どのデータが意図したUUIデータであるかを判別するメカニズムがないため、すべて破棄されます。
These requirements apply when the "purpose" header field parameter is set to "isdn-uui" or when there is no "purpose" header field parameter.
これらの要件は、「目的」ヘッダーフィールドパラメーターが「isdn-uui」に設定されている場合、または「目的」ヘッダーフィールドパラメーターがない場合に適用されます。
Processing for User-to-User header fields sent or received with values other than this value are outside the scope of this document, and the appropriate package document for that value applies.
この値以外の値で送受信されるユーザー間ヘッダーフィールドの処理は、このドキュメントの範囲外であり、その値に適切なパッケージドキュメントが適用されます。
The default and only content defined for this package is "isdn-uui". When sending UUI, the sending SIP entity MAY, but need not, include a "content" header field with a value set to "isdn-uui". A receiving SIP entity MUST ignore a received User-to-User header field if the "content" header field parameter is present and the value is some other value than "isdn-uui".
このパッケージに定義されているデフォルトの唯一のコンテンツは「isdn-uui」です。 UUIを送信するとき、送信SIPエンティティは、「isdn-uui」に設定された値を持つ「コンテンツ」ヘッダーフィールドを含めることができますが、必須ではありません。 「コンテンツ」ヘッダーフィールドパラメータが存在し、値が「isdn-uui」以外の値である場合、受信SIPエンティティは受信したユーザー間ヘッダーフィールドを無視する必要があります。
The default and only encoding defined for this package is "hex". When sending UUI, the sending SIP entity MAY, but need not, include an "encoding" header field with a value set to "hex". A receiving SIP entity MUST ignore a received User-to-User header field if the "encoding" header field parameter is present and the value is some other value than "hex".
このパッケージに定義されているデフォルトの唯一のエンコーディングは「hex」です。 UUIを送信するとき、送信SIPエンティティは、値を「hex」に設定した「エンコーディング」ヘッダーフィールドを含めることができますが、そうする必要はありません。 「encoding」ヘッダーフィールドパラメータが存在し、値が「hex」以外の値である場合、受信SIPエンティティは受信したUser-to-Userヘッダーフィールドを無視する必要があります。
When sending UUI, the sending application MUST include a protocol discriminator octet, conforming to Table 4-26 of ITU-T Recommendation Q.931 [Q931], as the first octet of the UUI data. It is up to the receiving application what it does with this value. This document places no other normative requirement on the use of the protocol discriminator; it is required at interworking gateways to allow mapping into the appropriate fields in the ISDN protocols; otherwise, the usage is entirely up to the application and is outside the scope of this document. Valid values are identified and documented by ITU-T, and there is no IANA registry for these values.
UUIを送信する場合、送信アプリケーションは、UTUデータの最初のオクテットとして、ITU-T勧告Q.931 [Q931]の表4-26に準拠したプロトコル識別子オクテットを含める必要があります。この値をどのように処理するかは、受信側アプリケーション次第です。このドキュメントでは、プロトコル識別子の使用に関するその他の規範的な要件はありません。インターワーキングゲートウェイでは、ISDNプロトコルの適切なフィールドにマッピングできるようにする必要があります。それ以外の場合、使用方法は完全にアプリケーション次第であり、このドキュメントの範囲外です。有効な値はITU-Tによって識別および文書化されており、これらの値に対するIANAレジストリはありません。
ISDN interworking gateways MUST support the requirements defined for UAS and UAC operation.
ISDNインターワーキングゲートウェイは、UASおよびUACの動作に定義された要件をサポートする必要があります。
ISDN interworking gateways MUST support only the "isdn-uui" package on dialogs that are interworked.
ISDNインターワーキングゲートウェイは、インターワークされているダイアログの「isdn-uui」パッケージのみをサポートする必要があります。
ISDN interworking gateways will take octet-structured data from the ISDN side and encode it using the "hex" encoding scheme defined in [RFC7433] for inclusion as the UUI data in the User-to-User header field. In the reverse direction, it will take valid UUI data according to the "hex" encoding scheme and decode it to octet-structured data to send to the ISDN side.
ISDNインターワーキングゲートウェイは、ISDN側からオクテット構造化データを取得し、[RFC7433]で定義されている「hex」エンコーディングスキームを使用してエンコードし、User-to-UserヘッダーフィールドにUUIデータとして含めます。逆方向では、 "hex"エンコーディングスキームに従って有効なUUIデータを取得し、それをオクテット構造化データにデコードして、ISDN側に送信します。
When mapping data content from the ISDN to SIP signalling, or from SIP signalling to the ISDN, the gateway needs to assume that all content is octet-structured binary, irrespective of the value of the received protocol discriminator. There are no requirements in the ISDN to ensure that the content matches the value of the protocol discriminator; the application usage sorts out any discrepancy. The same applies to the ISDN protocol discriminator as the first octet of the UUI data, as defined in Table 4-26 of ITU-T Recommendation Q.931 [Q931]; the interworking gateway will not perform any additional checking of this value.
ISDNからSIPシグナリングへ、またはSIPシグナリングからISDNへデータコンテンツをマッピングする場合、ゲートウェイは、受信したプロトコル識別子の値に関係なく、すべてのコンテンツがオクテット構造化バイナリであると想定する必要があります。 ISDNには、コンテンツがプロトコル識別子の値と一致することを保証するための要件はありません。アプリケーションの使用法は不一致を整理します。 ITU-T勧告Q.931 [Q931]の表4-26で定義されているように、UUIデータの最初のオクテットとしてISDNプロトコル識別子にも同じことが当てはまります。インターワーキングゲートウェイは、この値の追加のチェックを実行しません。
A "uui" option tag for use with the UUI mechanism extension is defined in [RFC7433]. The option tag is not interworked at an ISDN interworking gateway. The ISDN interworking gateways MUST NOT take the omission of the "uui" option tag in a received INVITE request to indicate that interworking of a received header field is not to be performed.
UUIメカニズム拡張で使用する「uui」オプションタグは、[RFC7433]で定義されています。オプションタグは、ISDNインターワーキングゲートウェイでインターワーキングされません。 ISDNインターワーキングゲートウェイは、受信したINVITEリクエストで「uui」オプションタグを省略して、受信したヘッダーフィールドのインターワーキングを実行しないことを示してはなりません（MUST NOT）。
This document defines "isdn-uui" as a new value of the User-to-User "purpose" header field parameter. The following ABNF adds to the production in [RFC7433]:
このドキュメントでは、ユーザー間の「目的」ヘッダーフィールドパラメータの新しい値として「isdn-uui」を定義しています。次のABNFは、[RFC7433]のプロダクションに追加されます。
pkg-param-value =/ "isdn-uui"
pkg-param-value = / "isdn-uui"
This document defines "isdn-uui" as a new value of the User-to-User "content" header field parameter. A content value of "isdn-uui" indicates that the contents have a first octet that is a protocol discriminator (see Table 4-26 of ITU-T Recommendation Q.931 [Q931]) followed by UUI data that can be subject to a length limitation (before encoding or after decoding) that is generally 128 octets.
このドキュメントでは、「isdn-uui」をユーザー間「コンテンツ」ヘッダーフィールドパラメータの新しい値として定義しています。 「isdn-uui」のコンテンツ値は、コンテンツに、プロトコル弁別子である最初のオクテット（ITU-T勧告Q.931 [Q931]の表4-26を参照）があり、その後に、長さの制限（エンコード前またはデコード後）は、通常128オクテットです。
The following ABNF adds to the production in [RFC7433].
次のABNFは、[RFC7433]のプロダクションに追加されます。
cont-param-value =/ "isdn-uui"
cont-param-value = / "isdn-uui"
This document defines the new media feature tag "sip.uui-isdn". This feature tag indicates that this ISDN UUI package is supported by the sender, and its usage is entirely in accordance with [RFC3840]. This document makes no additional provisions for the use of this feature tag.
このドキュメントでは、新しいメディア機能タグ「sip.uui-isdn」を定義しています。この機能タグは、このISDN UUIパッケージが送信者によってサポートされており、その使用法が完全に[RFC3840]に準拠していることを示します。このドキュメントでは、この機能タグの使用に関する追加の規定はありません。
Per this document, the following row has been added to the "UUI Packages" subregistry of the SIP parameter registry:
このドキュメントにより、SIPパラメータレジストリの「UUI Packages」サブレジストリに次の行が追加されました。
Value: isdn-uui
値：isdn-uui
Description: The associated application is being used with constraints suitable for interworking with the ISDN User-to-User service, and therefore can be interworked at ISDN gateways.
説明：関連するアプリケーションは、ISDNユーザー間サービスとの相互作用に適した制約で使用されているため、ISDNゲートウェイで相互作用することができます。
Reference: RFC 7434
リファレンス：RFC 7434
Per this document, the following row has been added to the "UUI Content" subregistry of the SIP parameter registry:
このドキュメントにより、SIPパラメータレジストリの「UUIコンテンツ」サブレジストリに次の行が追加されました。
Value: isdn-uui
値：isdn-uui
Description: The associated contents conform to the content associated with the ISDN User-to-User service. In the presence of the "purpose" header field parameter set to "isdn-uui" (or the absence of any "purpose" header field parameter), this is the default meaning and therefore need not be included in this case.
説明：関連するコンテンツは、ISDNユーザー間サービスに関連するコンテンツに準拠しています。 「isdn-uui」に設定された「purpose」ヘッダーフィールドパラメータがある場合（または「purpose」ヘッダーフィールドパラメータがない場合）、これはデフォルトの意味であるため、この場合に含める必要はありません。
Reference: RFC 7434
リファレンス：RFC 7434
This document defines the following media feature tag, which has been added to the features.sip-tree of the Media feature tags registry:
このドキュメントでは、メディア機能タグレジストリのfeatures.sip-treeに追加された次のメディア機能タグを定義しています。
Media feature tag name: sip.uui-isdn
メディア機能タグ名：sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x Summary of the media feature indicated by this tag: This media feature tag when used in a Contact header field of a SIP request or a SIP response indicates that the entity sending the SIP message supports the package "uui-isdn".
ASN.1識別子：1.3.6.1.8.4.xこのタグで示されるメディア機能の概要：このメディア機能タグは、SIP要求またはSIP応答のContactヘッダーフィールドで使用すると、SIPメッセージを送信するエンティティがサポートすることを示しますパッケージ「uui-isdn」。
Values appropriate for use with this feature tag: none
この機能タグでの使用に適した値：なし
Examples of typical use: Indicating that a mobile phone supports Single Radio Voice call Continuity (SRVCC) for calls in the alerting phase.
典型的な使用例：携帯電話がアラート段階の通話に対して単一無線音声通話継続（SRVCC）をサポートすることを示します。
Related standards or documents: RFC 7434
関連する規格または文書：RFC 7434
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of [RFC3840]
セキュリティに関する考慮事項：このメディア機能タグのセキュリティに関する考慮事項は、[RFC3840]のセクション11.1で説明されています。
This document contains no specific requirements in regard to security over and above those specified in [RFC7433]. However, since this capability is designed to interwork with the ISDN, the general security considerations of SIP to ISDN User Part (ISUP) interworking defined in [RFC3398] apply. Any SIP/PSTN gateway implementing the ISDN User-to-User service should not blindly trust ISUP from the PSTN. In general, the overlying use case will define the security measures required. The underlying User-to-User header field extension provides a number of tools that can meet certain security requirements.
このドキュメントには、[RFC7433]で指定されているもの以上のセキュリティに関する特定の要件は含まれていません。ただし、この機能はISDNと相互作用するように設計されているため、[RFC3398]で定義されているSIPからISDNユーザーパート（ISUP）への相互作用に関する一般的なセキュリティの考慮事項が適用されます。 ISDNユーザー間サービスを実装するSIP / PSTNゲートウェイは、PSTNからのISUPを盲目的に信頼してはなりません。一般に、上にあるユースケースは、必要なセキュリティ対策を定義します。基本的なユーザー間ヘッダーフィールド拡張は、特定のセキュリティ要件を満たすことができるいくつかのツールを提供します。
Information that might otherwise reveal private information about an individual, or where a level of authenticity needs to be guaranteed, may need a higher level of protection and may indeed not be suitable for this package, particularly taking into account the statement in the following paragraph.
そうでなければ個人に関する個人情報を明らかにする可能性のある情報、または信頼性のレベルを保証する必要がある場所は、より高いレベルの保護を必要とする可能性があり、特に次の段落のステートメントを考慮すると、実際にはこのパッケージには適さない可能性があります。
As this capability is defined to interwork with the ISDN, if the ISDN forms part of the route, any usage needs to be aware that the security level of the ISDN service may be lower than the security of the SIP service. The ISDN security is itself not definable on an end-to-end basis and exists on a hop-by-hop basis. This can be high in some places (e.g., it can require physical access to a secure building) and in other places it can be low (e.g., the point where an ISDN access enters a building). If this level of security is not sufficient, then either a different package or indeed a different method of data transfer needs to be selected by the application user.
この機能はISDNと相互に作用するように定義されているため、ISDNがルートの一部を形成する場合、ISDNサービスのセキュリティレベルがSIPサービスのセキュリティよりも低い場合があることに注意してください。 ISDNセキュリティ自体は、エンドツーエンドで定義することはできず、ホップバイホップで存在します。これは、一部の場所では高くなる可能性があります（たとえば、安全な建物への物理的なアクセスが必要になる場合があります）。その他の場所では低くなる可能性があります（ISDNアクセスが建物に入るポイントなど）。このセキュリティレベルでは不十分な場合は、アプリケーションユーザーが別のパッケージまたは実際に別のデータ転送方法を選択する必要があります。
[Q931] ITU-T, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, <http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.
[Q931] ITU-T、「ISDN user-network interface layer 3 specification for basic call control」、ITU-T Recommendation Q.931、<http://www.itu.int/rec/T-REC-Q.931 -199805-I / en>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002, <http://www.rfc-editor.org/info/rfc3372>.
[RFC3372] Vemuri、A.およびJ. Peterson、「Session Initiation Protocol for Telephones（SIP-T）：Context and Architectures」、BCP 63、RFC 3372、2002年9月、<http://www.rfc-editor.org / info / rfc3372>。
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002, <http://www.rfc-editor.org/info/rfc3398>.
[RFC3398] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「Integrated Services Digital Network（ISDN）User Part（ISUP）to Session Initiation Protocol（SIP）Mapping）」、RFC 3398、12月2002、<http://www.rfc-editor.org/info/rfc3398>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Indicating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月、<http：//www.rfc-editor。 org / info / rfc3840>。
[RFC7433] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User-to-User Call Control Information in SIP", RFC 7433, December 2014, <http://www.rfc-editor.org/info/rfc7433>.
[RFC7433]ジョンストンA.およびJ.ラファティー、「SIPでユーザー間通話制御情報を転送するメカニズム」、RFC 7433、2014年12月、<http://www.rfc-editor.org/info/ rfc7433>。
[ANSII] ANSI, "Integrated Services Digital Network (ISDN) - Explicit Call Transfer Supplementary Service", ANSI-T1.643A - SUP A, December 1996.
[ANSII] ANSI、「Integrated Services Digital Network（ISDN）-Explicit Call Transfer Supplementary Service」、ANSI-T1.643A-SUP A、1996年12月。
[ETSI] ETSI, "Integrated Services Digital Network (ISDN); Diversion supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification", ETSI ETS 300 207-1, Ed. 1, December 1994.
[ETSI] ETSI、「統合サービスデジタルネットワーク（ISDN）、迂回補足サービス、デジタル加入者信号システムNo. 1（DSS1）プロトコル、パート1：プロトコル仕様」、ETSI ETS 300 207-1、エド。 1994年12月1日。
[Q763] ITU-T, "Signalling System No. 7 - ISDN User Part formats and codes", ITU-T Recommendation Q.763, <http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.
[Q763] ITU-T、「Signalling System No. 7-ISDN User Part format and codes」、ITU-T Recommendation Q.763、<http://www.itu.int/rec/T-REC-Q.763 -199912-I / en>。
[Q957.1] ITU-T, "Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)", ITU-T Recommendation Q.957.1, <http://www.itu.int/rec/T-REC-Q.957.1-199607-I>.
[Q957.1] ITU-T、「デジタルサブスクライバーシグナリングシステムNo. 1-DSS 1を使用する補足サービスのステージ3の説明、DSS 1を使用する追加情報転送補足サービスのステージ3の説明：ユーザー間シグナリング（UUS） "、ITU-T勧告Q.957.1、<http://www.itu.int/rec/T-REC-Q.957.1-199607-I>。
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP", RFC 6567, April 2012, <http://www.rfc-editor.org/info/rfc6567>.
[RFC6567] Johnston、A。およびL. Liess、「SIPでユーザー間通話制御情報を転送するための問題ステートメントと要件」、RFC 6567、2012年4月、<http://www.rfc-editor.org/ info / rfc6567>。
Acknowledgments
謝辞
Joanne McMillen was a major contributor and coauthor of earlier versions of this document.
Joanne McMillenは、このドキュメントの以前のバージョンの主要な寄稿者および共著者でした。
Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland Jesske for their reviews of this document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, Mahalingam Mani, and Celine Serrut-Valette for their comments.
このドキュメントのレビューを提供してくれたSpencer Dawkins、Vijay Gurbani、Laura Liess、Roland Jesskeに感謝します。著者は、コメントしてくれたFrancois Audet、Denis Alexeitsev、Paul Kyzivat、Cullen Jennings、Mahalingam Mani、およびCeline Serrut-Valetteに感謝します。
The death of Francois Audet occurred before this document was finalized, and the authors would like to identify the significant contribution of Francois to this and a number of important RFCs and to express their condolences to his family. It was always a pleasure to work with Francois.
このドキュメントが完成する前にフランソワオーデットの死が発生しました。著者は、これといくつかの重要なRFCに対するフランソワの重要な貢献を特定し、家族に哀悼の意を表したいと思います。フランソワと一緒に仕事ができたことはいつも喜びでした。
Authors' Addresses
著者のアドレス
Keith Drage (editor) Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon United Kingdom
Keith Drage（編集者）アルカテルルーセントクアドラント、ストーンヒルグリーン、ウェストリースウィンドンイギリス
EMail: keith.drage@alcatel-lucent.com
Alan Johnston Avaya St. Louis, MO United States
あぁん じょｈんｓとん あゔぁや Ｓｔ。 ぉういｓ、 も うにてｄ Ｓたてｓ
EMail: alan.b.johnston@gmail.com