Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6086 Ericsson
Obsoletes: 2976 E. Burger
Category: Standards Track Georgetown University
ISSN: 2070-1721 H. Kaplan
Acme Packet
January 2011
Session Initiation Protocol (SIP) INFO Method and Package Framework
セッション開始プロトコル（SIP）INFOメソッドおよびパッケージのフレームワーク
Abstract
抽象
This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document.
この文書では、セッション開始プロトコル（SIP）、およびインフォパッケージのメカニズムのために、方法、INFOを定義します。この文書は、下位互換性のためにRFC 2976.を時代遅れ、この文書はまた、以前にRFC 2976で定義された使用と互換性があるINFO方法の使用の「レガシー」モードを指定し、このドキュメントの「レガシーINFO使用法」と呼びます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc6086.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6086で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Motivation ......................................................4
3. Applicability and Backward Compatibility ........................5
4. The INFO Method .................................................6
4.1. General ....................................................6
4.2. INFO Request ...............................................6
4.2.1. INFO Request Sender .................................6
4.2.2. INFO Request Receiver ...............................7
4.2.3. SIP Proxies .........................................8
4.3. INFO Message Body ..........................................8
4.3.1. INFO Request Message Body ...........................8
4.3.2. INFO Response Message Body ..........................9
4.4. Order of Delivery ..........................................9
5. Info Packages ...................................................9
5.1. General ....................................................9
5.2. User Agent Behavior .......................................10
5.2.1. General ............................................10
5.2.2. UA Procedures ......................................10
5.2.3. Recv-Info Header Field Rules .......................11
5.2.4. Info Package Fallback Rules ........................12
5.3. REGISTER Processing .......................................12
6. Formal INFO Method Definition ..................................13
6.1. INFO Method ...............................................13
7. INFO Header Fields .............................................15
7.1. General ...................................................15
7.2. Info-Package Header Field .................................15
7.3. Recv-Info Header Field ....................................16
8. Info Package Considerations ....................................16
8.1. General ...................................................16
8.2. Appropriateness of Info Package Usage .....................16
8.3. INFO Request Rate and Volume ..............................16
8.4. Alternative Mechanisms ....................................17
8.4.1. Alternative SIP Signaling Plane Mechanisms .........17
8.4.2. Media Plane Mechanisms .............................18
8.4.3. Non-SIP-Related Mechanisms .........................19
9. Syntax .........................................................19
9.1. General ...................................................19
9.2. ABNF ......................................................19
10. Info Package Requirements .....................................20
10.1. General ..................................................20
10.2. Overall Description ......................................20
10.3. Applicability ............................................20
10.4. Info Package Name ........................................21
10.5. Info Package Parameters ..................................21
10.6. SIP Option-Tags ..........................................22
10.7. INFO Message Body Parts ..................................22
10.8. Info Package Usage Restrictions ..........................22
10.9. Rate of INFO Requests ....................................23
10.10. Info Package Security Considerations ....................23
10.11. Implementation Details ..................................23
10.12. Examples ................................................24
11. IANA Considerations ...........................................24
11.1. Update to Registration of SIP INFO Method ................24
11.2. Registration of the Info-Package Header Field ............24
11.3. Registration of the Recv-Info Header Field ...............24
11.4. Creation of the Info Packages Registry ...................25
11.5. Registration of the Info-Package Content-Disposition .....25
11.6. SIP Response Code 469 Registration .......................26
12. Examples ......................................................26
12.1. Indication of Willingness to Receive INFO Requests
for Info Packages ........................................26
12.1.1. Initial INVITE Request ............................26
12.1.2. Target Refresh ....................................27
12.2. INFO Request Associated with Info Package ................28
12.2.1. Single Payload ....................................28
12.2.2. Multipart INFO ....................................28
13. Security Considerations .......................................30
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................32
Appendix A. Acknowledgements .....................................35
This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261].
この文書では、セッション開始プロトコル（SIP）[RFC3261]のための、方法、INFOを定義します。
The purpose of the INFO message is to carry application level information between endpoints, using the SIP dialog signaling path. Note that the INFO method is not used to update characteristics of a SIP dialog or session, but to allow the applications that use the SIP session to exchange information (which might update the state of those applications).
INFOメッセージの目的は、SIPダイアログのシグナリングパスを使用して、エンドポイント間のアプリケーションレベルの情報を搬送することです。 INFOメソッドはSIPダイアログまたはセッションの特性を更新するために使用されていないが、SIPセッションを使用するアプリケーションは、（それらのアプリケーションの状態を更新するかもしれない）情報を交換できるようにすることに留意されたいです。
Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages, or outside an existing dialog.
INFOメソッドを使用すると、別のダイアログの使用を構成するものではありません。 INFOメッセージは常にの一部であり、招待ダイアログの使用[RFC5057]、の運命を共有しています。 INFOメッセージは、他のダイアログ用法の一部として、または既存のダイアログ外に送信することはできません。
This document also defines an Info Package mechanism. An Info Package specification defines the content and semantics of the information carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for user agents (UAs) to indicate for which Info Packages they are willing to receive INFO requests, and which Info Package a specific INFO request is associated with.
また、このドキュメントでは、インフォパッケージのメカニズムを定義します。情報パッケージの仕様は、情報パッケージに関連付けられたINFOメッセージで搬送される情報の内容と意味論を定義します。インフォパッケージのメカニズムは、インフォパッケージは、彼らがINFO要求を受け取るために喜んでいる、そしてその情報パッケージ固有INFO要求が関連付けられているために示すために、ユーザエージェント（UAS）のための方法を提供します。
A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set during the lifetime of the invite dialog usage.
UAは、そのための情報は、INFO要求を受信する意思があるパッケージ示すために、あたりのダイアログベースで、Recv関数-Infoヘッダーフィールドを使用しています。 UAは、ダイアログ確立中の情報パッケージの初期セットを示すことができ、招待ダイアログの使用の寿命の間に新しいセットを示すことができます。
NOTE: A UA can use an empty Recv-Info header field (a header field without a value) to indicate that it is not willing to receive INFO requests for any Info Package, while still informing other UAs that it supports the Info Package mechanism.
注：まだそれはインフォパッケージのメカニズムをサポートしている他のUAを通知しながら、UAは、どんな情報パッケージのためのINFO要求を受け取ることを望んでいないことを示すために（値なしヘッダフィールド）空のRecv-Infoヘッダーフィールドを使用することができます。
When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with the request. One particular INFO request can only be associated with a single Info Package.
UAは、INFO要求を送信すると、それは情報パッケージは、要求に関連付けられているかを示すためにインフォパッケージヘッダフィールドを使用します。一つの特定のINFO要求は、単一の情報パッケージに関連付けることができます。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A number of applications, standardized and proprietary, make use of the INFO method as it was previously defined in RFC 2976 [RFC2976], here referred to as "legacy INFO usage". These include but are not limited to the following:
それは、以前ここで、RFC 2976 [RFC2976]で定義された「レガシーINFOの使用」と呼ばれたように、標準化と独自のアプリケーションの数は、INFOメソッドを利用します。これらとしては、以下に限定されません：
o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP message bodies. ITU-T and the Third Generation Partnership Project (3GPP) have specified similar procedures.
O RFC 3372 [RFC3372]は、SIPメッセージボディ内のISDNユーザ部（ISUP）のカプセル化を指定します。 ITU-Tと第三世代パートナーシッププロジェクト（3GPP）は、同様の手順を指定しています。
o [ECMA-355] specifies the encapsulation of "QSIG" in SIP message bodies.
O [ECMA-355]は、SIPメッセージボディ内の "QSIG" のカプセル化を指定します。
o RFC 5022 [RFC5022] specifies how INFO is used as a transport mechanism by the Media Server Control Markup Language (MSCML) protocol. MSCML uses an option-tag in the Require header field to ensure that the receiver understands the INFO content.
O RFC 5022 [RFC5022]は情報をメディアサーバ制御マークアップ言語（MSCML）プロトコルによってトランスポート機構として使用される方法を指定します。 MSCMLは、受信機がINFOコンテンツを理解していることを確認するために必要なヘッダフィールドにオプションタグを使用します。
o RFC 5707 [RFC5707] specifies how INFO is used as a transport mechanism by the Media Server Markup Language (MSML) protocol.
O RFC 5707 [RFC5707]は情報をメディアサーバマークアップ言語（MSML）プロトコルによってトランスポート機構として使用される方法を指定します。
o Companies have been using INFO messages in order to request fast video update. Currently, a standardized mechanism, based on the Real-time Transport Control Protocol (RTCP), has been specified in RFC 5168 [RFC5168].
O企業が速い映像の更新を要求するために、INFOメッセージを使用してきました。現在、リアルタイムトランスポート制御プロトコル（RTCP）に基づいて標準化されたメカニズムは、RFC 5168 [RFC5168]で指定されています。
o Companies have been using INFO messages in order to transport Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are proprietary and have not been standardized.
O企業はデュアルトーン多重周波数（DTMF）トーンを輸送するために、INFOメッセージを使用してきました。すべてのメカニズムは独自であり、標準化されていません。
Some legacy INFO usages are also recognized as being shortcuts to more appropriate and flexible mechanisms.
一部のレガシーINFOの使用法は、より適切かつ柔軟なメカニズムへのショートカットであると認識されています。
Furthermore, RFC 2976 did not define mechanisms that would enable a SIP UA to indicate (1) the types of applications and contexts in which the UA supports the INFO method or (2) the types of applications and contexts with which a specific INFO message is associated.
また、RFC 2976は、UAは、INFOメソッドをサポートしているか、（2）特定のINFOメッセージであるアプリケーションおよびコンテキストの種類れるアプリケーションおよびコンテキストの（1）のタイプを示すために、SIP UAを可能にするメカニズムを定義していません関連します。
Because legacy INFO usages do not have associated Info Packages, it is not possible to use the Recv-Info and Info-Package header fields with legacy INFO usages. That is, a UA cannot use the Recv-Info header field to indicate for which legacy INFO usages it is willing to receive INFO requests, and a UA cannot use the Info-Package header field to indicate with which legacy INFO usage an INFO request is associated.
レガシーINFOの使用法は、関連する情報のパッケージを持っていないので、レガシーINFOの使用法とのRecv-情報およびインフォパッケージのヘッダフィールドを使用することはできません。つまり、UAは、レガシーINFOは、INFO要求を受信する意思がある建物内の企業、およびUAは、INFO要求があるレガシーINFOの使用を示すために、インフォパッケージのヘッダフィールドを使用できないために示すためのRecv-Infoヘッダーフィールドを使用することはできません関連します。
Due to the problems described above, legacy INFO usages often require static configuration to indicate the types of applications and contexts for which the UAs support the INFO method, and the way they handle application information transported in INFO messages. This has caused interoperability problems in the industry.
上記の問題のために、レガシーINFOの使用法は、多くの場合、UAはINFOメソッドをサポートするためのアプリケーションやコンテキストの種類、そして、彼らはINFOメッセージで運ばアプリケーション情報を処理する方法を示すために、静的な構成が必要です。これは、業界の相互運用性の問題を引き起こしています。
To overcome these problems, the SIP Working Group has spent significant discussion time over many years coming to agreement on whether it was more appropriate to fix INFO (by defining a registration mechanism for the ways in which it was used) or to deprecate it altogether (with the usage described in RFC 3398 [RFC3398] being grandfathered as the sole legitimate usage). Although it required substantial consensus building and concessions by those more inclined to completely deprecate INFO, the eventual direction of the working group was to publish a framework for registration of Info Packages as defined in this specification.
これらの問題を克服するために、SIPワーキンググループは、（それが使用された方法を登録メカニズムを定義することによって）INFOを修正するか、（それを完全に廃止することがより適切であったかどうかに合意に来て、長年にわたり重要な議論の時間を費やしてきましたRFC 3398 [RFC3398]に記載され使用して）唯一の正当な使用法として適用除外されます。それは完全にINFOを廃止するものをより多くの傾斜によってかなりの合意形成や譲歩を要求しますが、ワーキンググループの最終的な方向は、この仕様で定義されている情報パッケージの登録のためのフレームワークを公開しました。
This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. This document obsoletes RFC 2976 [RFC2976]. For backward compatibility,
この文書では、セッション開始プロトコル（SIP）[RFC3261]、およびインフォパッケージ機構のための方法、INFOを、定義します。この文書は、RFC 2976 [RFC2976]を廃止します。下位互換性のため、
this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, here referred to as "legacy INFO Usage".
この文書はまた、以前RFC 2976で定義された使用方法に対応しているINFOメソッドの使い方の「レガシー」モードを指定し、ここでは「レガシーINFOの使用法」と呼ばれます。
For backward compatibility purposes, this document does not deprecate legacy INFO usages, and does not mandate users to define Info Packages for such usages. However:
下位互換性のために、この文書では、レガシーINFOの使用法を廃止しないと、このような用途のために情報のパッケージを定義するには、ユーザーを強制しません。しかしながら：
1. A UA MUST NOT insert an Info-Package header field in a legacy INFO request (as described in Section 4.2.1, an INFO request associated with an Info Package always contains an Info-Package header field).
1. A UAは、レガシーINFO要求（セクション4.2.1で説明したように、情報パッケージに関連付けられた情報要求は常にインフォパッケージヘッダフィールドを含む）でインフォパッケージのヘッダーフィールドを挿入してはいけません。
2. Any new usage MUST use the Info Package mechanism defined in this specification, since it does not share the issues associated with legacy INFO usage, and since Info Packages can be registered with IANA.
2.それはレガシーINFOの使用に関連する問題を共有していないので、すべての新しい使用法は、この仕様で定義されたインフォパッケージのメカニズムを使用しなければならない、とインフォパッケージは、IANAに登録することができるからです。
3. UAs are allowed to enable both legacy INFO usages and Info Package usages as part of the same invite dialog usage, but UAs SHALL NOT mix legacy INFO usages and Info Package usages in order to transport the same application level information. If possible, UAs SHALL prefer the usage of an Info Package.
3. UAは同じ招待ダイアログの使用の一環として、両方のレガシーINFOの用途およびインフォパッケージの使用法を可能にするために許可されていますが、UAは、同じアプリケーション・レベルの情報を輸送するために、従来のINFOの用途およびインフォパッケージの使用法を混在させないものとします。可能な場合は、UAは、インフォパッケージの使用を好むものとします。
The INFO method provides a mechanism for transporting application level information that can further enhance a SIP application. Section 8 gives more details on the types of applications for which the use of INFO is appropriate.
INFO方法はさらに、SIPアプリケーションを向上させることができ、アプリケーション・レベルの情報を搬送するための機構を提供します。第8節はINFOの使用が適切であるため、アプリケーションの種類に関する詳細を提供します。
This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFO messages.
このセクションでは、UAは、INFO要求と応答だけでなく、INFOメッセージに含まれるメッセージボディを処理する方法を説明します。
An INFO request can be associated with an Info Package (see Section 5), or associated with a legacy INFO usage (see Section 2).
INFO要求はインフォパッケージ（セクション5を参照）に関連した、またはレガシーINFOの使用に関連することができます（第2章を参照してください）。
The construction of the INFO request is the same as any other non-target refresh request within an existing invite dialog usage as described in Section 12.2 of RFC 3261.
INFO要求の建設は、RFC 3261のセクション12.2で説明したように既存のダイアログの使用を招待内の任意の他の非標的リフレッシュ要求と同じです。
When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Package header field that indicates which Info Package is associated with the request. A specific INFO request can be used only for a single Info Package.
UAは情報パッケージに関連付けられた情報要求を送信すると、それは情報パッケージは、要求に関連付けられているかを示す情報、パッケージのヘッダーフィールドを含まなければなりません。特定INFO要求は、単一のインフォパッケージのために使用することができます。
When a UA sends an INFO request associated with a legacy INFO usage, there is no Info Package associated with the request, and the UA MUST NOT include an Info-Package header field in the request.
UAがレガシーINFOの使用に関連したINFO要求を送信すると、そこにはインフォパッケージは、要求に関連付けられていないで、UAはリクエストでインフォパッケージヘッダフィールドを含んではいけません。
The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods (and their responses) listed in Section 5.
INFO要求は、Recv関数-Infoヘッダーフィールドを含めることはできません。 UAは、第5項に記載されているSIPメソッド（とその回答）を使用して、INFO要求を受信するために喜んでいるインフォパッケージのセットを示すことができます。
A UA MUST NOT send an INFO request outside an invite dialog usage and MUST NOT send an INFO request for an Info Package inside an invite dialog usage if the remote UA has not indicated willingness to receive that Info Package within that dialog.
UAは招待ダイアログの使用外INFO要求を送ってはいけませんし、遠隔UAは、そのダイアログの中にその情報パッケージを受信するために意欲を示していない場合に招待ダイアログの使用内の情報パッケージのためのINFO要求を送ってはいけません。
If a UA receives a 469 (Bad Info Package) response to an INFO request, based on RFC 5057 [RFC5057], the response represents a Transaction Only failure, and the UA MUST NOT terminate the invite dialog usage.
UAは、RFC 5057に基づいて情報要求に469（悪いインフォパッケージ）応答、[RFC5057]を受信した場合、応答は、トランザクションを表し唯一の失敗、およびUA招待ダイアログの使用を終了してはなりません。
Due to the possibility of forking, the UA that sends the initial INVITE request MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase. In addition, the UA MUST be prepared to receive different Recv-Info header field values from different remote UAs.
最初のINVITE要求が早いダイアログフェーズの間に、複数のリモートのUAからの情報要求を受信するために準備しなければなりません送信フォークの可能性、UAのために。また、UAは、異なるリモートのUAから別のRecv-INFOヘッダフィールド値を受信するように準備しなければなりません。
NOTE: If the User Agent Server (UAS) (receiver of the initial INVITE request) sends an INFO request just after it has sent the response that creates the dialog, the UAS needs to be prepared for the possibility that the INFO request will reach the User Agent Client (UAC) before the dialog-creating response, and might therefore be rejected by the UAC. In addition, an INFO request might be rejected due to a race condition, if a UA sends the INFO request at the same time that the remote UA sends a new set of Info Packages for which it is willing to receive INFO requests.
注：ユーザエージェントサーバ（UAS）（初期INVITEリクエストの受信機は）それがダイアログを作成し、応答を送信した直後INFO要求を送信した場合、UASはINFO要求が到達する可能性のために準備する必要がありますダイアログ作成応答する前にユーザーエージェントクライアント（UAC）とするので、UACによって拒否されることがあります。 UAは、リモートUAは、INFO要求を受け取るために喜んでいるインフォパッケージの新しいセットを送信し、同時にINFOリクエストを送信した場合また、INFO要求は、原因競合状態に拒否されることがあります。
If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad Info Package) response (see Section 11.6), which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests. The UA MUST NOT use the response to update the set of Info Packages, but simply to indicate the current set. In the terminology of multiple dialog usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage.
情報とのRecv-Infoヘッダーフィールドが含まれているUAは、UAが受信する意欲を示していないことをインフォパッケージに関連付けられたINFO要求を受信した場合、UAは469（悪いインフォパッケージ）応答を送らなければなりません（セクション11.6）、 UAは、INFO要求を受信するために喜んでいるパッケージ。 UAは、インフォパッケージのセットを更新するために応答を使用してはならないが、単純に現在のセットを示すために。複数のダイアログ用法[RFC5057]の用語では、これは、トランザクションのみ失敗を表し、ダイアログの使用状況を招待し終了しません。
If a UA receives an INFO request associated with an Info Package, and the message body part with Content-Disposition "Info-Package" (see Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) type that the UA supports but not in the context of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response.
UAは、コンテンツディスポジションでインフォパッケージに関連付けられたINFO要求、およびメッセージのボディ部を受信した場合、「インフォパッケージ」（4.3.1項を参照）MIME（Multipurpose Internet Mail Extensions）はUAがサポートするタイプではなく、いそのインフォパッケージの文脈においては、UAは415（サポートされていないメディアタイプ）応答を送信することが推奨されます。
The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx), and Global Failure (6xx), in accordance with the error-handling procedures defined in RFC 3261.
UAは、RFC 3261で定義されたエラー処理手順に従って、そのような要求の失敗（4XX）、サーバ障害（5xxの）、およびグローバル失敗（6xxの）などの他のエラー応答を送信することができます。
Otherwise, if the INFO request is syntactically correct and well structured, the UA MUST send a 200 (OK) response.
INFO要求は構文的に正しい、よく構造化されている場合はそうでない場合は、UAは、200（OK）応答を送らなければなりません。
NOTE: If the application needs to reject the information that it received in an INFO request, that needs to be done on the application level. That is, the application needs to trigger a new INFO request, which contains information that the previously received application data was not accepted. Individual Info Package specifications need to describe the details for such procedures.
注：アプリケーションは、アプリケーション・レベルで行われる必要があるINFO要求で受信した情報を拒絶する必要がある場合。これは、アプリケーションが以前に受信したアプリケーションデータが受け入れられなかったという情報を含む新しいINFO要求をトリガするために必要です。個々の情報パッケージの仕様は、このような手順の詳細を記述する必要があります。
Proxies need no additional behavior beyond that described in RFC 3261 to support INFO.
プロキシはINFOをサポートするために、RFC 3261に記載されているもの以外の追加の動作を必要としません。
The purpose of the INFO request is to carry application level information between SIP UAs. The application information data is carried in the payload of the message body of the INFO request.
INFO要求の目的は、SIPのUA間のアプリケーションレベルの情報を搬送することです。アプリケーション情報データは、INFO要求のメッセージボディのペイロードで運ばれます。
NOTE: An INFO request associated with an Info Package can also include information associated with the Info Package using Info-Package header field parameters.
注：インフォパッケージに関連付けられたINFO要求もインフォパッケージのヘッダフィールドのパラメータを使用してインフォパッケージに関連する情報を含めることができます。
If an INFO request associated with an Info Package contains a message body part, the body part is identified by a Content-Disposition header field "Info-Package" value. The body part can contain a single MIME type, or it can be a multipart [RFC5621] that contains other body parts associated with the Info Package.
情報パッケージに関連付けられた情報要求メッセージのボディ部が含まれている場合、本体部は、Content-Dispositionヘッダーフィールド「インフォパッケージ」の値によって識別されます。本体部分は、単一のMIMEタイプを含むことができ、またはそれは情報パッケージに関連付けられた他の身体部分を含んでいるマルチ[RFC5621]であることができます。
UAs MUST support multipart body parts in accordance with RFC 5621.
UAは、RFC 5621に従ったマルチボディ部品をサポートしなければなりません。
NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned.
注：INFO要求が招待ダイアログ用法の文脈の中で意味があるが、特にINFO方法および当該アプリケーションに関連付けられていない他の身体部分をも含有することができます。
When a UA supports a specific Info Package, the UA MUST also support message body MIME types in accordance with that Info Package. However, in accordance with RFC 3261, the UA still indicates the supported MIME types using the Accept header.
UAが特定の情報パッケージをサポートしている場合、UAはまた、その情報パッケージに従ってメッセージボディのMIMEタイプをサポートしなければなりません。しかし、RFC 3261に従って、UAは依然として受け入れヘッダを使用してサポートされているMIMEタイプを示しています。
A UA MUST NOT include a message body associated with an Info Package in an INFO response. Message bodies associated with Info Packages MUST only be sent in INFO requests.
UAは、INFO応答で情報パッケージに関連付けられたメッセージ本体を含んではいけません。インフォパッケージに関連付けられたメッセージ本文はINFO要求で送らなければなりません。
A UA MAY include a message body that is not associated with an Info Package in an INFO response.
UAは、INFO応答で情報パッケージに関連付けられていないメッセージ本体を含むかもしれません。
The Info Package mechanism does not define a delivery order mechanism. Info Packages can rely on the CSeq header field [RFC3261] to detect if an INFO request is received out of order.
インフォパッケージのメカニズムは、配信順序メカニズムを定義していません。インフォパッケージはINFO要求の順序が受信されたかどうかを検出するためにCSeqヘッダーフィールド[RFC3261]に依存することができます。
If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, are specified as part of the associated Info Package (e.g., the use of sequence numbers within the application data).
特定のアプリケーションは、配信、それらのメカニズム、及び関連する手順の順序のための追加のメカニズムが必要な場合は、関連情報パッケージ（アプリケーションデータ内のシーケンス番号の例えば、使用）の一部として指定されています。
An Info Package specification defines the content and semantics of the information carried in an INFO message associated with an Info Package. The Info Package mechanism provides a way for UAs to indicate for which Info Packages they are willing to receive INFO requests, and with which Info Package a specific INFO request is associated.
情報パッケージの仕様は、情報パッケージに関連付けられたINFOメッセージで搬送される情報の内容と意味論を定義します。インフォパッケージのメカニズムは、UAが情報パッケージは、彼らがINFO要求を受信するために喜んでいる示し、特定のINFO要求が関連している情報パッケージたとする方法を提供します。
This section describes how a UA handles Info Packages, how a UA uses the Recv-Info header field, and how the UA acts in re-INVITE rollback situations.
このセクションでは、UAは、のRecv-Infoヘッダーフィールドをどのように使用するか、およびUAは再INVITEロールバックの状況に作用するか、UAは情報パッケージを処理する方法を説明します。
A UA that supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages for which it is willing to receive INFO requests for a specific session. A UA can list multiple Info Packages in a single Recv-Info header field, and the UA can use multiple Recv-Info header fields. A UA can use an empty Recv-Info header field, i.e., a header field without any header field values.
インフォパッケージのメカニズムをサポートUAはのRecv-Infoヘッダーフィールド、特定のセッションのためのINFO要求を受け取るために喜んでいるインフォパッケージのセットを使用して、指定する必要があります。 UAは、単一のRecv-Infoヘッダーフィールドに複数のインフォパッケージを一覧表示することができ、およびUAは、複数のRecv-Infoヘッダーフィールドを使用することができます。 UAは、任意のヘッダフィールド値なしで、すなわち、ヘッダーフィールドを空のRecv-Infoヘッダフィールドを使用することができます。
A UA provides its set of Info Packages for which it is willing to receive INFO requests during the dialog establishment. A UA can update the set of Info Packages during the invite dialog usage.
UAは、ダイアログの確立中にINFO要求を受け取るために喜んでいるインフォパッケージのセットを提供します。 UAは招待ダイアログの使用時のインフォパッケージのセットを更新することができます。
If a UA is not willing to receive INFO requests for any Info Packages, during dialog establishment or later during the invite dialog usage, the UA MUST indicate this by including an empty Recv-Info header field. This informs other UAs that the UA still supports the Info Package mechanism.
UAは、ダイアログ確立時以降の招待ダイアログの使用時に、任意の情報パッケージ用のINFO要求を受け取ることを望んでいない場合、UAは、空のRecv-Infoヘッダーフィールドを含めることによって、このことを示す必要があります。これは、UAは、まだ情報パッケージのメカニズムをサポートし、他のユーザーエージェントを通知します。
Example: If a UA has previously indicated Info Packages "foo" and "bar" in a Recv-Info header field, and the UA during the lifetime of the invite dialog usage wants to indicate that it does not want to receive INFO requests for any Info Packages anymore, the UA sends a message with an empty Recv-Info header field.
例：UAが以前の存続期間中にインフォパッケージ「foo」とのRecv-Infoヘッダーフィールドに「バー」、およびUAを示している場合は、ダイアログの使用は、それが任意のためのINFO要求を受信したくないことを示したい招待しますインフォパッケージはもう、UAは、空のRecv-Infoヘッダーフィールドとメッセージを送信します。
Once a UA has sent a message with a Recv-Info header field containing a set of Info Packages, the set is valid until the UA sends a new Recv-Info header field containing a new, or empty, set of Info Packages.
UAは、インフォパッケージのセットを含むのRecv-Infoヘッダーフィールドとメッセージを送った後はUAが情報パッケージのセット、新しい、または空を含む新しいのRecv-Infoヘッダーフィールドを送信するまで、セットは有効です。
Once a UA has indicated that it is willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST be prepared to receive INFO requests associated with that Info Package until the UA indicates that it is no longer willing to receive INFO requests associated with that Info Package.
UAは、特定の情報パッケージのためのINFO要求を受信する意思があることが示されており、およびダイアログが確立されるとUAが、それはもはや喜んでいることを示していないまで、UAは、その情報パッケージに関連付けられたINFO要求を受け取ることを準備する必要がありその情報パッケージに関連付けられたINFO要求を受信します。
For a specific dialog usage, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info
それは、リモートUAが、その情報のためのINFO要求を受信する意思があるという指示を受信するまで、特定のダイアログの使用方法については、UAは、インフォパッケージに関連付けられたINFO要求を送ってはいけません
Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package.
パッケージ、またはUAが遠隔UAは、もはやその情報パッケージに関連付けられたINFO要求を受信する意思があるという指示を受けた後。
NOTE: When a UA sends a message that contains a Recv-Info header field with a new set of Info Packages for which the UA is willing to receive INFO requests, the remote UA might, before it receives the message, send an INFO request based on the old set of Info Packages. In this case, the receiver of the INFO requests rejects, and sends a 469 (Bad Info Package) response to, the INFO request.
注：UAは、UAは、INFO要求を受信するために喜んでいるインフォパッケージの新しいセットでのRecv-Infoヘッダーフィールドを含むメッセージを送信するとき、それはメッセージを受信する前に、遠隔UAは、ベースINFO要求を送信することがありますインフォパッケージの古いセットに。この場合、INFO要求の受信は拒否し、INFOの要求に469（悪いインフォパッケージ）応答を送信します。
If a UA indicates multiple Info Packages that provide similar functionality, it is not possible to indicate a priority order of the Info Packages, or to indicate that the UA wishes to only receive INFO requests for one of the Info Packages. It is up to the application logic associated with the Info Packages, and particular Info Package specifications, to describe application behavior in such cases.
UAは、同様の機能を提供する複数の情報パッケージを示している場合、Infoパッケージの優先順位を示すために、またはUAが唯一の情報パッケージのいずれかのINFO要求を受信したいことを指示することはできません。そのような場合にアプリケーションの動作を記述するために、インフォパッケージに関連付けられたアプリケーション・ロジック、および特定のインフォパッケージの仕様次第です。
For backward compatibility purposes, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO usages. In addition, if a UA indicates support of the INFO method using the Allow header field [RFC3261], it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv-Info header field to indicate that it supports the Info Package mechanism, in addition the UA still indicates support of the INFO method using the Allow header.
下位互換性の目的のためには、UAは、インフォパッケージ機構のサポートを示していても、まだレガシーINFOの使用法を可能にするために許可されています。 UAが許可ヘッダーフィールド[RFC3261]を使用して、INFO方法のサポートを示す場合に加えて、それは暗黙的に情報パッケージ機構のサポートを示していません。 UAは、それがインフォパッケージのメカニズムをサポートしていることを示すためにのRecv-Infoヘッダーフィールドを使用しなければなりません。同様に、UAはそれがインフォパッケージのメカニズムをサポートしていることを示すためのRecv-Infoヘッダーフィールドを使用している場合でも、ほかにUAはまだ許可ヘッダーを使用してINFOメソッドのサポートを示します。
This document does not define a SIP option-tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can define an option-tag associated with the specific Info Package, as described in Section 10.6.
この文書は、情報パッケージのメカニズムのためのSIPオプションタグ[RFC3261]を定義していません。ただし、インフォパッケージの仕様は、10.6項で説明したように、特定の情報パッケージに関連付けられているオプションタグを定義することができます。
The text below defines rules on when a UA is required to include a Recv-Info header field in SIP messages. Section 7.1 lists the SIP methods for which a UA can insert a Recv-Info header field in requests and responses.
テキストは、以下のUAは、SIPメッセージ内のRecv-Infoヘッダフィールドを含むことが要求される場合にルールを定義します。 7.1節のリストUAは、要求と応答でのRecv-Infoヘッダーフィールドを挿入することができたためにSIP方法。
o The sender of an initial INVITE request MUST include a Recv-Info header field in the initial INVITE request, even if the sender is not willing to receive INFO requests associated with any Info Package.
O初期INVITE要求の送信者は、送信者が任意の情報パッケージに関連付けられた情報要求を受信したくない場合であっても、初期INVITE要求内のRecv-Infoヘッダフィールドを含まなければなりません。
o The receiver of a request that contains a Recv-Info header field MUST include a Recv-Info header field in a reliable 18x/2xx response to the request, even if the request contains an empty Recv-Info header field, and even if the header field value of the receiver has not changed since the previous time it sent a Recv-Info header field.
要求が空のRecv-Infoヘッダフィールドが含まれ、そして場合でも、要求に信頼18X / 2XX応答のRecv-Infoヘッダフィールドを含まなければならないのRecv-Infoヘッダフィールドを含むリクエストの受信Oたとえ受信機のヘッダフィールドの値は、それがのRecv-Infoヘッダフィールドを送信前回以降に変更されていません。
o A UA MUST NOT include a Recv-Info header field in a response if the associated request did not contain a Recv-Info header field.
関連する要求がのRecv-Infoヘッダーフィールドが含まれていなかった場合、O UA応答でのRecv-Infoヘッダーフィールドを含んではいけません。
NOTE: In contrast to the rules for generating Session Description Protocol (SDP) answers [RFC3264], the receiver of a request is not restricted to generating its own set of Info Packages as a subset of the Info Package set received in the Info-Package header field of the request.
注：セッション記述プロトコルを生成するためのルールと対照（SDP）回答[RFC3264]は、要求の受信は、インフォパッケージで受信した情報パッケージのセットのサブセットとして情報パッケージの独自のセットを生成することに限定されるものではありませんリクエストのヘッダフィールド。
As with SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver MUST use the same Recv-Info header field value (if included) in all responses for the same transaction.
SDP回答と同様に、受信機は、同一のINVITE / RE-INVITEトランザクションに対して複数の応答（18X / 2XX）における同一のRecv-Infoヘッダフィールド値を含むことができ、しかし、もし受信機が（同一のRecv-Infoヘッダフィールド値を使用する必要があります同じトランザクションのすべての応答に）含まれています。
If the receiver of a request that contains a Recv-Info header field rejects the request, both the sender and receiver of the request MUST roll back to the set of Info Packages that was used before the request was sent. This also applies to the case where the receiver of an INVITE/re-INVITE request has included a Recv-Info header field in a provisional response, but later rejects the request.
Recv-Infoヘッダーフィールドを含むリクエストの受信機が要求を拒否した場合は、リクエストの送信者と受信者の両方がバック要求が送信される前に使用された情報パッケージのセットにロールしなければなりません。これはまた、再INVITE / INVITEリクエストの受信機は、暫定応答でのRecv-Infoヘッダフィールドを含んでいる場合に適用され、それ以降の要求を拒否する。
NOTE: The dialog state rollback rules for Info Packages might differ from the rules for other types of dialog state information (SDP, target, etc.).
注：インフォパッケージの対話状態にロールバックルールが対話状態情報（SDP、ターゲットなど）の他のタイプのためのルールと異なる場合があります。
This document allows a UA to insert a Recv-Info header field in a REGISTER request. However, a UA SHALL NOT include a header value for a specific Info Package unless the particular Info Package specification describes how the header field value shall be interpreted and used by the registrar, e.g., in order to determine request targets.
この文書では、UAは、REGISTERリクエストでのRecv-Infoヘッダフィールドを挿入することを可能にします。特定の情報パッケージ仕様は、ヘッダフィールド値は、要求のターゲットを決定するために、例えば、レジストラによって解釈され使用されなければならない方法について説明していない限りしかし、UAは、特定の情報パッケージのヘッダー値を含めてはなりません。
Rather than using the Recv-Info header field in order to determine request targets, it is recommended to use more appropriate mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this document does not define a feature tag for the Info Package mechanism, or a mechanism to define feature tags for specific Info Packages.
むしろ要求目標を決定するために、Recv関数-Infoヘッダフィールドを使用するよりも、RFC 3840 [RFC3840]に基づいて、例えば、より適切なメカニズムを使用することが推奨されます。しかし、この文書は情報パッケージメカニズムの機能タグ、または特定のインフォパッケージの機能のタグを定義するためのメカニズムを定義していません。
This document describes one new SIP method: INFO. This document replaces the definition and registrations found in RFC 2976 [RFC2976].
INFO：この文書は、1つの新しいSIP方法を説明します。この文書は、RFC 2976 [RFC2976]で見つけ定義と登録を置き換えます。
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
この表は、RFC 3261で、表2及び3 [RFC3261]に拡張します。
Header field where INFO
--------------------------------------------
Accept R o
Accept 415 o
Accept-Encoding R o
Accept-Encoding 2xx o
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx o
Accept-Language 415 o
Accept-Resource-Priority 2xx,417 o
Alert-Info -
Allow R o
Allow 405 m
Allow r o
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info o
Contact -
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length o
Content-Type *
CSeq c m
Date o
Error-Info 3xx-6xx o
Expires -
From c m
Geolocation R o
Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organization - Priority R - Privacy o Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx,18x o Referred-By R o Request-Disposition R o Require o Resource-Priority o Retry-After R - Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx o Timestamp o To c m (w/ Tag) Unsupported 420 o User-Agent o Via m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o
組織 - - 優先R - プロキシ必要R O理由Oプロキシ認証Oプライバシー401 Oプロキシ認証407メートルプロキシ認証Rミン期限O MIME-版O最大転送しR - 最大巾R ROジオロケーション・エラーRレコードルートR OレコードルートO 2XX、18X O呼ば-によりR O要求 - ディスポジションR O要求Oリソース優先Oリトライ後、R - 再試行後404413480486 Oリトライ後500503 Oリトライ後600603 O CMにOタイムスタンプOサポートの2xx OサポートR O件名R ROセキュリティクライアントRセキュリティを確認し、O 421494セキュリティ・サーバO RのOサーバOルートR（タグ/ w）でサポートされていない420 OのUser-Agent O WWW ROメートルの警告経由401メートルWWW認証407 Oを-Authenticate
Table 1: Summary of Header Fields
表1：ヘッダフィールドの概要
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
この表は、RFC 3261で、表2及び3 [RFC3261]に拡張します。
Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD
------------------------------------------------------------------
Info-Package R - - - - - - - m* - -
Recv-Info R - - - m - o o - - o
Recv-Info 2xx - - - o** - - o***- - o***
Recv-Info 1xx - - - o** - - - - - -
Recv-Info 469 - - - - - - - m* - -
Recv-Info r - - - o - - o - - o
Header field where SUB NOT RFR
--------------------------------
Info-Package R - - -
Recv-Info R - - -
Recv-Info 2xx - - -
Recv-Info 1xx - - -
Recv-Info 469 - - -
Recv-Info r - - -
Table 2: INFO-Related Header Fields
表2：INFO関連ヘッダー・フィールド
The support and usage of the Info-Package and Recv-Info header fields are not applicable to UAs that only support legacy INFO usages.
インフォパッケージとのRecv-Infoヘッダーフィールドのサポートと使用方法は、従来のINFOの使用法をサポートするUAには適用されません。
* Not applicable to INFO requests and responses associated with legacy INFO usages.
*レガシーINFOの使用法に関連した情報の要求と応答には適用されません。
** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field.
** INVITE要求を関連のRecv-Infoヘッダフィールドが含まれている場合、INVITE要求に、送信された場合、少なくとも一つの信頼18X / 2xx応答に必須。
*** Mandatory if the associated request contained a Recv-Info header field.
***関連要求のRecv-Infoヘッダフィールドが含まれている場合は必須。
As defined in Section 20 of RFC 3261, a "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request.
RFC 3261のセクション20で定義されているように、「必須」ヘッダフィールドは要求に存在していなければなりません、との要求を受信UASによって理解されなければなりません。
This document adds "Info-Package" to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 4 describes the Info-Package header field usage.
この文書は、SIPメッセージの文法[RFC3261]の要素「メッセージヘッダ」の定義に「インフォパッケージ」を加算します。第4節は、Info-パッケージヘッダフィールドの使用方法について説明します。
For the purposes of matching Info Package types indicated in Recv-Info with those in the Info-Package header field value, one compares the Info-package-name portion of the Info-package-type portion of the Info-Package header field octet by octet with that of the Recv-Info header field value. That is, the Info Package name is case sensitive. Info-package-param is not part of the comparison-checking algorithm.
インフォパッケージヘッダフィールド値のものとのRecv-詳細に示されているマッチング情報パッケージタイプの目的のために、一つによるインフォパッケージヘッダフィールドのオクテットの情報パッケージ型部分のインフォパッケージ名部分を比較Recv-Infoヘッダフィールド値のそれとオクテット。それは、Infoパッケージ名は大文字と小文字が区別され、です。インフォパッケージ-paramが比較チェックアルゴリズムの一部ではありません。
This document does not define values for Info-Package types. Individual Info Package specifications define these values.
この文書は、Info-パッケージタイプの値を定義していません。個々の情報パッケージ仕様は、これらの値を定義します。
This document adds Recv-Info to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 5 describes the Recv-Info header field usage.
この文書は、SIPメッセージの文法[RFC3261]の要素「メッセージヘッダ」の定義とのRecv-情報を追加します。第5節では、Recv関数-Infoヘッダーフィールドの使用方法について説明します。
This section covers considerations to take into account when deciding whether the usage of an Info Package is appropriate for transporting application information for a specific use-case.
このセクションでは、インフォパッケージの使用は、特定のユースケースのためのアプリケーション情報を輸送するための適切であるかどうかを決定する際に考慮すべき注意事項をカバーしています。
When designing an Info Package, for application level information exchange, it is important to consider: is signaling, using INFO requests, within a SIP dialog, an appropriate mechanism for the use-case? Is it because it is the most reasonable and appropriate choice, or merely because "it's easy"? Choosing an inappropriate mechanism for a specific use-case can cause negative effects in SIP networks where the mechanism is used.
インフォパッケージを設計するとき、アプリケーション・レベルの情報交換のために、考慮することが重要である：、SIPダイアログ内、INFO要求を使用して、ユースケースのための適切なメカニズムをシグナリングして？それは、最も合理的かつ適切な選択である、または単に「それは簡単だ」なぜならためですか？特定のユースケースのために不適切な機構を選択する機構が使用されているSIPネットワークに悪影響を引き起こす可能性があります。
INFO messages differ from many other sorts of SIP messages in that they carry application information, and the size and rate of INFO messages are directly determined by the application. This can cause application information traffic to interfere with other traffic on that infrastructure, or to self-interfere when data rates become too high.
INFOメッセージは、彼らがアプリケーション情報を伝えるという点で、SIPメッセージの他の多くの種類の異なる、およびINFOメッセージのサイズとレートは、直接アプリケーションによって決定されます。これは、そのインフラストラクチャ上の、または自己干渉データレートが高くなりすぎたときに他のトラフィックを妨害するアプリケーション情報トラフィックを引き起こす可能性があります。
There is no default throttling mechanism for INFO requests. Apart from the SIP session establishment, the number of SIP messages exchanged during the lifetime of a normal SIP session is rather small.
INFO要求に対するデフォルトの絞り機構はありません。離れたSIPセッションの確立から、SIPメッセージの数が通常のSIPセッションの存続期間中に交換することはかなり小さいです。
Some applications, like those sending Dual-Tone Multi-Frequency (DTMF) tones, can generate a burst of up to 20 messages per second. Other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage.
デュアルトーン多重周波数（DTMF）トーンを送信するもののようないくつかのアプリケーションは、毎秒最大20件のメッセージのバーストを生成することができます。他のアプリケーションは、一定のGPSの位置情報の更新のように、招待ダイアログの使用の存続期間中にINFO要求の高い率を生成することができます。
A designer of an Info Package, and the application that uses it, need to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message is sent over such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control.
インフォパッケージのデザイナー、およびそれを使用するアプリケーションは、正常にINFOメッセージが運ばれることを保証することはできませんので、サイズおよびINFOメッセージの速度は、ネットワーク上の他のトラフィックに及ぼす影響を考慮する必要があります輻輳制御トランスポートプロトコル上のエンドツーエンド。 INFOメッセージは、このようなトランスポートプロトコルを介して送信された場合でも、下流SIPエンティティは、輻輳制御を提供していないトランスポートプロトコルを介してメッセージを転送するかもしれません。
Furthermore, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. Appropriate mechanisms for such traffic include the Hypertext Transfer Protocol (HTTP) [RFC2616], the Message Session Relay Protocol (MSRP) [RFC4975], or other media plane data transport mechanisms.
また、SIPメッセージは32Kバイトに500バイト程度の比較的小さい傾向があります。 SIPヘッダープラス本体がユーザーデータグラムプロトコル（UDP）MTU [RFC0768]を超えた場合は特に、これらの限界を超えて、バルクデータの直接交換の貧機構です。そのようなトラフィックのための適切なメカニズムは、ハイパーテキスト転送プロトコル（HTTP）[RFC2616]、メッセージセッションリレープロトコル（MSRP）[RFC4975]、またはその他のメディアプレーン・データ転送メカニズムを含みます。
RFC 5405 [RFC5405] provides additional guidelines for applications using UDP that may be useful background reading.
RFC 5405 [RFC5405]は有用なバックグラウンドの読み取りであってもよいUDPを使用するアプリケーションのための追加の指針を提供します。
This subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, using SIP messages.
ここでは、SIPメッセージを使用して、SIPシグナリング・プレーン上のアプリケーション情報を搬送するためのいくつかの別のメカニズムを説明しています。
An alternative for application level interaction is to use subscription-based events [RFC3265] that use the SIP SUBSCRIBE and NOTIFY methods. Using that mechanism, a UA requests state information, such as keypad presses from a device to an application server, or key-map images from an application server to a device.
アプリケーションレベルの相互作用のための代替は、SIP SUBSCRIBE及びNOTIFYメソッドを使用して、サブスクリプションベースのイベント[RFC3265]を使用することです。その機構を使用して、UAは、デバイスへのアプリケーションサーバからアプリケーションサーバへのデバイスからのキーパッドを押す、またはキーマップ画像などの状態情報を要求します。
Event Packages [RFC3265] perform the role of disambiguating the context of a message for subscription-based events. The Info Package mechanism provides similar functionality for application information exchange using invite dialog usages [RFC5057].
イベントパッケージ[RFC3265]は、サブスクリプションベースのイベントのためのメッセージの文脈を一義化の役割を行います。インフォパッケージのメカニズムは、ダイアログ用法[RFC5057]を招待し使用したアプリケーションの情報交換のための同様の機能を提供します。
While an INFO request is always part of, and shares the fate of, an existing invite dialog usage, a SUBSCRIBE request creates a separate dialog usage [RFC5057], and is normally sent outside an existing dialog usage.
INFO要求は常にの一部であり、株式の既存のダイアログの使用状況を招き、の運命が、SUBSCRIBEリクエストは、別のダイアログの使用[RFC5057]を作成し、通常は既存のダイアログの使用の外に送信されます。
The subscription-based mechanism can be used by SIP entities to receive state information about SIP dialogs and sessions, without requiring the entities to be part of the route set of those dialogs and sessions.
サブスクリプションベースのメカニズムは、これらのダイアログ及びセッションのルートセットの一部であるエンティティを必要とせずに、SIPダイアログ及びセッションに関する状態情報を受信するSIPエンティティによって使用することができます。
As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies and back-to-back user agents (B2BUAs), the resource impact caused by the subscription dialogs needs to be considered. The number of subscription dialogs per user also needs to be considered.
SUBSCRIBE / NOTIFYメッセージは、ステートフルSIPプロキシおよびバックツーバックユーザエージェント（型B2BUA）を横断するように、サブスクリプション・ダイアログによって引き起こされるリソースへの影響を考慮する必要があります。ユーザーごとのサブスクリプションダイアログの数も考慮する必要があります。
As for any other SIP-signaling-plane-based mechanism for transporting application information, the SUBSCRIBE/NOTIFY messages can put a significant burden on intermediate SIP entities that are part of the dialog route set, but do not have any interest in the application information transported between the end users.
アプリケーション情報を輸送するための任意の他のSIPシグナリング・プレーンベースのメカニズムについては、SUBSCRIBE / NOTIFYメッセージがダイアログルートセットの一部である中間のSIPエンティティに大きな負担をかけることができますが、アプリケーション情報に興味を持っていませんエンドユーザーの間で搬送されます。
The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user.
MESSAGEメソッド[RFC3428]は、典型的には、ユーザにレンダリングするためのMIMEコンテンツを送信するために、ワンタイムインスタントメッセージ交換を定義します。
In SIP, media plane channels associated with SIP dialogs are established using SIP signaling, but the data exchanged on the media plane channel does not traverse SIP signaling intermediates, so if there will be a lot of information exchanged, and there is no need for the SIP signaling intermediaries to examine the information, it is recommended to use a media plane mechanism, rather than a SIP-signaling-based mechanism.
SIPは、SIPダイアログに関連付けられたメディアプレーン・チャネルは、SIPシグナリングを用いて確立されているが、メディアプレーン・チャネルはSIPシグナリング中間体を通過しないで多くの情報が存在することになるので、もしデータを交換し、必要がなく、交換しました情報を調べるために仲介SIPシグナリング、メディアプレーン機構ではなく、SIPシグナリング・ベースの機構を使用することが推奨されます。
A low-latency requirement for the exchange of information is one strong indicator for using a media channel. Exchanging information through the SIP routing network can introduce hundreds of milliseconds of latency.
情報を交換するための低レイテンシの要件は、メディアチャネルを使用するための1つの強力な指標です。 SIPルーティングネットワークを介して情報を交換することは、待ち時間の数百ミリ秒を導入することができます。
One mechanism for media plane exchange of application data is the Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2], where a media plane connection-oriented channel, such as a Transmission Control Protocol (TCP) [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] stream is established.
メディア・プレーンのための1つの機構は、アプリケーションデータの交換は、伝送制御プロトコル（TCP）[RFC0793]またはストリーム制御伝送プロトコルとしてメディアプレーン接続指向のチャネル、メディアリソース制御プロトコル（MRCP）SPEECHSC-MRCPv2]、です（SCTP）[RFC4960]のストリームが確立されます。
MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses.
MSRP [RFC4975]は、セッション・ベースのインスタント・メッセージングならびにバルクファイル転送、および他のこのような大容量の用途を定義します。
Another alternative is to use a SIP-independent mechanism, such as HTTP [RFC2616]. In this model, the UA knows about a rendezvous point to which it can direct HTTP requests for the transfer of information. Examples include encoding of a prompt to retrieve in the SIP Request URI [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-voicexml21-20070619] script.
別の代替は、HTTP [RFC2616]としてSIP非依存性メカニズムを使用することです。このモデルでは、UAは、それが情報を転送するためのHTTP要求を指示することができますするためにどのランデブーポイントを知っています。例としては、SIPリクエストURI [RFC4240]またはVoiceXMLの[W3C.REC-voicexml21-20070619]スクリプトのSUBMITターゲットのエンコーディングに取得するプロンプトのエンコーディングを含みます。
This section describes the syntax extensions to the ABNF syntax defined in RFC 3261 required for the INFO method, and adds definitions for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
このセクションでは、INFOメソッドに必要なRFC 3261で定義されたABNF構文に構文拡張について説明し、インフォパッケージとのRecv-Infoヘッダーフィールドの定義を追加します。前のセクションでは意味を説明します。本明細書で定義されたABNFは、RFC 5234 [RFC5234]に準拠しています。
INFOm = %x49.4E.46.4F ; INFO in caps Method =/ INFOm
INFOm =％x49.4E.46.4F。キャップ内INFOメソッド= / INFOm
message-header =/ (Info-Package / Recv-Info) CRLF Info-Package = "Info-Package" HCOLON Info-package-type Recv-Info = "Recv-Info" HCOLON [Info-package-list] Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *( SEMI Info-package-param ) Info-package-name = token Info-package-param = generic-param
メッセージヘッダ= /（インフォパッケージ/レシーバ-INFO）CRLFインフォパッケージ= "インフォパッケージ" HCOLONインフォパッケージ型のRecv-INFO = "Recv関数-INFO" HCOLON [インフォパッケージリスト]情報パッケージ-list =インフォパッケージ型*（COMMAインフォパッケージ型）インフォパッケージ型=インフォパッケージ名*（SEMIインフォパッケージのparam）インフォパッケージ名=トークンインフォパッケージのparam =ジェネリック-PARAM
This section provides guidance on how to define an Info Package, and what information needs to exist in an Info Package specification.
このセクションでは、インフォパッケージを定義する方法に関するガイダンスを提供し、どのような情報は、情報パッケージ仕様に存在する必要があります。
If, for an Info Package, there is a need to extend or modify the behavior described in this document, that behavior MUST be described in the Info Package specification. It is bad practice for Info Package specifications to repeat procedures defined in this document, unless needed for purposes of clarification or emphasis.
、インフォパッケージのために、このドキュメントで説明する動作を拡張または変更する必要がある場合、その動作は、Infoパッケージ仕様で説明されなければなりません。これは、明確化や強調のために必要な場合を除き、本文書で定義された手順を繰り返すインフォパッケージ仕様の悪い習慣です。
Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Package specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" if applications associated with the Info Package require it.
インフォパッケージの仕様は、本明細書では「SHOULD」や「MUST」で指定されたすべての行動を弱めてはなりません。ただし、インフォパッケージの仕様は「SHOULD」、「MAY」、または「推奨」要件への強化MAY「MUST」インフォパッケージに関連付けられたアプリケーションは、それを必要とする場合。
Info Package specifications MUST address the issues defined in the following subsections, or document why an issue is not applicable to the specific Info Package.
インフォパッケージの仕様は以下のサブセクションで定義された問題に対処する、または問題が特定の情報パッケージには適用されない理由を文書化する必要があります。
Section 8.4 describes alternative mechanisms, which should be considered as part of the process for solving a specific use-case, when there is a need for transporting application information.
セクション8.4は、アプリケーション情報を搬送する必要がある場合、特定のユースケースを解決するためのプロセスの一部として考慮されるべき別のメカニズムを記述する。
The Info Package specification MUST contain an overall description of the Info Package: what type of information is carried in INFO requests associated with the Info Package, and for what types of applications and functionalities UAs can use the Info Package.
インフォパッケージの仕様は、インフォパッケージの全体的な記述が含まれなければならない：インフォパッケージに関連付けられたINFO要求で運ばれる情報の種類を、そして何のためにアプリケーションや機能のユーザーエージェントの種類は、情報パッケージを使用することができます。
If the Info Package is defined for a specific application, the Info Package specification MUST state which application UAs can use the Info Package with.
インフォパッケージは、特定のアプリケーションのために定義されている場合は、インフォパッケージの仕様は、UAがでインフォパッケージを使用できるアプリケーション述べなければなりません。
The Info Package specification MUST describe why the Info Package mechanism, rather than some other mechanism, has been chosen for the specific use-case to transfer application information between SIP endpoints. Common reasons can be a requirement for SIP proxies or back-to-back user agents (B2BUAs) to see the transported application information (which would not be the case if the information was transported on a media path), or that it is not seen as feasible to establish separate dialogs (subscription) in order to transport the information.
情報パッケージ機構ではなく、いくつかの他の機構は、SIPエンドポイントとの間でアプリケーション情報を転送するために、特定のユースケースのために選択された理由情報パッケージの仕様が記述しなければなりません。一般的な理由は、SIPプロキシのための要件であるか、またはバックツーバックユーザエージェント（型B2BUAに）（情報は、メディア経路上を搬送された場合はそうではない）輸送アプリケーションの情報を表示すること、またはそれが見られないことができ情報を輸送するために、別のダイアログ（サブスクリプション）を確立するために実行可能。
Section 8 provides more information and describes alternative mechanisms that one should consider for solving a specific use-case.
第8章は、より多くの情報を提供し、もう1つは、特定のユースケースを解決するため検討すべき代替メカニズムについて説明します。
The Info Package specification MUST define an Info Package name, which UAs use as a header field value (e.g., "infoX") to identify the Info Package in the Recv-Info and Info-Package header fields. The header field value MUST conform to the ABNF defined in Section 9.2.
情報パッケージ仕様は、UAがRecv関数-INFOおよびインフォパッケージヘッダフィールドに情報パッケージを識別するためのヘッダフィールド値（例えば、「INFOX」）として使用情報パッケージ名を定義しなければなりません。ヘッダフィールド値はセクション9.2で定義されたABNFに従わなければなりません。
The Info Package mechanism does not support package versioning. Specific Info Package message body payloads can contain version information, which is handled by the applications associated with the Info Package. However, such a feature is outside the scope of the generic Info Package mechanism.
インフォパッケージのメカニズムは、パッケージのバージョン管理をサポートしていません。特定の情報パッケージメッセージボディペイロードは情報パッケージに関連付けられたアプリケーションによって処理されたバージョン情報を含むことができます。しかし、そのような機能は、一般的な情報パッケージのメカニズムの範囲外です。
NOTE: Even if an Info Package name contains version numbering (e.g., foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name.
注：インフォパッケージ名は、バージョン番号（例えば、foo_v2）が含まれている場合でも、インフォパッケージのメカニズムは、インフォパッケージ名の残りの部分からバージョン番号を区別しません。
The Info Package specification MAY define Info Package parameters, which can be used in the Recv-Info or Info-Package header fields, together with the header field value that indicates the Info Package name (see Section 10.4).
情報パッケージ仕様は、情報パッケージ名（10.4項を参照）を示すヘッダフィールド値とともに、Recv関数-INFOまたはインフォパッケージのヘッダフィールドに使用することができる情報パッケージパラメータを規定することができます。
The Info Package specification MUST define the syntax and semantics of the defined parameters. In addition, the specification MUST define whether a specific parameter is applicable to only the Recv-Info header field, only the Info-Package header field, or to both.
インフォパッケージの仕様が定義されたパラメータの構文とセマンティクスを定義しなければなりません。なお、本明細書は、特定のパラメータのみのRecv-Infoヘッダフィールドのみインフォパッケージヘッダフィールド、あるいはその両方にに適用可能であるかどうかを定義しなければなりません。
By default, an Info Package parameter is only applicable to the Info Package for which the parameter has been explicitly defined.
デフォルトでは、インフォパッケージのパラメータは、パラメータが明示的に定義されたインフォパッケージにのみ適用されます。
Info Package parameters defined for specific Info Packages can share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined. However, when choosing the name of a parameter, it is RECOMMENDED to not use the same name as an existing parameter for another Info Package, if the semantics of the parameters are different.
特定のインフォパッケージ用に定義されたインフォパッケージのパラメータは、他の情報パッケージ用に定義されたパラメータと名前を共有することができますが、パラメータの意味は、それらが定義されている情報パッケージに固有のものです。パラメータの名前を選択する際のパラメータの意味が異なっている場合しかし、別のインフォパッケージのための既存のパラメータと同じ名前を使用しないことをお勧めします。
The Info Package specification MAY define SIP option-tags, which can be used as described in RFC 3261.
インフォパッケージの仕様はRFC 3261で説明したように使用することができSIPオプションタグを定義するかもしれません。
The registration requirements for option-tags are defined in RFC 5727 [RFC5727].
オプションタグの登録要件は、RFC 5727 [RFC5727]で定義されています。
The Info Package specification MUST define which message body part MIME types are associated with the Info Package. The specification MUST either define those body parts, including the syntax, semantics, and MIME type of each body part, or refer to other documents that define the body parts.
情報パッケージの仕様は、本体部のMIMEタイプは情報パッケージに関連付けられているメッセージを定義しなければなりません。仕様は、各身体部分の構文、セマンティクス、およびMIMEタイプを含む、それらの体の部分を定義する、または体の部分を定義する他の文書を参照する必要があります。
If multiple message body part MIME types are associated with an Info Package, the Info Package specification MUST define whether UAs need to use multipart body parts, in order to include multiple body parts in a single INFO request.
複数のメッセージボディパートのMIMEタイプは情報パッケージに関連付けられている場合、情報パッケージ仕様は、UAが単一のINFO要求における複数の身体部分を含めるために、マルチボディ部品を使用する必要があるかどうかを定義しなければなりません。
If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document such restrictions.
UAが情報パッケージを使用する方法に制限がある場合は、インフォパッケージの仕様では、そのような制限を文書化しなければなりません。
There can be restrictions related to whether UAs are allowed to send overlapping (outstanding) INFO requests associated with the Info Package, or whether the UA has to wait for the response for a previous INFO request associated with the same Info Package.
UAのは、情報パッケージに関連付けられたオーバーラップ（発行済）INFO要求を送信することが許可されているかどうかに関係の制約が存在することができ、またはUAが同じ情報パッケージに関連付けられた以前のINFO要求に対する応答を待つ必要があるかどうか。
There can also be restrictions related to whether UAs need to support and use other SIP extensions and capabilities when they use the Info Package, and if there are restrictions related to how UAs can use the Info Package together with other Info Packages.
また、UAは、他の情報パッケージと一緒に情報のパッケージを使用する方法に関連する制限がある場合UAは、彼らが情報のパッケージを使用する場合、他のSIPの拡張と機能をサポートして使用する必要がある、とするかどうかに関連する制約が存在する場合があります。
As the SIP stack might not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section 4.2.2, UAs will normally send a 200 (OK) response to an INFO request. The application logic associated with the Info Package needs to handle situations where UAs do not follow restrictions associated with the Info Package.
SIPスタックは、インフォパッケージ固有の制限に注意していないかもしれませんが、オーバーラップの要求が拒否されると仮定することはできません。 4.2.2で定義されているように、UAは通常、INFO要求に対する200（OK）応答を送信します。インフォパッケージに関連付けられたアプリケーション・ロジックは、UAが情報パッケージに関連付けられた制限に従わない状況を処理する必要があります。
If there is a maximum or minimum rate at which UAs can send INFO requests associated with the Info Package within a dialog, the Info Package specification MUST document the rate values.
UAは、ダイアログ内の情報パッケージに関連付けられたINFO要求を送信することができる最大または最小レートがある場合は、インフォパッケージの仕様は、レート値を文書化しなければなりません。
If the rates can vary, the Info Package specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Alternatively, the rate information can be part of the application data information associated with the Info Package.
金額は変更になることができた場合は、インフォパッケージの仕様では、UAが速度を示すか、交渉するために使用できるインフォパッケージのパラメータを定義することができます。あるいは、レート情報は、情報パッケージに関連付けられたアプリケーションデータ情報の一部とすることができます。
If the application information carried in INFO requests associated with the Info Package requires a certain level of security, the Info Package specification MUST describe the mechanisms that UAs need to use in order to provide the required security.
インフォパッケージに関連付けられたINFO要求で運ばれたアプリケーション情報があるレベルのセキュリティを必要とする場合は、インフォパッケージの仕様では、UAが必要なセキュリティを提供するために使用する必要があるメカニズムを説明しなければなりません。
If the Info Package specification does not require any additional security, other than what the underlying SIP protocol provides, this MUST be stated in the Info Package specification.
インフォパッケージの仕様は基本的なSIPプロトコルが提供するもの以外の任意の追加のセキュリティを必要としない場合は、これはインフォパッケージの仕様に記載しなければなりません。
NOTE: In some cases, it may not be sufficient to mandate Transport Layer Security (TLS) [RFC5246] in order to secure the Info Package payload, since intermediaries will have access to the payload, and because beyond the first hop, there is no way to assure subsequent hops will not forward the payload in clear text. The best way to ensure secure transport at the application level is to have the security at the application level. One way of achieving this is to use end-to-end security techniques such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751].
注：いくつかのケースでは、インフォパッケージのペイロードを確保するために、トランスポート層セキュリティ（TLS）[RFC5246]を強制するのに十分ではないかもしれないが、仲介者は、ペイロードへのアクセス権を持っている、と理由は最初のホップを超えてますから、ノーがありますその後のホップを保証する方法は、クリアテキストでペイロードを転送しません。アプリケーションレベルでの安全な輸送を確保するための最良の方法は、アプリケーションレベルでのセキュリティを持つことです。これを達成する一つの方法は、セキュア/多目的インターネットメール拡張（S / MIME）などのエンドツーエンドのセキュリティ技術[RFC5751]を使用することです。
It is strongly RECOMMENDED that the Info Package specification define the procedure regarding how implementors shall implement and use the Info Package, or refer to other locations where implementors can find that information.
強くインフォパッケージの仕様は実装が実装し、情報パッケージを使用するか、または実装者がその情報を見つけることができる他の場所を指すものとする方法に関する手順を定義することをお勧めします。
NOTE: Sometimes an Info Package designer might choose to not reveal the details of an Info Package. However, in order to allow multiple implementations to support the Info Package, Info Package designers are strongly encouraged to provide the implementation details.
注：時々インフォパッケージの設計者は、インフォパッケージの詳細を明らかにしないことを選択するかもしれません。しかし、複数の実装は、情報パッケージをサポートすることを可能にするために、インフォパッケージの設計者は強く、実装の詳細を提供することが奨励されています。
It is RECOMMENDED that the Info Package specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions.
インフォパッケージの仕様は、完全なメッセージとメッセージの説明とペア実証メッセージ・フロー・ダイアグラムを、提供することを推奨されます。
Note that example flows are by definition informative, and do not replace normative text.
例のフローが定義によって有益であり、規範的なテキストを置き換えないことに注意してください。
IANA updated the existing registration in the "Methods and Response Codes" registry under "Session Initiation Protocol (SIP) Parameters" from:
IANAは、「セッション開始プロトコル（SIP）パラメータ」から下の「メソッドと応答コード」レジストリ内の既存の登録を更新しました：
Method: INFO Reference: [RFC2976]
方法：INFOリファレンス：[RFC2976]
to:
と：
Method: INFO Reference: [RFC6086]
方法：INFOリファレンス：[RFC6086]
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
IANAは、「セッション開始プロトコル（SIP）パラメータ」の下の「ヘッダフィールド」のレジストリに以下の新しいSIPヘッダフィールドを追加しました。
Header Name: Info-Package Compact Form: (none) Reference: [RFC6086]
ヘッダー名：インフォパッケージのコンパクトなフォーム：（なし）参考：[RFC6086]
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
IANAは、「セッション開始プロトコル（SIP）パラメータ」の下の「ヘッダフィールド」のレジストリに以下の新しいSIPヘッダフィールドを追加しました。
Header Name: Recv-Info Compact Form: (none) Reference: [RFC6086]
ヘッダー名：Recv関数 - インフォメーションコンパクト形：（なし）参考：[RFC6086]
IANA created the following registry under "Session Initiation Protocol (SIP) Parameters":
IANAは、「セッション開始プロトコル（SIP）パラメータ」の下で以下のレジストリを作成しました：
Info Packages
インフォパッケージ
Note to the reviewer:
レビューアに注意してください：
The policy for review of Info Packages is "Specification Required", as defined in [RFC5226]. This policy was selected because Info Packages re-use an existing mechanism for transport of arbitrary session-associated data within SIP; therefore, new Info Packages do not require the more extensive review required by specifications that make fundamental protocol changes. However, the reviewer is expected to verify that each Info Package registration is in fact consistent with this definition. Changes to the SIP protocol and state machine are outside of the allowable scope for an Info Package and are governed by other procedures including RFC 5727 and its successors, if any.
[RFC5226]で定義されている情報パッケージの見直しのための政策は、「仕様が必要」です。情報パッケージは、SIP内の任意のセッション関連データを輸送するための既存のメカニズムを再使用するので、このポリシーを選択しました。そのため、新しい情報パッケージは、基本的なプロトコルの変更を行う仕様で必要とされるより広範な検討を必要としません。しかし、レビューアは、各インフォパッケージの登録は、この定義と一致実際にあることを確認することが期待されます。 SIPプロトコルとステートマシンへの変更は、インフォパッケージの許容範囲外であり、いずれの場合、RFC 5727およびその後継者を含む他の手順によって支配されています。
The following data elements populate the Info Packages Registry.
次のデータ要素は、インフォパッケージのレジストリを読み込みます。
o Info Package Name: The Info Package Name is a case-sensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values.
O情報パッケージ名：インフォパッケージ名は大文字と小文字が区別トークンです。また、IANAは、同一の大文字と小文字を区別しない値を持つ複数のインフォパッケージ名を登録してはなりません。
o Reference: A reference to a specification that describes the Info Package.
Oリファレンス：インフォパッケージを記述する明細書を参照します。
The initial population of this table shall be:
この表の最初の人口はしなければなりません。
Name Reference
名前リファレンス
IANA added the following new header field value to the "Mail Content Disposition Values" registry under "Mail Content Disposition Values and Parameters".
IANAは、「メールコンテンツ配置値とパラメータ」の下に「メールコンテンツ配置値」レジストリに次の新しいヘッダフィールド値を追加しました。
Name: info-package Description: The body contains information associated with an Info Package Reference: RFC6086
名前：インフォパッケージの説明：体がインフォパッケージのリファレンスに関連した情報が含まれています：RFC6086
IANA registered the following new response code in the "Session Initiation Protocol (SIP) Parameters" -- "Response Codes" registry.
「レスポンスコード」のレジストリ - IANAは、「セッション開始プロトコル（SIP）パラメータ」で、次の新しい応答コードを登録しました。
Response Code: 469 Default Reason Phrase: Bad Info Package Reference: RFC6086
応答コード：469デフォルトの理由フレーズ：悪い情報パッケージ参照：RFC6086
12.1. Indication of Willingness to Receive INFO Requests for Info Packages
12.1. インフォパッケージのINFO要求を受信するために意欲を示します
The UAC sends an initial INVITE request, where the UAC indicates that it is willing to receive INFO requests for Info Packages P and R.
UACは、UACは、情報パッケージPとRのINFO要求を受信する意思があることを示している初期INVITEリクエストを送信します
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Recv-Info: P, R Contact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ...
SIP / 2.0 / TCPのpc33.example.com;ブランチ= z9hG4bK776マックス・フォワード：bob@example.com SIP / 2.0経由：SIP INVITE〜70：ボブ<SIP：bob@example.com>から：アリス<一口： alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710@pc33.example.comのCSeq：314159 INVITEのRecv-INFO：P、R連絡先：<SIP：alice@pc33.example.com>のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T.
UASは、バックUASはインフォパッケージのRおよびT.のためのINFO要求を受信する意思があることを示しているUAC、200（OK）応答を送信します
SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776; received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Contact: <sip:bob@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ...
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pc33.example.com;ブランチ= z9hG4bK776。ボブ：TO = 192.0.2.1を受信<SIP：bob@example.com>;タグ= a6c85cfから：アリス<SIP：alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710@pc33.example.comのCSeq： 314159連絡先をINVITE：<SIP：bob@pc33.example.com>のRecv-情報：R、TのContent-Type：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
The UAC sends an ACK request.
UACは、ACK要求を送信します。
ACK sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 ACK Content-Length: 0
ACKのSIP：bob@pc33.example.com SIP / 2.0経由：SIP / 2.0 / TCP pc33.example.com;ブランチ= z9hG4bK754マックス・フォワード：70：ボブ<SIP：bob@example.com>;タグ= a6c85cf投稿者：アリス<SIP：alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710@pc33.example.comのCSeq：314159 ACKのコンテンツの長さ：0
The UAC sends an UPDATE request within the invite dialog usage, where the UAC indicates (using an empty Recv-Info header field) that it is not willing to receive INFO requests for any Info Packages.
UACは、UACは、どんな情報パッケージのINFO要求を受け取ることを望んでいないことを（空のRecv-Infoヘッダーフィールドを使用して）を示す招待ダイアログの使用、内UPDATEリクエストを送信します。
UPDATE sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314163 UPDATE Recv-Info: Contact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ...
UPDATEのSIP：bob@pc33.example.com SIP / 2.0経由：SIP / 2.0 / TCP pc33.example.com;ブランチ= z9hG4bK776マックス・フォワード：70：ボブ<SIP：bob@example.com>;タグ= a6c85cf投稿者：アリス<SIP：alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710@pc33.example.comのCSeq：314163 UPDATEのRecv-情報：お問い合わせ：<SIP：alice@pc33.example.com>のContentタイプ：application / SDPコンテンツの長さ：...
...
。。。
The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T.
UASは、バックUASはインフォパッケージのRおよびT.のためのINFO要求を受信する意思があることを示しているUAC、200（OK）応答を送信します
SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893; received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314163 INVITE Contact: <sip:alice@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ...
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pc33.example.com;ブランチ= z9hG4bK893。ボブ：TO = 192.0.2.1を受信<SIP：bob@example.com>;タグ= a6c85cfから：アリス<SIP：alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710@pc33.example.comのCSeq： 314163連絡先をINVITE：<SIP：alice@pc33.example.com>のRecv-情報：R、TのContent-Type：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
The UA sends an INFO request associated with Info Package "foo".
UAは、インフォパッケージ「foo」という関連付けられたINFO要求を送信します。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314333 INFO Info-Package: foo Content-type: application/foo Content-Disposition: Info-Package Content-length: 24
INFOのSIP：alice@pc33.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.2:5060;branch=z9hG4bKnabcdefへ：ボブ<SIP：bob@example.com>;タグ= a6c85cfから：アリス<一口：alice@example.com>;タグ= 1928301774コールID：a84b4c76e66710@pc33.example.comのCSeq：314333 INFOインフォパッケージ：FOOのコンテンツタイプ：アプリケーション/ fooの内容-処分：インフォパッケージ内容長さ：24
I am a foo message type
私はFOOメッセージタイプです
SIP extensions can sometimes add body part payloads into an INFO request, independent of the Info Package. In this case, the Info Package payload gets put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
SIPの拡張は時々インフォパッケージの独立したINFO要求の中に身体の一部のペイロードを追加することができます。この場合、情報パッケージのペイロードは、情報パッケージに関連付けられている本体部分を示しコンテンツの廃棄ヘッダーフィールドと、マルチパートMIME本体に入れます。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314400 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Length: ...
INFOのSIP：alice@pc33.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.2:5060;branch=z9hG4bKnabcdefへ：アリス<SIP：alice@example.net>;タグ= 1234567から：ボブ<一口：bob@example.com>;タグ= ABCDEFGコールID：a84b4c76e66710@pc33.example.comのCSeq：314400 INFOインフォパッケージ：fooというのContent-Type：multipart / mixedの;境界= "theboundary" のContent-Length .. 。
--theboundary Content-Type: application/mumble ...
--theboundaryのContent-Type：アプリケーション/むにゃむにゃ...
<mumble stuff>
<むにゃむにゃもの>
--theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59
--theboundaryのContent-Type：アプリケーション/ fooの-XのContent-処分：インフォパッケージ内容長さ：59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
私はFOO-Xメッセージタイプ、と私は、インフォパッケージfooに属し--theboundary--
12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body Part
12.2.2.2。マルチパートボディパート内の複数のボディパーツを持つインフォパッケージ
Multiple body part payloads can be associated with a single Info Package. In this case, the body parts are put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
複数のボディ部分のペイロードは、単一の情報パッケージに関連付けることができます。この場合、本体部分は情報パッケージに関連付けられている本体部分を示しコンテンツの廃棄ヘッダーフィールドと、マルチパートMIMEボディに入れます。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ...
INFOのSIP：alice@pc33.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.2:5060;branch=z9hG4bKnabcdefへ：アリス<SIP：alice@example.net>;タグ= 1234567から：ボブ<一口：bob@example.com>;タグ= ABCDEFGコールIDを：a84b4c76e66710@pc33.example.comのCSeq：314423 INFOインフォパッケージ：fooというのContent-Type：multipart / mixedの;境界= "theboundaryの" Content-処分：Info-パッケージのContent-Length：...
--theboundary Content-Type: application/foo-x Content-length: 59
--theboundaryのContent-Type：アプリケーション/ fooの-Xコンテンツの長さ：59
I am a foo-x message type, and I belong to Info Package foo
私はFOO-Xメッセージタイプ、と私は、インフォパッケージfooに属し
<mumble stuff>
<むにゃむにゃもの>
--theboundary Content-Type: application/foo-y Content-length: 59
--theboundaryコンテンツタイプ：アプリケーション/ FOO-YのContent-Length：59
I am a foo-y message type, and I belong to Info Package foo --theboundary--
私はFOO-Yメッセージの種類、と私は、インフォパッケージfooに属し--theboundary--
The body part payload associated with the Info Package can have a Content-Disposition header field value other than "Info-Package". In this case, the body part is put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
インフォパッケージに関連付けられている身体の部分ペイロードは、「インフォパッケージ」以外のContent-Dispositionヘッダーフィールド値を持つことができます。この場合、本体部は、情報パッケージに関連付けられている本体部分を示しコンテンツの廃棄ヘッダーフィールドと、マルチパートMIME本体に入れられます。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ...
INFOのSIP：alice@pc33.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.2:5060;branch=z9hG4bKnabcdefへ：アリス<SIP：alice@example.net>;タグ= 1234567から：ボブ<一口：bob@example.com>;タグ= ABCDEFGコールIDを：a84b4c76e66710@pc33.example.comのCSeq：314423 INFOインフォパッケージ：fooというのContent-Type：multipart / mixedの;境界= "theboundaryの" Content-処分：Info-パッケージのContent-Length：...
--theboundary Content-Type: application/foo-x Content-Disposition: icon Content-length: 59
--theboundaryコンテンツタイプ：アプリケーション/ FOO-xのコンテンツの廃棄：アイコンのContent-Length：59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
私はFOO-Xメッセージタイプ、と私は、インフォパッケージfooに属し--theboundary--
By eliminating multiple usages of INFO messages without adequate community review, and by eliminating the possibility of rogue SIP UAs confusing another UA by purposely sending unrelated INFO requests, we expect this document's clarification of the use of INFO to improve the security of the Internet. While rogue UAs can still send unrelated INFO requests, this mechanism enables the UAS and other security devices to associate INFO requests with Info Packages that have been negotiated for a session.
十分なコミュニティのレビューなし、とわざわざ無関係INFO要求を送信することにより、他のUAを混乱不正なSIPのUAはの可能性を排除することにより、INFOメッセージの複数の用途を排除することによって、私たちは、インターネットのセキュリティを向上させるためのINFOの使用このドキュメントの明確化を期待しています。不正なUAはまだ無関係INFO要求を送信することができますが、このメカニズムは、セッションのために交渉されている情報のパッケージでINFO要求を関連付けるためにUASや他のセキュリティデバイスを有効にします。
If the content of the Info Package payload is private, UAs will need to use end-to-end encryption, such as S/MIME, to prevent access to the content. This is particularly important, as transport of INFO is likely not to be end-to-end, but through SIP proxies and back-to-back user agents (B2BUAs), which the user may not trust.
インフォパッケージのペイロードの内容がプライベートの場合、UAは、コンテンツへのアクセスを防止するために、S / MIMEとして、エンドツーエンドの暗号化を使用する必要があります。 INFOの輸送は、エンド・ツー・エンドが、SIPプロキシ、ユーザが信頼しないかもしれないバックツーバックユーザエージェント（型B2BUA）を介してされるべきではない可能性があるので、これは特に重要です。
The INFO request transports application level information. One implication of this is that INFO messages may require a higher level of protection than the underlying SIP dialog signaling. In particular, if one does not protect the SIP signaling from eavesdropping or authentication and repudiation attacks, for example by using TLS transport, then the INFO request and its contents will be vulnerable as well. Even with SIP/TLS, any SIP hop along the path from UAC to UAS can view, modify, or intercept INFO requests, as they can with any SIP request. This means some applications may require end-to-end encryption of the INFO payload, beyond, for example, hop-by-hop protection of the SIP signaling itself. Since the application dictates the level of security required, individual Info Packages have to enumerate these requirements. In any event, the Info Package mechanism described by this document provides the tools for such secure, end-to-end transport of application data.
INFO要求は、アプリケーション・レベルの情報を転送します。これの一つの含意は、INFOメッセージは、基礎となるSIPダイアログシグナリングよりもより高いレベルの保護を必要とするかもしれないということです。一つは盗聴や認証及び否認攻撃からSIPシグナリングを保護していない場合、特に、TLSトランスポートを使用することによって、例えば、次にINFO要求とその内容も脆弱であろう。 SIP / TLS、表示、変更、またはそれらは任意のSIPリクエストとすることができるように、INFOリクエストを傍受することができUASへのUACからのパスに沿った任意のSIPホップ有します。これは、いくつかのアプリケーションが自身をSIPシグナリングの、例えば、ホップバイホップ保護を超えて、INFOペイロードのエンドツーエンドの暗号化を必要とするかもしれないことを意味します。アプリケーションは、必要なセキュリティのレベルを指示するので、個々のインフォパッケージは、これらの要件を列挙しなければなりません。いずれにせよ、この文書で説明したインフォパッケージのメカニズムは、アプリケーション・データの安全な、エンド・ツー・エンドの輸送のためのツールを提供しています。
One interesting property of Info Package usage is that one can re-use the same digest-challenge mechanism used for INVITE-based authentication for the INFO request. For example, one could use a quality-of-protection (qop) value of authentication with integrity (auth-int), to challenge the request and its body, and prevent intermediate devices from modifying the body. However, this assumes the device that knows the credentials in order to perform the INVITE challenge is still in the path for the INFO request, or that the far-end UAS knows such credentials.
インフォパッケージの使用方法のひとつ興味深い特性は、1つのINFO要求に対するINVITEベースの認証に使用されるのと同じダイジェストチャレンジ・メカニズムを再利用できるということです。例えば、1は、要求とそのボディに挑戦、と体を変更するの中間デバイスを防ぐために、整合性（のauth-int型）を使用して認証の保護品質（QOP）値を使用することができます。しかし、これは、INFO要求のパスにまだあるINVITE挑戦を実行するために、資格情報を知っている、または遠端ことをUASがこのような資格情報を知っているデバイスを想定しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5621]キャマリロ、G.、RFC 5621 "メッセージ本文は、セッション開始プロトコル（SIP）で処理" を、2009年9月。
[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.
[RFC5727]ピーターソン、J.、ジェニングス、C.、およびR.スパークス、BCP 67、RFC 5727、2010年3月 "セッション開始プロトコル（SIP）とリアルタイムアプリケーションとインフラストラクチャ領域の変更処理"。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.
[RFC3398]キャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オング、 "セッション開始プロトコル（SIP）へのマッピング総合デジタル通信網（ISDN）ユーザ部（ISUP）"、RFC 3398、12月2002。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
"電話用のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ" [RFC3372] Vemuri、A.およびJ.ピーターソン、BCP 63、RFC 3372、2002年9月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "SIPを使用した基本的なネットワークメディアサービス"、RFC 4240、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[RFC5022]ヴァン・ダイク、J.、バーガー、E.、およびA.スピッツァー、 "メディアサーバ制御マークアップ言語（MSCML）とプロトコル"、RFC 5022、2007年9月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057]スパークス、R.、 "セッション開始プロトコルの複数の対話用法"、RFC 5057、2007年11月。
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, March 2008.
[RFC5168]レヴィン、O.、でも、R.、およびP. Hagendorf、 "メディアコントロールのためのXMLスキーマ"、RFC 5168、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項"、BCP 145、RFC 5405、2008年11月。
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup Language (MSML)", RFC 5707, February 2010.
[RFC5707]サリーム、A.、新、Y.、およびG. Sharratt、 "メディアサーバーマークアップ言語（MSML）"、RFC 5707、2010年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
[W3C.REC-voicexml21-20070619] Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M., Carter, J., Burke, D., Baggia, P., Candell, E., Burnett, D., McGlashan, S., and A. Lee, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[W3C.REC-voicexml21-20070619]ポーター、B.、Oshry、M.、Rehor、K.、オーバーン、R.、Bodell、M.、カーター、J.、バーク、D.、Baggia、P.、Candell 、E.、バーネット、D.、McGlashan、S.、およびA.リー、 "音声拡張マークアップ言語（VoiceXMLの）2.1"、World Wide Web Consortium（W3C）の勧告REC-voicexml21-20070619、2007年6月、<のhttp：// WWW .w3.org / TR / 2007 / REC-voicexml21-20070619>。
[SPEECHSC-MRCPv2] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", Work in Progress, November 2010.
[SPEECHSC-MRCPv2]バーネット、D.とS. Shanmugham、 "メディアリソース制御プロトコルバージョン2（MRCPv2）"、進歩、2010年11月での作業。
[ECMA-355] "Standard ECMA-355 Corporate Telecommunication Networks - Tunnelling of QSIG over SIP", ECMA http:// www.ecma-international.org/publications/standards/ Ecma-355.htm, June 2008.
[ECMA-355] "標準ECMA-355企業通信ネットワーク - SIPを超えるQSIGのトンネリング"、ECMAはhttp：// www.ecma-international.org/publications/standards/ ECMA-355.htm、2008年6月。
Appendix A. Acknowledgements
付録A.謝辞
The work on this document was influenced by "The Session Initiation Protocol (SIP) INFO Considered Harmful" (26 December 2002) written by Jonathan Rosenberg, and by "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" (15 January 2003) written by Dean Willis.
この文書の作業は、ジョナサン・ローゼンバーグによって書かれた「有害と考えられセッション開始プロトコル（SIP）INFO」（2002年12月26日）によると、「セッション開始プロトコルのためのINFOメソッドのパッケージ化と交渉」（2003年1月15日）の影響を受けましたディーンウィリスによって書かれました。
The following individuals have been involved in the work, and have provided input and feedback on this document:
以下の個人は仕事に携わってきました、そしてこの文書の入力とフィードバックを提供しています
Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Jonathan Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske, Roni Even, Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and Xavier Marjoum.
アダムローチ、アンダース・クリステンセン、アンドリュー・アレン、アルンArunachalam、ベン・キャンベル、ボブペンフィールド、ブラムVerburg、ブライアンStucker、クリスボールトン、クリスチャンStredicke、カレン・ジェニングス、デイル・ウォーリー、ディーンウィリス、エリックレスコラ、フランク・ミラー、ゴンサロ・カマリロ、ゴードン・ビース、ヘンリーSinnreich、イニャキバズカスティーヨ、ジェームズ・ジャクソン、ジェームズ・ラファティ、イェルーンバンBemmel、ジョエル・ハルパーン、ジョンエルウェル、ジョナサン・ローゼンバーグ、ユハHeinanen、キース糖剤、ケビン・アッタードCompagno、Manpreetシン、マーティン・ドリー、メアリー・バーンズ、マイケル・プロクター、ポールKyzivat、Peili徐、ピーターBlatherwick、ラジ・ジャイン、Rayeesカーン、ロバート・スパークス、ローランドJesske、ロニでも、サルヴァトーレ・ロレート、サム・ガネサン、サンジャイ・シンハ、スペンサードーキンススティーブLangstaff、スミットガーグ、そしてザビエルMarjoum。
John Elwell and Francois Audet helped with QSIG references. In addition, Francois Audet provided text for the revised abstract. Keith Drage provided comments and helped immensely with Table 1.
ジョンエルウェルとフランソワAudetはQSIGの参照を手伝ってくれました。また、フランソワAudetは、改訂された抽象のテキストを提供します。キース糖剤は、コメントを提供し、表1に非常に役立ちました。
Arun Arunachalam, Brett Tate, John Elwell, Keith Drage, and Robert Sparks provided valuable feedback during the working group last call process, in order to prepare this document for publication.
アルンArunachalam、ブレット・テイト、ジョンエルウェル、キース糖剤、およびロバート・スパークスは、出版のために、この文書を準備するために、ワーキンググループの最後の呼び出し処理中に貴重なフィードバックを提供しました。
Adam Roach, Dean Willis, John Elwell, and Paul Kyzivat provided valuable input in order to sort out the message body part usage for Info Packages.
アダムローチ、ディーンウィリス、ジョンエルウェル、そしてポール・Kyzivatは、インフォパッケージのメッセージボディ部の使用状況を整理するために、貴重な入力を提供します。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland
クリステルHolmbergのエリクソンHirsalantie 11 Jorvas、02420フィンランド
EMail: christer.holmberg@ericsson.com
メールアドレス：christer.holmberg@ericsson.com
Eric W. Burger Georgetown University
エリック・W.バーガージョージタウン大学
EMail: eburger@standardstrack.com URI: http://www.standardstrack.com
電子メール：eburger@standardstrack.com URI：http://www.standardstrack.com
Hadriel Kaplan Acme Packet 100 Crosby Drive Bedford, MA 01730 USA
Hadrielカプランアクメパケット100クロスビードライブベッドフォード、MA 01730 USA
EMail: hkaplan@acmepacket.com
メールアドレス：hkaplan@acmepacket.com