[要約] 要約： RFC 7433は、SIPでユーザー間の通話制御情報を転送するためのメカニズムを提供します。目的： このRFCの目的は、SIPセッションにおいてユーザー間の通話制御情報を効果的に転送するための標準化された手法を提供することです。
Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 7433 Avaya
Category: Standards Track J. Rafferty
ISSN: 2070-1721 Human Communications
January 2015
A Mechanism for Transporting User-to-User Call Control Information in SIP
SIPでユーザー間の通話制御情報を転送するメカニズム
Abstract
概要
There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.
セッションの確立中にSIPを使用してユーザー間情報（UUI）データを交換することから利益を得るアプリケーションのクラスがあります。呼制御UUIデータと呼ばれるこの情報は、セッションを開始するアプリケーションによって挿入され、セッションを受け入れるアプリケーションによって利用される小さなデータです。特定のアプリケーションで使用されるUUIデータの構文とセマンティクスは、UUIパッケージで定義されています。このUUIデータはSIPに対して不透明であり、その機能は基本的なSIP機能とは無関係です。このドキュメントでは、拡張メカニズムとともに、UUIデータを転送するための新しいSIPヘッダーフィールドUser-to-Userを定義します。
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/rfc7433.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7433で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4
4. Normative Definition . . . . . . . . . . . . . . . . . . . . 5
4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6
4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
4.3. Source Identity of UUI Data . . . . . . . . . . . . . . . 7
5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of User-to-User Header Field . . . . . . . . 11
6.2. Registration of User-to-User Header Field Parameters . . 11
6.3. Registration of UUI Packages . . . . . . . . . . . . . . 11
6.4. Registration of UUI Content Parameters . . . . . . . . . 12
6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
6.6. Registration of SIP Option Tag . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Other Possible Mechanisms . . . . . . . . . . . . . 17
A.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . 17
A.2. Why Other Protocol Encapsulation UUI Mechanisms Are Not
Used . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. MIME Body Approach . . . . . . . . . . . . . . . . . . . 17
A.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document describes the transport of UUI data using SIP [RFC3261]. It defines a mechanism for the transport of general application UUI data and for the transport of the call control related ITU-T Recommendation Q.931 User-user information element [Q931] and ITU-T Recommendation Q.763 User-to-User information parameter [Q763] data in SIP. UUI data is widely used in the Public Switched Telephone Network (PSTN) today for contact centers and call centers. There is also a trend for the related applications to transition from ISDN to SIP. The UUI extension for SIP may also be used for native SIP User Agents (UAs) implementing similar services and to interwork with ISDN services. Note that in most cases, there is an a priori understanding between the UAs in regard to what to do with received UUI data. This document enables the definition of packages and related attributes that can make such understandings more explicit.
このドキュメントでは、SIP [RFC3261]を使用したUUIデータの転送について説明します。これは、一般的なアプリケーションUUIデータのトランスポート、および呼制御に関連するITU-T勧告Q.931のユーザー-ユーザー情報要素[Q931]およびITU-T勧告Q.763のユーザー間情報のトランスポートのためのメカニズムを定義します。パラメータ[Q763] SIPのデータ。 UUIデータは、現在、コンタクトセンターおよびコールセンターの公衆交換電話網（PSTN）で広く使用されています。関連するアプリケーションがISDNからSIPに移行する傾向もあります。 SIPのUUI拡張は、同様のサービスを実装するネイティブSIPユーザーエージェント（UA）やISDNサービスとの相互作用にも使用できます。ほとんどの場合、受信したUUIデータをどのように処理するかに関して、UA間に事前の理解があります。このドキュメントは、そのような理解をより明確にすることができるパッケージと関連する属性の定義を可能にします。
The UUI mechanism is designed to meet the use cases, requirements, and call flows for SIP call control UUI detailed in [RFC6567]. All references to requirement numbers (REQ-N) and figure numbers refer to [RFC6567].
UUIメカニズムは、[RFC6567]で詳述されているSIPコール制御UUIのユースケース、要件、およびコールフローを満たすように設計されています。要件番号（REQ-N）および図番号へのすべての参照は、[RFC6567]を参照します。
The mechanism is a new SIP header field, along with a new SIP option tag. The header field carries the UUI data, along with parameters indicating the encoding of the UUI data, the UUI package, and optionally the content of the UUI data. The package definition contains details about how a particular application can utilize the UUI mechanism. The header field can be included (sometimes called "escaped") into URIs supporting referral and redirection scenarios. In these scenarios, the History-Info header field is used to indicate the inserter of the UUI data. The SIP option tag can be used to indicate support for the header field. Support for the UUI header field indicates that a UA is able to extract the information in the UUI data and pass it up the protocol stack. Individual packages using the UUI mechanism can utilize SIP media feature tags to indicate that a UA supports a particular UUI package. Guidelines for defining UUI packages are provided.
メカニズムは、新しいSIPヘッダーフィールドと新しいSIPオプションタグです。ヘッダーフィールドは、UUIデータ、UUIデータのエンコードを示すパラメーター、UUIパッケージ、およびオプションでUUIデータのコンテンツを運ぶUUIデータを運びます。パッケージ定義には、特定のアプリケーションがUUIメカニズムを利用する方法に関する詳細が含まれています。ヘッダーフィールドは、参照とリダイレクトのシナリオをサポートするURIに含めることができます（「エスケープ」と呼ばれることもあります）。これらのシナリオでは、History-Infoヘッダーフィールドを使用して、UUIデータの挿入者を示します。 SIPオプションタグは、ヘッダーフィールドのサポートを示すために使用できます。 UUIヘッダーフィールドのサポートは、UAがUUIデータの情報を抽出してプロトコルスタックに渡すことができることを示しています。 UUIメカニズムを使用する個々のパッケージは、SIPメディア機能タグを利用して、UAが特定のUUIパッケージをサポートすることを示すことができます。 UUIパッケージを定義するためのガイドラインが提供されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Note that the <allOneLine> tag convention from SIP Torture Test Messages [RFC4475] is used to show that there are no line breaks in the actual message syntax.
SIP Tortureテストメッセージ[RFC4475]の<allOneLine>タグの規則は、実際のメッセージ構文に改行がないことを示すために使用されていることに注意してください。
This section describes how the User-to-User header field meets the requirements in [RFC6567]. The header field can be included in INVITE requests and responses and BYE requests and responses, meeting REQ-1 and REQ-2.
このセクションでは、User-to-Userヘッダーフィールドが[RFC6567]の要件を満たす方法について説明します。ヘッダーフィールドは、REQ-1およびREQ-2を満たすINVITE要求と応答およびBYE要求と応答に含めることができます。
For redirection and referral use cases and REQ-3, the header field is included (escaped) within the Contact or Refer-To URI. The details of this mechanism as it applies for redirection and referral use cases are covered in Section 4.1.
リダイレクトと紹介のユースケースおよびREQ-3の場合、ヘッダーフィールドは連絡先または参照先URIに含まれます（エスケープされます）。リダイレクトと紹介のユースケースに適用されるこのメカニズムの詳細は、セクション4.1で説明されています。
Since SIP proxy forwarding and retargeting does not affect header fields, the header field meets REQ-4.
SIPプロキシの転送とリターゲティングはヘッダーフィールドに影響を与えないため、ヘッダーフィールドはREQ-4に適合します。
The UUI header field will carry the UUI data and not a pointer to the data, so REQ-5 is met.
UUIヘッダーフィールドは、データへのポインターではなくUUIデータを運ぶため、REQ-5が満たされます。
Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols is straightforward and is documented in a separate specification [RFC7434], meeting REQ-6.
UUIヘッダーフィールドの基本設計はISDN UUIサービスに類似しているため、PSTNプロトコルとのインターワーキングは簡単で、別の仕様[RFC7434]に記載されており、REQ-6に準拠しています。
Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the mechanism and supported packages, and hence applications. REQ-7 relates to support of the UUI header field, while REQ-8 relates to routing based on support of the UUI header field. REQ-7 is met by defining a new SIP option tag "uui". The use of a Require:uui in a request or Supported:uui in an OPTIONS response could be used to require or discover support of the mechanism. The presence of a Supported:uui or Require:uui header field can be used by proxies to route to an appropriate UA, meeting REQ-8. However, note that only UAs are expected to understand the UUI data -- proxies and other intermediaries do not. REQ-10 is met by utilizing SIP feature tags [RFC3840]. For example, the feature tag "sip.uui-isdn" could be used to indicate support of the ISDN UUI package, or "sip.uui-pk1" could be used to indicate support for a particular package, pk1.
要件REQ-7、REQ-8、およびREQ-10は、メカニズムおよびサポートされているパッケージ、したがってアプリケーションの検出に関連しています。 REQ-7はUUIヘッダーフィールドのサポートに関連し、REQ-8はUUIヘッダーフィールドのサポートに基づくルーティングに関連しています。 REQ-7は、新しいSIPオプションタグ「uui」を定義することで満たされます。要求でのRequire：uuiの使用、またはOPTIONS応答でのSupported：uuiの使用は、メカニズムのサポートを要求または発見するために使用できます。プロキシは、Supported：uuiまたはRequire：uuiヘッダーフィールドの存在を使用して、REQ-8を満たす適切なUAにルーティングできます。ただし、UAだけがUUIデータを理解する必要があることに注意してください。プロキシやその他の仲介者は理解しません。 REQ-10は、SIP機能タグ[RFC3840]を利用して満たされます。たとえば、機能タグ「sip.uui-isdn」を使用してISDN UUIパッケージのサポートを示すことができ、「sip.uui-pk1」を使用して特定のパッケージpk1のサポートを示すことができます。
Proxies commonly apply policy to the presence of certain SIP header fields in requests by either passing them or removing them from requests. REQ-9 is met by allowing proxies and other intermediaries to remove UUI header fields in a request or response based on policy.
プロキシは通常、ポリシーをリクエスト内の特定のSIPヘッダーフィールドに渡すか、リクエストから削除することで、それらの存在にポリシーを適用します。 REQ-9は、プロキシや他の仲介者が、ポリシーに基づいて要求または応答のUUIヘッダーフィールドを削除できるようにすることで満たされます。
Carrying UUI data elements of at least 129 octets is trivial in the UUI header field, meeting REQ-11. Note that avoiding having very large UUI data elements is a good idea, as SIP header fields have traditionally not been large.
少なくとも129オクテットのUUIデータ要素を運ぶことは、REQ-11を満たすUUIヘッダーフィールドでは簡単です。 SIPヘッダーフィールドは従来は大きくなかったため、非常に大きなUUIデータ要素を使用しないことをお勧めします。
To meet REQ-12 for the redirection and referral use cases, the History-Info header field [RFC7044] can be used. In these retargeting cases, the changed Request-URI will be recorded in the History-Info header field along with the identity of the element that performed the retargeting.
リダイレクトと紹介のユースケースでREQ-12を満たすには、History-Infoヘッダーフィールド[RFC7044]を使用できます。これらのリターゲティングの場合、変更されたRequest-URIは、リターゲティングを実行した要素のIDとともにHistory-Infoヘッダーフィールドに記録されます。
The requirement for integrity protection in REQ-13 could be met by the use of an S/MIME signature over a subset of header fields, as defined in "SIP Header Privacy and Integrity using S/MIME: Tunneling SIP", Section 23.4 of RFC 3261. Note that the lack of deployment of S/MIME with SIP means that, in general, REQ-13 is not met. The requirement of REQ-14 for end-to-end privacy could be met using S/MIME or using encryption at the application layer. Note that the use of S/MIME to secure the UUI data will result in an additional body being added to the request. Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header field to meet REQ-15 for hop-by-hop security.
REQ-13の整合性保護の要件は、「S / MIMEを使用したSIPヘッダーのプライバシーと整合性：SIPのトンネリング」、RFCのセクション23.4で定義されているように、ヘッダーフィールドのサブセットでS / MIME署名を使用することで満たすことができます。 3261. SIPでのS / MIMEの展開がないことは、一般に、REQ-13が満たされていないことを意味することに注意してください。エンドツーエンドのプライバシーに対するREQ-14の要件は、S / MIMEを使用するか、アプリケーション層で暗号化を使用することで満たすことができます。 S / MIMEを使用してUUIデータを保護すると、リクエストに追加の本文が追加されることに注意してください。ホップ単位のトランスポート層セキュリティ（TLS）[RFC5246]により、ヘッダーフィールドはホップバイホップのセキュリティのためにREQ-15を満たすことができます。
This document defines a new SIP header field "User-to-User" to transport call control UUI data to meet the requirements in [RFC6567].
このドキュメントでは、[RFC6567]の要件を満たすように呼制御UUIデータを転送するための新しいSIPヘッダーフィールド「User-to-User」を定義しています。
To help tag and identify the UUI data used with this header field, "purpose", "content", and "encoding" header field parameters are defined. The "purpose" header field parameter identifies the package that defines the generation and usage of the UUI data for a particular application. The value of the "purpose" parameter is the package name, as registered in the "UUI Packages" subregistry defined in Section 6.3. For the case of interworking with the ISDN UUI service, the ISDN UUI service interworking package is used. The default value for the "purpose" header field is "isdn-uui" as defined in [RFC7434]. If the "purpose" header field parameter is not present, the ISDN UUI MUST be used. The "content" header field parameter identifies the actual content of the UUI data. If not present, the default content defined for the package MUST be used. Newly defined UUI packages MUST define or reference at least a default "content" value. The "encoding" header field parameter indicates the method of encoding the information in the UUI data associated with a particular "content" value. This specification only defines "encoding=hex". If the "encoding" header field parameter is not present, the default encoding defined for the package MUST be used.
このヘッダーフィールドで使用されるUUIデータにタグを付けて識別するために、「目的」、「コンテンツ」、および「エンコーディング」ヘッダーフィールドパラメータが定義されています。 「目的」ヘッダーフィールドパラメーターは、特定のアプリケーションのUUIデータの生成と使用を定義するパッケージを識別します。 「purpose」パラメータの値は、セクション6.3で定義されている「UUI Packages」サブレジストリに登録されているパッケージ名です。 ISDN UUIサービスとのインターワーキングの場合、ISDN UUIサービスインターワーキングパッケージが使用されます。 「目的」ヘッダーフィールドのデフォルト値は、[RFC7434]で定義されている「isdn-uui」です。 「目的」ヘッダーフィールドパラメータが存在しない場合は、ISDN UUIを使用する必要があります。 「コンテンツ」ヘッダーフィールドパラメータは、UUIデータの実際のコンテンツを識別します。存在しない場合は、パッケージに定義されているデフォルトのコンテンツを使用する必要があります。新しく定義されたUUIパッケージは、少なくともデフォルトの「コンテンツ」値を定義または参照する必要があります。 「encoding」ヘッダーフィールドパラメータは、特定の「content」値に関連付けられたUUIデータの情報をエンコードする方法を示します。この仕様では、「encoding = hex」のみを定義しています。 「encoding」ヘッダーフィールドパラメータが存在しない場合、パッケージに定義されているデフォルトのエンコーディングを使用する必要があります。
UUI data is considered an opaque series of octets. This mechanism MUST NOT be used to convey a URL or URI, since the Call-Info header field in [RFC3261] already supports this use case.
UUIデータは、不透明な一連のオクテットと見なされます。 [RFC3261]のCall-Infoヘッダーフィールドはすでにこのユースケースをサポートしているため、このメカニズムをURLまたはURIの伝達に使用してはなりません（MUST NOT）。
The UUI header field can be present in INVITE requests and responses and in BYE requests and responses. Note that when the UUI header is used in responses, it can only be utilized in end-to-end responses, e.g., 1xx (excluding 100), 2xx, and 3xx responses.
UUIヘッダーフィールドは、INVITE要求と応答、およびBYE要求と応答に存在できます。 UUIヘッダーが応答で使用される場合、エンドツーエンド応答でのみ使用できることに注意してください。たとえば、1xx（100を除く）、2xx、3xx応答などです。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 5234 and extends RFC 3261 (where token, quoted-string, and generic-param are defined).
次の構文仕様では、RFC 5234で説明されているようにAugmented Backus-Naur Form（ABNF）を使用し、RFC 3261（token、quoted-string、generic-paramが定義されている）を拡張しています。
UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
uui-value = uui-data *(SEMI uui-param)
uui-data = token / quoted-string
uui-param = pkg-param / cont-param / enc-param / generic-param
pkg-param = "purpose" EQUAL pkg-param-value
pkg-param-value = token
cont-param = "content" EQUAL cont-param-value
cont-param-value = token
enc-param = "encoding" EQUAL enc-param-value
enc-param-value = token / "hex"
Each package defines how many User-to-User header fields of each package may be present in a request or a response. A sender MAY include multiple User-to-User header fields, and a receiver MUST be prepared to receive multiple User-to-User header fields. Consistent with the rules of SIP syntax, the syntax defined in this document allows any combination of individual User-to-User header fields or User-to-User header fields with multiple comma separated UUI data elements. Any size limitations on the UUI data for a particular purpose are to be defined by the related UUI package.
各パッケージは、要求または応答に存在できる各パッケージのユーザー間ヘッダーフィールドの数を定義します。送信者は複数のユーザー間ヘッダーフィールドを含めることができ（MAY）、受信者は複数のユーザー間ヘッダーフィールドを受信できるように準備する必要があります。このドキュメントで定義されている構文では、SIP構文の規則に従って、個々のユーザー間ヘッダーフィールドまたはユーザー間ヘッダーフィールドとコンマで区切られた複数のUUIデータ要素を自由に組み合わせることができます。特定の目的のためのUUIデータのサイズ制限は、関連するUUIパッケージによって定義されます。
UAs SHALL ignore UUI data from packages or encoding that they do not understand.
UAは、理解できないパッケージまたはエンコーディングからのUUIデータを無視するものとします（SHALL）。
For redirection use cases, the header field is included (escaped) within the Contact URI. For referral use cases, the header field is included (escaped) within the Refer-To URI. For example, if a UA supports this specification, it SHOULD include any UUI data included in a redirection URI (if the UUI data and encoding is understood).
リダイレクトの使用例の場合、ヘッダーフィールドは連絡先URIに含まれます（エスケープされます）。紹介の使用例では、ヘッダーフィールドは参照先URIに含まれます（エスケープされます）。たとえば、UAがこの仕様をサポートしている場合、リダイレクトURIに含まれているすべてのUUIデータを含める必要があります（UUIデータとエンコーディングが理解されている場合）。
Note that redirection can occur multiple times to a request. Currently, UAs that support attended transfer support the ability to include a Replaces header field [RFC3891] into a Refer-To URI, and when acting upon this URI, UAs add the Replaces header field to the triggered INVITE. This sort of logic and behavior is utilized for the UUI header field (that is, the UUI header field is included in the triggered INVITE). The UA processing the REFER [RFC3515] or the 3xx response to the INVITE SHOULD support the UUI mechanism. If the REFER or redirect target does not support UUI, the UUI header will be discarded as per [RFC3261]. However, this may limit the utility of use cases that depend upon the UUI being supported by all elements.
リダイレクトはリクエストに対して複数回発生する可能性があることに注意してください。現在、在席転送をサポートするUAは、Replacesヘッダーフィールド[RFC3891]をRefer-To URIに含める機能をサポートしており、このURIに基づいて機能する場合、UAはReplacesヘッダーフィールドをトリガーされたINVITEに追加します。このようなロジックと動作は、UUIヘッダーフィールドに使用されます（つまり、UUIヘッダーフィールドはトリガーされたINVITEに含まれます）。 REFER [RFC3515]を処理するUAまたはINVITEへの3xx応答は、UUIメカニズムをサポートする必要があります（SHOULD）。 REFERまたはリダイレクトターゲットがUUIをサポートしない場合、[RFC3261]に従ってUUIヘッダーは破棄されます。ただし、これにより、すべての要素でサポートされているUUIに依存するユースケースのユーティリティが制限される場合があります。
Here is an example of an included User-to-User header field from the redirection response F2 of Figure 2 in [RFC6567]:
[RFC6567]の図2のリダイレクト応答F2に含まれているUser-to-Userヘッダーフィールドの例を次に示します。
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar>
</allOneLine>
The resulting INVITE F4 would contain:
結果のINVITE F4には以下が含まれます。
User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar
This specification defines hex encoding of UUI data. When the value of "hex" is used in the "encoding" parameter of a header field, the data is encoded using base16 encoding according to Section 8 of [RFC4648]. The hex-encoded value is normally represented using the "token" construction from RFC 3261, although the "quoted-string" construction is permitted, in which case the quotes MUST be ignored.
この仕様は、UUIデータの16進エンコーディングを定義します。ヘッダーフィールドの「エンコーディング」パラメータで「hex」の値が使用されている場合、データは[RFC4648]のセクション8に従ってbase16エンコーディングを使用してエンコードされます。 16進数でエンコードされた値は通常、RFC 3261の「トークン」構成を使用して表されますが、「引用文字列」の構成は許可されます。この場合、引用符は無視する必要があります。
If a canonicalized version of a normally case-insensitive hex encoded UUI data object is needed for a digital signature or integrity checking, then the base16 encoding with all upper case MUST be used.
通常は大文字と小文字を区別しない16進エンコードされたUUIデータオブジェクトの正規化されたバージョンがデジタル署名または整合性チェックに必要な場合は、すべて大文字のbase16エンコードを使用する必要があります。
It is important for the recipient of UUI data to know the identity of the UA that inserted the UUI data. In a request without a History-Info header field, the identity of the entity that inserted the UUI data will be assumed to be the source of the SIP message. For a SIP request, typically this is the UA identified by the URI in the From header field or a P-Asserted-Identity [RFC3325] header field. In a request with a History-Info header field, the recipient needs to parse the Targeted-to-URIs present (hi-targeted-to-uri defined in
UUIデータの受信者は、UUIデータを挿入したUAのIDを知ることが重要です。 History-Infoヘッダーフィールドのないリクエストでは、UUIデータを挿入したエンティティのIDがSIPメッセージのソースであると想定されます。 SIPリクエストの場合、これは通常、FromヘッダーフィールドのURIまたはP-Asserted-Identity [RFC3325]ヘッダーフィールドで識別されるUAです。 History-Infoヘッダーフィールドを含むリクエストでは、受信者は存在するTargeted-to-URIs（hi-targeted-to-uri defined in
[RFC7044]) to see if any included User-to-User header fields are present. If an included User-to-User header field is present and matches the UUI data in the request, this indicates that redirection has taken place, resulting in the inclusion of UUI data in the request. The inserter of the UUI data will be the UA identified by the Targeted-to-URI of the History-Info element prior to the element with the included UUI data. In a response, the inserter of the UUI data will be the identity of the UA that generated the response. Typically, this is the UA identified in the To header field of the response. Note that any updates to this identity by use of the SIP connected identity extension [RFC4916] or other identity modifiers will update this information.
[RFC7044]）含まれているUser-to-Userヘッダーフィールドが存在するかどうかを確認します。含まれているUser-to-Userヘッダーフィールドが存在し、リクエストのUUIデータと一致する場合、これはリダイレクトが行われたことを示しており、リクエストにUUIデータが含まれています。 UUIデータの挿入子は、含まれているUUIデータを持つ要素の前のHistory-Info要素のTargeted-to-URIによって識別されるUAです。応答では、UUIデータの挿入子は、応答を生成したUAのIDになります。通常、これは応答のToヘッダーフィールドで識別されるUAです。 SIP接続ID拡張[RFC4916]または他のID修飾子を使用してこのIDを更新すると、この情報が更新されることに注意してください。
For an example of History-Info and redirection, consider Figure 2 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, and the Terminating UA Alice. The INVITE F4 containing UUI data could be:
History-Infoとリダイレクションの例として、[RFC6567]の図2を検討してください。ここで、元のUAはキャロル、リダイレクターボブ、および終了UAアリスです。 UUIデータを含むINVITE F4は次のとおりです。
INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>
Without the redirection captured in the History-Info header field, Alice would conclude that the UUI data was inserted by Carol. However, the History-Info containing UUI data (index=1.1) indicates that the inserter was Bob (index=1).
History-Infoヘッダーフィールドでリダイレクトをキャプチャしないと、アリスはUUIデータがキャロルによって挿入されたと結論付けます。ただし、UUIデータ（index = 1.1）を含むHistory-Infoは、挿入者がBob（index = 1）であることを示しています。
To enable maintaining a record of the inserter identity of UUI data, UAs supporting this mechanism SHOULD support History-Info [RFC7044] and include Supported: histinfo in all requests and responses.
UUIデータの挿入者IDの記録を維持できるようにするには、このメカニズムをサポートするUAがHistory-Info [RFC7044]をサポートし（SHOULD）、すべての要求と応答にSupported：histinfoを含める必要があります。
If a border element such as a proxy or a Back-to-Back User Agent (B2BUA) removes a History-Info header field containing a User-to-User parameter, the UA consuming the UUI data may not be able at the SIP level to identify the source of the UUI data.
プロキシやバックツーバックユーザーエージェント（B2BUA）などの境界要素が、ユーザー間パラメーターを含むHistory-Infoヘッダーフィールドを削除すると、UUIデータを消費するUAがSIPレベルで実行できない場合があります。 UUIデータのソースを識別します。
UUI packages defined using this SIP UUI mechanism MUST follow the "Standards Action" guideline as defined in [RFC5226] and publish a Standards Track RFC that describes the usage. The CUSS WG chose to adopt this conservative policy while it considers other potential registration policies. Note that this mechanism is not suitable for the transport of arbitrary data between UAs. The following guidelines are provided to help determine if this mechanism is appropriate or not. The SIP UUI mechanism is applicable when all of the following conditions are met:
このSIP UUIメカニズムを使用して定義されたUUIパッケージは、[RFC5226]で定義されている「標準アクション」ガイドラインに従い、使用法を説明する標準トラックRFCを公開する必要があります。 CUSS WGは、他の潜在的な登録ポリシーを考慮しながら、この保守的なポリシーを採用することを選択しました。このメカニズムは、UA間の任意のデータの転送には適していないことに注意してください。次のガイドラインは、このメカニズムが適切かどうかを判断するために提供されています。 SIP UUIメカニズムは、次の条件がすべて満たされた場合に適用されます。
1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily SIP aware.
1. 情報は、SIPを使用したセッションのセットアップ中にアプリケーションによって生成および消費されますが、アプリケーションは必ずしもSIP対応ではありません。
2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of [RFC5727]).
2. これをサポートするSIPエンティティの動作は大幅に変更されていません（[RFC5727]のセクション4で説明）。
3. UAs are the generators and consumers of the UUI data. Proxies and other intermediaries may route based on the presence of a User-to-User header field or a particular package tag but do not otherwise consume or generate the UUI data.
3. UAは、UUIデータのジェネレーターとコンシューマーです。プロキシおよびその他の仲介者は、ユーザー間ヘッダーフィールドまたは特定のパッケージタグの存在に基づいてルーティングできますが、それ以外ではUUIデータを消費または生成しません。
4. There are no privacy issues associated with the information being transported (e.g., geolocation or emergency-related information are examples of inappropriate UUI data).
4. 転送される情報に関連するプライバシーの問題はありません（たとえば、地理位置情報や緊急関連情報は、不適切なUUIデータの例です）。
5. The UUI data is not being utilized for User-to-User Remote Procedure Calls (RPCs).
5. UUIデータは、ユーザー間リモートプロシージャコール（RPC）には使用されていません。
UUI packages define the semantics for a particular application usage of UUI data. The content defines the syntax of the UUI data, while the encoding defines the encoding of the UUI data for the content. Each content is defined as a stream of octets, which allows multiple encodings of that content. For example, packages may define:
UUIパッケージは、特定のアプリケーションでのUUIデータの使用に関するセマンティクスを定義します。コンテンツはUUIデータの構文を定義し、エンコーディングはコンテンツのUUIデータのエンコーディングを定義します。各コンテンツはオクテットのストリームとして定義され、そのコンテンツの複数のエンコーディングを可能にします。たとえば、パッケージは次のものを定義します。
1. The SIP methods and responses in which the UUI data may be present.
1. UUIデータが存在する可能性があるSIPメソッドおよび応答。
2. The maximum number of UUI data elements that may be inserted into a request or response. The default is one per encoding. Note that a UA may still receive a request with more than this maximum number due to redirection. The package needs to define how to handle this situation.
2. 要求または応答に挿入できるUUIデータ要素の最大数。デフォルトはエンコーディングごとに1つです。 UAは、リダイレクトのために、この最大数を超えるリクエストを受信する可能性があることに注意してください。パッケージは、この状況を処理する方法を定義する必要があります。
3. The default values for content and encoding if they are not present. If the same UUI data may be inserted multiple times with different encodings, the package needs to state this. A package may support and define multiple contents and their associated encodings and reuse contents defined by other packages.
3. コンテンツとエンコーディングが存在しない場合のデフォルト値。同じUUIデータが異なるエンコーディングで複数回挿入される可能性がある場合、パッケージはこれを示す必要があります。パッケージは、複数のコンテンツとそれらに関連付けられたエンコーディングをサポートおよび定義し、他のパッケージによって定義されたコンテンツを再利用できます。
4. Any size limitations on the UUI data. Size needs to be specified in terms of the octet stream output of the content, since the size of the resulting uui-data element will vary depending on the encoding scheme.
4. UUIデータのサイズ制限。結果のuui-data要素のサイズはエンコーディングスキームによって異なるため、コンテンツのオクテットストリーム出力に関してサイズを指定する必要があります。
A package MUST define a "purpose" header field value to identify the package in the coding. A package MUST describe the new application that is utilizing the UUI data and provide some use case examples. The default "content" value MUST be defined or referenced in another document for the package. Additional allowed contents MAY also be defined or referenced. Any restrictions on the size of the UUI data MUST be described. In addition, a package MAY define a media feature tag per [RFC3840] to indicate support for this UUI package. For example, the media feature tag "sip.uui-pk1" could be defined to indicate support for a UUI package named pk1. The definition of a new SIP option tag solely to identify support for a UUI package is NOT RECOMMENDED unless there are additional SIP behaviors needed to implement this feature.
パッケージは、コーディングでパッケージを識別するための「目的」ヘッダーフィールド値を定義する必要があります。パッケージは、UUIデータを利用する新しいアプリケーションを記述し、いくつかの使用例を提供する必要があります。デフォルトの「コンテンツ」値は、パッケージの別のドキュメントで定義または参照する必要があります。追加の許可されたコンテンツも定義または参照できます。 UUIデータのサイズの制限について説明する必要があります。さらに、パッケージはこのUUIパッケージのサポートを示すために[RFC3840]に従ってメディア機能タグを定義してもよい（MAY）。たとえば、メディア機能タグ「sip.uui-pk1」は、pk1という名前のUUIパッケージのサポートを示すように定義できます。この機能を実装するために必要な追加のSIP動作がない限り、UUIパッケージのサポートを識別するためだけの新しいSIPオプションタグの定義は推奨されません。
For an example UUI package definition, see [RFC7434].
UUIパッケージ定義の例については、[RFC7434]を参照してください。
New "content" values MUST describe the semantics of the UUI data and valid encodings, and give some example use cases. A previously defined UUI content value can be used in a new package. In this case, the semantics and usage of the content by the new package is defined within the new package. New UUI content types cannot be added to existing packages -- instead, a new package would need to be defined. New content values that are defined are added to the IANA registry with a Standards Track RFC, which needs to discuss the issues in this section. If no new encoding value is defined for a content, the encoding defaults to "hex" as defined in this document. In this case, the "hex" value will be explicitly stated via the encoding parameter as the encoding for the content.
新しい「コンテンツ」値は、UUIデータのセマンティクスと有効なエンコーディングを記述し、いくつかの使用例を提供する必要があります。以前に定義されたUUIコンテンツ値は、新しいパッケージで使用できます。この場合、新しいパッケージによるコンテンツのセマンティクスと使用法は、新しいパッケージ内で定義されます。新しいUUIコンテンツタイプを既存のパッケージに追加することはできません。代わりに、新しいパッケージを定義する必要があります。定義された新しいコンテンツ値は、Standards Track RFCを使用してIANAレジストリに追加されます。このセクションで問題を議論する必要があります。コンテンツに新しいエンコード値が定義されていない場合、このドキュメントで定義されているように、エンコードはデフォルトで「hex」に設定されます。この場合、「hex」値は、コンテンツのエンコーディングとしてencodingパラメータを介して明示的に示されます。
New "encoding" values associated with a new content MUST reference a specific encoding scheme (such as "hex", which is defined in this specification) or define the new encoding scheme. A previously defined UUI encoding value can be used with a newly defined content. In this case, the usage of the encoding is defined by the content definition. New UUI encodings cannot be added to existing contents -- instead, a new content would need to be defined. Newly defined encoding values are added to the IANA registry with a Standards Track RFC, which needs to discuss the issues in this section.
新しいコンテンツに関連付けられた新しい「エンコーディング」値は、特定のエンコーディングスキーム（この仕様で定義されている「hex」など）を参照するか、新しいエンコーディングスキームを定義する必要があります。以前に定義されたUUIエンコーディング値は、新しく定義されたコンテンツで使用できます。この場合、エンコーディングの使用はコンテンツ定義によって定義されます。新しいUUIエンコーディングを既存のコンテンツに追加することはできません。代わりに、新しいコンテンツを定義する必要があります。新しく定義されたエンコーディング値は、Standards Track RFCを使用してIANAレジストリに追加されます。このセクションで問題を議論する必要があります。
This document defines a new SIP header field named "User-to-User".
このドキュメントでは、「User-to-User」という名前の新しいSIPヘッダーフィールドを定義しています。
The following row has been added to the "Header Fields" section of the SIP parameter registry:
次の行が、SIPパラメーターレジストリの[ヘッダーフィールド]セクションに追加されました。
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFC7433] |
+------------------+--------------+-----------+
This document defines the parameters for the header field defined in the preceding section. The header field "User-to-User" can contain the parameters "encoding", "content", and "purpose".
このドキュメントでは、前のセクションで定義したヘッダーフィールドのパラメーターを定義します。ヘッダーフィールド「User-to-User」には、パラメーター「encoding」、「content」、および「purpose」を含めることができます。
The following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
次の行が、SIPパラメーターレジストリの[ヘッダーフィールドパラメーターとパラメーター値]セクションに追加されました。
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User | encoding | Yes | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | content | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
| User-to-User | purpose | No | [RFC7433] |
+------------------+----------------+-------------------+-----------+
This specification establishes the "UUI Packages" subregistry under <http://www.iana.org/assignments/sip-parameters>.
この仕様は、<http://www.iana.org/assignments/sip-parameters>の下にある「UUIパッケージ」サブレジストリを確立します。
The descriptive text for this subregistry is:
このサブレジストリの説明テキストは次のとおりです。
UUI packages provide information about the usage of the UUI data in a User-to-User header field [RFC7433].
UUIパッケージは、User-to-Userヘッダーフィールド[RFC7433]でUUIデータの使用に関する情報を提供します。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
このレジストリの登録ポリシーは、[RFC5226]で定義されている「標準アクション」です。
+------------+------------------------------------------+-----------+
| Package | Description | Reference |
+------------+------------------------------------------+-----------+
This specification establishes the "UUI Content Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters>.
この仕様は、<http://www.iana.org/assignments/sip-parameters>の下にある「UUIコンテンツパラメータ」サブレジストリを確立します。
The descriptive text for this subregistry is:
このサブレジストリの説明テキストは次のとおりです。
UUI content provides information about the content of the UUI data in a User-to-User header field [RFC7433].
UUIコンテンツは、ユーザー間ヘッダーフィールド[RFC7433]のUUIデータのコンテンツに関する情報を提供します。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
このレジストリの登録ポリシーは、[RFC5226]で定義されている「標準アクション」です。
+------------+------------------------------------------+-----------+
| Content | Description | Reference |
+------------+------------------------------------------+-----------+
This specification establishes the "UUI Encoding Parameters" subregistry under <http://www.iana.org/assignments/sip-parameters> and initiates its population with the table below.
この仕様は、<http://www.iana.org/assignments/sip-parameters>の下の「UUIエンコーディングパラメータ」サブレジストリを確立し、以下の表を使用してその作成を開始します。
The descriptive text for this subregistry is:
このサブレジストリの説明テキストは次のとおりです。
UUI encoding provides information about the encoding of the UUI data in a User-to-User header field [RFC7433].
UUIエンコーディングは、User-to-Userヘッダーフィールド[RFC7433]のUUIデータのエンコーディングに関する情報を提供します。
The registration policy for this registry is "Standards Action" as defined in [RFC5226].
このレジストリの登録ポリシーは、[RFC5226]で定義されている「標準アクション」です。
+-----------+-------------------------------------------+-----------+
| Encoding | Description | Reference |
+-----------+-------------------------------------------+-----------+
| hex | The UUI data is encoded using hexadecimal | [RFC7433] |
+-----------+-------------------------------------------+-----------+
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261].
この仕様は、[RFC3261]のセクション27.1のガイドラインに従って、新しいSIPオプションタグを登録します。
This document defines the SIP option tag "uui".
このドキュメントでは、SIPオプションタグ「uui」を定義しています。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行が、SIPパラメータレジストリの「オプションタグ」セクションに追加されました。
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| uui | This option tag is used to indicate that | [RFC7433] |
| | a UA supports and understands the | |
| | User-to-User header field. | |
+------------+------------------------------------------+-----------+
UUI data can potentially carry sensitive information that might require confidentiality protection for privacy or integrity protection from third parties that may wish to read or modify the UUI data. The three security models described in [RFC6567] may be applicable for the UUI mechanism.
UUIデータは、UUIデータの読み取りまたは変更を望む第三者からのプライバシーまたは整合性保護のための機密保護を必要とする可能性のある機密情報を運ぶ可能性があります。 [RFC6567]で説明されている3つのセキュリティモデルは、UUIメカニズムに適用できる場合があります。
One model treats the SIP layer as untrusted and requires end-to-end integrity protection and/or encryption. This model can be achieved by providing these security services at a layer above SIP. In this case, applications are encouraged to use their own integrity and/or encryption mechanisms before passing it to the SIP layer.
1つのモデルはSIP層を信頼できないものとして扱い、エンドツーエンドの整合性保護や暗号化を必要とします。このモデルは、SIPの上のレイヤーでこれらのセキュリティサービスを提供することで実現できます。この場合、アプリケーションはそれをSIP層に渡す前に、独自の整合性および/または暗号化メカニズムを使用することをお勧めします。
The second approach is for the application to pass the UUI without any protection to the SIP layer and require the SIP layer to provide this security. This approach is possible in theory, although its practical use would be extremely limited. To preserve multi-hop or end-to-end confidentiality and integrity of UUI data, approaches using S/MIME or IPsec can be used, as discussed in the review of REQ-13 and REQ-14 in Section 3 of this document. However, the lack of deployment of these mechanisms means that applications cannot in general rely on them being present.
2番目の方法は、アプリケーションがSIP層を保護せずにUUIを渡し、SIP層がこのセキュリティを提供することを要求することです。このアプローチは理論的には可能ですが、実際の使用は非常に限られています。このドキュメントのセクション3のREQ-13とREQ-14のレビューで説明されているように、UUIデータのマルチホップまたはエンドツーエンドの機密性と整合性を維持するために、S / MIMEまたはIPsecを使用するアプローチを使用できます。ただし、これらのメカニズムが配備されていないことは、アプリケーションが一般的にそれらの存在に依存できないことを意味します。
The third model utilizes a trust domain and relies on perimeter security at the SIP layer. This is the security model of the PSTN and ISDN where UUI is commonly used today. This approach uses hop-by-hop security mechanisms and relies on border elements for filtering and application of policy. Standard deployed SIP security mechanisms such as TLS transport offer privacy and integrity protection properties on a hop-by-hop basis at the SIP layer.
3番目のモデルは、信頼ドメインを利用し、SIPレイヤーの境界セキュリティに依存しています。これは、現在UUIが一般的に使用されているPSTNおよびISDNのセキュリティモデルです。このアプローチは、ホップバイホップのセキュリティメカニズムを使用し、ポリシーのフィルタリングと適用を境界要素に依存しています。 TLSトランスポートなどの標準でデプロイされたSIPセキュリティメカニズムは、SIPレイヤーでホップバイホップベースでプライバシーと整合性保護のプロパティを提供します。
If the UUI data was included by the UA originator of the SIP request or response, normal SIP mechanisms can be used to determine the identity of the inserter of the UUI data. If the UUI data was included by a UA that was not the originator of the request, a History-Info header field can be used to determine the identity of the inserter of the UUI data. UAs can apply policy based on the origin of the UUI data using this information. In short, the UUI data included in an INVITE can be trusted as much as the INVITE itself can be trusted.
UUIデータがSIP要求または応答のUA発信者によって含まれていた場合、通常のSIPメカニズムを使用して、UUIデータの挿入者のIDを判別できます。リクエストの発信者ではないUAがUUIデータを含めた場合、History-Infoヘッダーフィールドを使用して、UUIデータの挿入者のIDを判別できます。 UAは、この情報を使用して、UUIデータの発信元に基づいてポリシーを適用できます。つまり、INVITEに含まれるUUIデータは、INVITE自体が信頼できるのと同じくらい信頼できます。
Note that it is possible that this mechanism could be used as a covert communication channel between UAs, conveying information unknown to the SIP network.
このメカニズムが、UA間の秘密通信チャネルとして使用され、SIPネットワークに未知の情報を伝達する可能性があることに注意してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515] Sparks、R。、「The Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月、<http://www.rfc-editor.org/info/rfc3515>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Indicating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月、<http：//www.rfc-editor。 org / info / rfc3840>。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「The Session Initiation Protocol（SIP） "Replaces" Header」、RFC 3891、2004年9月、<http://www.rfc-editor.org / info / rfc3891>。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月、<http://www.rfc-editor.org/info/rfc4474 >。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007, <http://www.rfc-editor.org/info/rfc4916>.
[RFC4916] Elwell、J。、「Connected Identity in the Session Initiation Protocol（SIP）」、RFC 4916、2007年6月、<http://www.rfc-editor.org/info/rfc4916>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044] Barnes、M.、Audet、F.、Schubert、S.、van Elburg、J。、およびC. Holmberg、「An an Extension to the Session Initiation Protocol（SIP）for Request History Information」、RFC 7044、2月2014、<http://www.rfc-editor.org/info/rfc7044>。
[RFC7434] Drage, K. and A. Johnston, "Interworking ISDN Call Control User Information with SIP", RFC 7434, January 2015, <http://www.rfc-editor.org/info/rfc7434>.
[RFC7434] Drage、K.およびA. Johnston、「Interworking ISDN Call Control User Information with SIP」、RFC 7434、2015年1月、<http://www.rfc-editor.org/info/rfc7434>。
[Q1980] ITU-T, "The Narrowband Signalling Syntax (NSS) - Syntax Definition", ITU-T Recommendation Q.1980.1, <http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/ q1980.1/q1980.1.html>.
[Q1980] ITU-T、「The Narrowband Signaling Syntax（NSS）-Syntax Definition」、ITU-T Recommendation Q.1980.1、<http://www.itu.int/itudoc/itu-t/aap/sg11aap/history / q1980.1 / q1980.1.html>。
[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>。
[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>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼できるネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、2002年11月、<http：// www。 rfc-editor.org/info/rfc3325>。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002, <http://www.rfc-editor.org/info/rfc3372>.
[RFC3372] Vemuri、A.およびJ. Peterson、「Session Initiation Protocol for Telephones（SIP-T）：Context and Architectures」、BCP 63、RFC 3372、2002年9月、<http://www.rfc-editor.org / info / rfc3372>。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006, <http://www.rfc-editor.org/info/rfc4475>.
[RFC4475] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J.、and H. Schulzrinne、 "Session Initiation Protocol（SIP）Torture Test Messages"、RFC 4475、May 2006、<http：/ /www.rfc-editor.org/info/rfc4475>。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010, <http://www.rfc-editor.org/info/rfc5727>.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月、< http://www.rfc-editor.org/info/rfc5727>。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011, <http://www.rfc-editor.org/info/rfc6086>.
[RFC6086] Holmberg、C.、Berger、E。、およびH. Kaplan、「Session Initiation Protocol（SIP）INFO Method and Package Framework」、RFC 6086、2011年1月、<http://www.rfc-editor.org / info / rfc6086>。
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP", RFC 6567, April 2012, <http://www.rfc-editor.org/info/rfc6567>.
[RFC6567] Johnston、A。およびL. Liess、「SIPでユーザー間通話制御情報を転送するための問題ステートメントと要件」、RFC 6567、2012年4月、<http://www.rfc-editor.org/ info / rfc6567>。
Two other possible mechanisms for transporting UUI data will be described: MIME body and URI parameter transport.
UUIデータを転送するための他の2つの可能なメカニズム、MIME本文とURIパラメータの転送について説明します。
Since the INFO method [RFC6086] was developed for ISDN User Part (ISUP) interworking of User-to-User Information, it might seem to be the logical choice here. For non-call control User-to-User Information, INFO can be utilized for end-to-end transport. However, for transport of call control User-to-User Information, INFO can not be used. As the call flows in [RFC6567] show, the information is related to an attempt to establish a session and needs to be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.
INFOメソッド[RFC6086]は、ユーザー間情報のISDNユーザーパート（ISUP）インターワーキング用に開発されたため、ここでは論理的な選択のように見えるかもしれません。非通話制御のユーザー間情報の場合、INFOをエンドツーエンドの転送に利用できます。ただし、通話制御のユーザー間情報の転送では、INFOは使用できません。 [RFC6567]のコールフローが示すように、情報はセッションを確立する試みに関連しており、セッションセットアップ要求（INVITE）、そのINVITEへの応答、またはセッション終了要求とともに渡す必要があります。その結果、これらの場合にINFOを使用することはできません。
Other protocols have the ability to transport UUI data. For example, consider the ITU-T Recommendation Q.931 User-user information element [Q931] and the ITU-T Recommendation Q.763 User-to-User information parameter [Q763]. In addition, the Narrowband Signalling System (NSS) [Q1980] is also able to transport UUI data. Should one of these protocols be in use, and present in both User Agents, then utilizing these other protocols to transport UUI data might be a logical solution. Essentially, this is just adding an additional layer in the protocol stack. In these cases, SIP is not transporting the UUI data; it is encapsulating another protocol, and that protocol is transporting the UUI data. Once a mechanism to transport that other protocol using SIP exists, the UUI data transport function is essentially obtained without any additional effort or work.
他のプロトコルには、UUIデータを転送する機能があります。たとえば、ITU-T勧告Q.931のユーザーとユーザーの情報要素[Q931]とITU-T勧告Q.763のユーザー間情報パラメーター[Q763]について考えてみます。さらに、Narrowband Signaling System（NSS）[Q1980]もUUIデータを転送できます。これらのプロトコルの1つが使用中で、両方のユーザーエージェントに存在する場合、これらの他のプロトコルを利用してUUIデータを転送することは、論理的な解決策になる可能性があります。基本的に、これはプロトコルスタックにレイヤーを追加するだけです。これらの場合、SIPはUUIデータを転送しません。それは別のプロトコルをカプセル化しており、そのプロトコルはUUIデータを転送しています。 SIPを使用して他のプロトコルを転送するメカニズムが存在すると、UUIデータ転送機能は基本的に、追加の作業や作業なしで取得されます。
However, the CUSS working group believes, consistent with its charter, that SIP needs to have its own native UUI data transport mechanism. It is not reasonable for a SIP UA to have to implement another entire protocol (either ISDN or NSS, for example) just to get the very simple UUI data transport service. Of course, this work does not preclude anyone from using other protocols with SIP to transport UUI data.
ただし、CUSSワーキンググループは、その憲章に従い、SIPには独自のネイティブUUIデータ転送メカニズムが必要であると考えています。非常に単純なUUIデータ転送サービスを取得するためだけに、SIP UAが別のプロトコル全体（たとえば、ISDNまたはNSS）を実装する必要があるのは合理的ではありません。もちろん、この作業は他のプロトコルをSIPで使用してUUIデータを転送することを妨げるものではありません。
One method of transport is to use a MIME body. This is in keeping with the Session Initiation Protocol for Telephones (SIP-T) architecture [RFC3372] in which MIME bodies are used to transport ISUP information. Since the INVITE will normally have a Session Description Protocol (SDP) message body, the resulting INVITE with SDP and UUI data will be multipart MIME. This is not ideal as many SIP UAs do not support multipart MIME INVITEs.
トランスポートの1つの方法は、MIME本文を使用することです。これは、MIME本体がISUP情報の転送に使用される電話用セッション開始プロトコル（SIP-T）アーキテクチャ[RFC3372]に準拠しています。通常、INVITEにはセッション記述プロトコル（SDP）メッセージ本文があるため、SDPおよびUUIデータを含む結果のINVITEはマルチパートMIMEになります。多くのSIP UAはマルチパートMIME INVITEをサポートしていないため、これは理想的ではありません。
A bigger problem is the insertion of a UUI message body by a redirect server or in a REFER. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. Currently, the authors are not aware of any UAs that support this capability today for any body type. As such, the complete set of semantics for this operation would need to be determined and defined. Some issues will need to be resolved, such as, do all the Content-* header fields have to be included as well? And, what if the included Content-Length does not agree with the included body?
より大きな問題は、リダイレクトサーバーまたはREFERでのUUIメッセージ本文の挿入です。本文は、3xx応答のContact URIまたはREFERのRefer-To URIでエンコードする必要があります。現在、作成者は、現在、どのボディタイプについてもこの機能をサポートするUAを認識していません。そのため、この操作のセマンティクスの完全なセットを決定して定義する必要があります。すべてのContent- *ヘッダーフィールドも含める必要があるなど、いくつかの問題を解決する必要がありますか？また、含まれているContent-Lengthが含まれている本文と一致しない場合はどうなりますか？
Since proxies cannot remove a body from a request or response, it is not clear how this mechanism could meet REQ-9.
プロキシはリクエストまたはレスポンスから本文を削除できないため、このメカニズムがどのようにREQ-9に対応できるかは明確ではありません。
The requirement for integrity protection could be met by the use of an S/MIME signature over the body, as defined in "Securing MIME bodies", Section 23.3 of RFC 3261. Alternatively, this could be achieved using [RFC4474]. The requirement for end-to-end privacy could be met using S/MIME encryption or using encryption at the application layer. However, note that neither S/MIME or RFC 4474 enjoys deployment in SIP today.
整合性保護の要件は、RFC 3261のセクション23.3の「MIMEボディの保護」で定義されているように、ボディにS / MIME署名を使用することで満たすことができます。あるいは、これは[RFC4474]を使用して実現できます。エンドツーエンドのプライバシー要件は、S / MIME暗号化またはアプリケーション層での暗号化を使用して満たすことができます。ただし、S / MIMEもRFC 4474も、今日のSIPでの展開を楽しんでいないことに注意してください。
An example:
例：
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, although the authors do not have a specific mechanism to propose. Meeting REQ-3 is problematic but not impossible for this mechanism. However, this mechanism does not seem to be able to meet REQ-9.
したがって、MIMEボディアプローチは、REQ-1、REQ-2、REQ-4、REQ-5、REQ-7、REQ-11、REQ-13、およびREQ-14を満たします。著者は提案する特定のメカニズムを持っていませんが、REQ-12を満たすことは可能であるようです。 REQ-3を満たすことは問題がありますが、このメカニズムでは不可能ではありません。ただし、このメカニズムはREQ-9を満たすことができないようです。
Another proposed approach is to encode the UUI data as a URI parameter. This UUI parameter could be included in a Request-URI or in the Contact URI or Refer-To URI. It is not clear how it could be transported in a response that does not have a Request-URI, or in BYE requests or responses.
別の提案されたアプローチは、UUIデータをURIパラメータとしてエンコードすることです。このUUIパラメータは、Request-URIまたはContact URIまたはRefer-To URIに含めることができます。 Request-URIがない応答、またはBYE要求または応答でどのように転送されるかは明確ではありません。
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT
6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
An INVITE sent to this Contact URI would contain UUI data in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter carried in a Request-URI will not survive retargeting by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is included with an Address of Record instead of a Contact URI, the URI parameter in the Request-URI will not be copied over to the Contact URI, resulting in the loss of the information. Note that if this same URI was present in a Refer-To header field, the same loss of information would occur.
このContact URIに送信されるINVITEは、INVITEのRequest-URIにUUIデータを含みます。 [RFC6567]の図2に示されているように、URIパラメータには、Request-URIに含まれるURIパラメータがプロキシによるリターゲティングに耐えられないという欠点があります。つまり、URIがContact URIではなくRecord of Recordに含まれている場合、Request-URIのURIパラメーターはContact URIにコピーされず、情報が失われます。この同じURIがRefer-Toヘッダーフィールドに存在する場合、同じ情報の損失が発生することに注意してください。
The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and REQ-11. It is possible the approach could meet REQ-12 and REQ-13. The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and REQ-14.
URIパラメータアプローチは、REQ-3、REQ-5、REQ-7、REQ-9、およびREQ-11を満たします。アプローチがREQ-12およびREQ-13に適合する可能性があります。このメカニズムは、REQ-1、REQ-2、REQ-4、およびREQ-14を満たしているようには見えません。
Acknowledgments
謝辞
Joanne McMillen was a major contributor and coauthor of earlier versions of this document. Thanks to Paul Kyzivat for his contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura Liess for their review of the document. The authors wish to thank Roland Jesske, Celine Serrut-Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments. Thanks to Scott Kelly and Joel Halpern for their reviews.
Joanne McMillenは、このドキュメントの以前のバージョンの主要な寄稿者および共著者でした。 16進エンコーディングルールの貢献をしてくれたPaul Kyzivatに感謝します。ドキュメントをレビューしてくれたSpencer Dawkins、Keith Drage、Vijay Gurbani、Laura Liessに感謝します。著者は、コメントを寄せてくれたRoland Jesske、Celine Serrut-Valette、Francois Audet、Denis Alexeitsev、Paul Kyzivat、Cullen Jennings、Mahalingam Maniに感謝します。 Scott KellyとJoel Halpernのレビューに感謝します。
Authors' Addresses
著者のアドレス
Alan Johnston Avaya St. Louis, MO 63124 United States
あぁん じょｈんｓとん あゔぁや Ｓｔ。 ぉういｓ、 も ６３１２４ うにてｄ Ｓたてｓ
EMail: alan.b.johnston@gmail.com
James Rafferty Human Communications Norfolk, MA 02056 United States
James Rafferty Human Communications Norfolk、MA 02056 United States
EMail: jay@humancomm.com