[要約] RFC 6086は、SIPのINFOメソッドとパッケージフレームワークに関する仕様です。このRFCの目的は、SIPセッション中に非呼制御情報を伝達するためのメカニズムを提供することです。
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）情報方法とパッケージフレームワーク
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）のメソッド、情報、および情報パッケージメカニズムを定義します。このドキュメントはRFC 2976を廃止します。後方互換性のために、このドキュメントは、このドキュメントの「レガシー情報使用」と呼ばれるRFC 2976で以前に定義された使用法と互換性のある情報方法の「レガシー」使用モードも指定しています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]のメソッド、情報を定義します。
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).
情報メッセージの目的は、SIPダイアログシグナリングパスを使用して、エンドポイント間にアプリケーションレベルの情報を伝達することです。情報方法は、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.
情報方法の使用は、個別のダイアログの使用を構成するものではありません。情報メッセージは常に招待ダイアログ使用[RFC5057]の一部であり、その運命を共有しています。情報メッセージは、他のダイアログ使用の一部として、または既存のダイアログの外側として送信することはできません。
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.
このドキュメントは、情報パッケージメカニズムも定義しています。情報パッケージの仕様では、情報パッケージに関連付けられた情報メッセージに掲載された情報のコンテンツとセマンティクスを定義します。情報パッケージメカニズムは、ユーザーエージェント（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は、Dialogごとに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は、空のRECV-INFOヘッダーフィールド（値のないヘッダーフィールド）を使用して、情報パッケージの情報リクエストを受け取ることができないことを示し、他のUASに情報パッケージメカニズムをサポートしていることを通知できます。
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が情報要求を送信すると、情報パッケージヘッダーフィールドを使用して、どの情報パッケージがリクエストに関連付けられているかを示します。1つの特定の情報要求は、単一の情報パッケージにのみ関連付けられます。
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]で定義されていた情報方法を使用して、ここでは「レガシー情報の使用」と呼ばれます。これらには、以下に限定されません。
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および第3世代パートナーシッププロジェクト（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は、必要なヘッダーフィールドのオプションタグを使用して、レシーバーが情報コンテンツを理解していることを確認します。
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 企業は、高速ビデオの更新を要求するために情報メッセージを使用しています。現在、リアルタイム輸送制御プロトコル（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）トーンを輸送するために情報メッセージを使用しています。すべてのメカニズムは独自であり、標準化されていません。
Some legacy INFO usages are also recognized as being shortcuts to more appropriate and flexible mechanisms.
一部のレガシー情報の使用は、より適切で柔軟なメカニズムのショートカットであると認識されています。
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は、SIP UAが（1）UAが情報方法をサポートするアプリケーションとコンテキストの種類、または（2）特定の情報メッセージがあるアプリケーションとコンテキストのタイプとコンテキストを示すことを可能にするメカニズムを定義しませんでした。関連する。
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.
レガシー情報の使用には関連する情報パッケージがないため、レガシー情報の使用でRECV-INFOおよび情報パッケージヘッダーフィールドを使用することはできません。つまり、UAは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.
上記の問題により、レガシー情報の使用は、UASが情報方法をサポートするアプリケーションとコンテキストの種類と、情報メッセージで輸送されるアプリケーション情報を処理する方法を示すための静的な構成を必要とすることがよくあります。これにより、業界の相互運用性の問題が発生しました。
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ワーキンググループは、長年にわたって重要な議論に費やして、情報を修正することがより適切であるかどうか（使用方法の登録メカニズムを定義するか、それを完全に非難する（）（それを完全に非難する）ことを合意してきました（RFC 3398 [RFC3398]で説明されている使用法は、唯一の正当な使用法として祖父になっています）。情報を完全に非難する傾向がある人々による実質的なコンセンサスの構築と譲歩は必要でしたが、ワーキンググループの最終的な方向性は、この仕様で定義されている情報パッケージの登録のフレームワークを公開することでした。
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, 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".
このドキュメントでは、セッション開始プロトコル（SIP）[RFC3261]のメソッド、情報、および情報パッケージメカニズムを定義します。このドキュメントは、RFC 2976 [RFC2976]を廃止します。後方互換性のために、このドキュメントは、RFC 2976で以前に定義された使用法と互換性のある情報方法の「レガシー」使用モードを指定します。ここでは「レガシー情報の使用」と呼ばれます。
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:
後方互換性のために、このドキュメントはレガシー情報の使用を非難するものではなく、ユーザーがそのような使用法の情報パッケージを定義することを義務付けません。でも：
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. UAは、情報パッケージヘッダーフィールドをレガシー情報リクエストに挿入してはなりません（セクション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. 新しい使用法は、この仕様で定義されている情報パッケージメカニズムを使用する必要があります。これは、レガシー情報の使用に関連する問題を共有していないため、情報パッケージは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. UASは、同じ招待ダイアログ使用の一部としてレガシー情報の使用と情報パッケージの両方の使用を有効にすることができますが、UASは同じアプリケーションレベルの情報を輸送するためにレガシー情報の使用と情報パッケージの使用を組み合わせてはなりません。可能であれば、UASは情報パッケージの使用を好むものとします。
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.
情報方法は、SIPアプリケーションをさらに強化できるアプリケーションレベル情報を輸送するためのメカニズムを提供します。セクション8では、情報の使用が適切なアプリケーションの種類の詳細について説明します。
This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFO messages.
このセクションでは、UAが情報のリクエストと応答、および情報メッセージに含まれるメッセージ本文を処理する方法について説明します。
An INFO request can be associated with an Info Package (see Section 5), or associated with a legacy INFO usage (see Section 2).
情報要求は、情報パッケージ（セクション5を参照）に関連付けたり、レガシー情報の使用（セクション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.
情報リクエストの構築は、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が情報パッケージに関連付けられた情報要求を送信する場合、リクエストに関連付けられている情報パッケージを示す情報パッケージヘッダーフィールドを含める必要があります。特定の情報要求は、単一の情報パッケージにのみ使用できます。
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がレガシー情報の使用に関連付けられた情報要求を送信する場合、リクエストに関連付けられた情報パッケージはなく、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.
情報要求には、RECV-INFOヘッダーフィールドを含めてはなりません。UAは、セクション5にリストされているSIPメソッド（およびその応答）を使用して、情報要求を受け取る意思のある情報パッケージのセットのみを示すことができます。
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は、招待ダイアログの使用状況外に情報リクエストを送信してはなりません。また、リモートUAがそのダイアログ内でその情報パッケージを受け取る意欲を示していない場合、Inviteダイアログの使用法の中で情報パッケージの情報要求を送信しないでください。
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.
RFC 5057 [RFC5057]に基づいて、UAが情報要求に対する469（悪い情報パッケージ）応答を受信した場合、応答はトランザクションのみの障害を表し、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.
フォーキングの可能性があるため、初期の招待リクエストを送信する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）（最初の招待リクエストの受信者）がダイアログを作成する応答を送信した直後に情報リクエストを送信する場合、UASは情報リクエストが到達する可能性のために準備する必要があります。ダイアログ作成応答の前にユーザーエージェントクライアント（UAC）があるため、UACによって拒否される可能性があります。さらに、Remote UAが情報リクエストを受け取る意思がある新しい情報パッケージを送信すると同時にUAが情報リクエストを送信する場合、レース条件のために情報要求が拒否される場合があります。
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.
UAがUAが受け取る意欲を示していない情報パッケージに関連付けられた情報リクエストを受信した場合、UAは469（悪い情報パッケージ）応答を送信する必要があります（セクション11.6を参照）。UAが情報リクエストを喜んで受け取るパッケージ。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が情報パッケージに関連付けられた情報リクエストを受信し、コンテンツディスポジション「情報パッケージ」（セクション4.3.1を参照）のメッセージ本文の部分には、UAがサポートしていない多目的インターネットメールエクステンション（MIME）タイプがありますその情報パッケージのコンテキストでは、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.
それ以外の場合、情報リクエストが構文的に正しく、十分に構造化されている場合、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.
注：アプリケーションが情報要求で受け取った情報を拒否する必要がある場合、アプリケーションレベルで実行する必要があります。つまり、アプリケーションは新しい情報要求をトリガーする必要があります。これには、以前に受信したアプリケーションデータが受け入れられなかった情報が含まれています。個々の情報パッケージ仕様そのような手順の詳細を説明する必要があります。
Proxies need no additional behavior beyond that described in RFC 3261 to support 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.
情報要求の目的は、SIP UAS間にアプリケーションレベルの情報を携帯することです。アプリケーション情報データは、情報リクエストのメッセージ本文のペイロードに含まれています。
NOTE: An INFO request associated with an Info Package can also include information associated with the Info Package using Info-Package header field parameters.
注：情報パッケージに関連付けられた情報要求には、情報パッケージヘッダーフィールドパラメーターを使用して情報パッケージに関連付けられた情報も含めることができます。
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.
情報パッケージに関連付けられている情報要求にメッセージ本文の部分が含まれている場合、ボディの部分はコンテンツディスポジションヘッダーフィールド「情報パッケージ」値によって識別されます。ボディの部分には、単一のMIMEタイプを含めることができます。または、情報パッケージに関連付けられた他の身体部分を含むマルチパート[RFC5621]にすることができます。
UAs MUST support multipart body parts in accordance with RFC 5621.
UASは、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.
注：情報要求には、招待ダイアログの使用状況のコンテキスト内で意味のある他の身体部分を含めることもできますが、情報方法と関係するアプリケーションに特に関連付けられていません。
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はその情報パッケージに従ってメッセージボディタイプもサポートする必要があります。ただし、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には、情報応答に情報パッケージに関連付けられたメッセージ本文を含めてはなりません。情報パッケージに関連付けられたメッセージ本文は、情報リクエストでのみ送信する必要があります。
A UA MAY include a message body that is not associated with an Info Package in an INFO response.
UAには、情報応答の情報パッケージに関連付けられていないメッセージ本文が含まれる場合があります。
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.
情報パッケージメカニズムは、配信順序メカニズムを定義しません。情報パッケージは、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.
情報パッケージの仕様では、情報パッケージに関連付けられた情報メッセージに掲載された情報のコンテンツとセマンティクスを定義します。情報パッケージメカニズムは、UASが情報リクエストを受け取る意思がある情報パッケージを示す方法を提供し、どの情報パッケージに特定の情報要求が関連付けられていますか。
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が情報パッケージをどのように処理するか、UAがRECV-INFOヘッダーフィールドを使用する方法、およびUAがRe-Inviteロールバックの状況でどのように作用するかについて説明します。
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ヘッダーフィールドを使用して示す必要があります。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は、ダイアログ確立中に情報要求を受け取る意思のある情報パッケージのセットを提供します。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が、ダイアログ確立中または招待ダイアログの使用中に情報パッケージの情報要求を受け取る意思がない場合、UAは空のRECV-INFOヘッダーフィールドを含めることでこれを示す必要があります。これは、UAがまだ情報パッケージメカニズムをサポートしていることを他のUASに通知します。
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が以前にrecv-infoヘッダーフィールドに情報パッケージ「foo」と「bar」を示していた場合、招待ダイアログの使用の存続期間中のUAは、任意の情報リクエストを受け取りたくないことを示す必要があります。情報パッケージはもう、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が特定の情報パッケージの情報リクエストを喜んで受信し、ダイアログが確立されたことを示したら、UAは、UAがそれがもはや意欲でないことを示すまで、その情報パッケージに関連付けられた情報要求を受信する準備をする必要がありますその情報パッケージに関連付けられた情報要求を受信します。
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 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がその情報パッケージの情報リクエストを受け取ることを望んでいることを示す、またはUAが兆候を受け取った後に、情報パッケージに関連付けられた情報リクエストを送信してはなりません。Remote UAは、その情報パッケージに関連付けられた情報リクエストを受け取る気がありません。
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が情報要求を受け取る新しい情報パッケージを備えたRECV-INFOヘッダーフィールドを含むメッセージを送信した場合、リモートUAはメッセージを受信する前に、情報リクエストベースを送信する可能性があります古い情報パッケージのセット。この場合、情報の受信者は拒否を要求し、情報要求に対する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が同様の機能を提供する複数の情報パッケージを示している場合、情報パッケージの優先順位を示すことはできません。また、UAが情報パッケージのいずれかの情報要求のみを受け取ることを希望することを示すことはできません。そのような場合のアプリケーションの動作を説明するために、情報パッケージに関連付けられたアプリケーションロジックと特定の情報パッケージ仕様次第です。
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が情報パッケージメカニズムのサポートを示していても、レガシー情報の使用を可能にすることが許可されています。さらに、UAがAllow Headerフィールド[RFC3261]を使用して情報方法のサポートを示している場合、情報パッケージメカニズムのサポートを暗黙的に示していません。UAは、情報パッケージメカニズムをサポートすることを示すために、RECV-INFOヘッダーフィールドを使用する必要があります。同様に、UAがRECV-INFOヘッダーフィールドを使用して情報パッケージメカニズムをサポートすることを示す場合でも、UAはAllowヘッダーを使用して情報方法のサポートを示しています。
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 最初の招待リクエストの送信者は、送信者が情報パッケージに関連付けられた情報要求を受け取ることをいとわない場合でも、最初の招待リクエストに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.
o RECV-INFOヘッダーフィールドを含むリクエストの受信者は、リクエストに空のRECV-INFOヘッダーフィールドが含まれていても、ヘッダーであっても、リクエストに対する18x/2XXの信頼性の高い18x/2XX応答にRECV-INFOヘッダーフィールドを含める必要がありますレシーバーのフィールド値は、以前に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.
o 関連する要求にRECV-INFOヘッダーフィールドが含まれていなかった場合、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の回答と同様に、受信者は、同じ招待/reviteトランザクションに対して複数の応答（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/Re-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は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.
RECTV-INFOヘッダーフィールドを使用して要求ターゲットを決定するのではなく、RFC 3840 [RFC3840]に基づいて、より適切なメカニズムを使用することをお勧めします。ただし、このドキュメントは、情報パッケージメカニズムの機能タグ、または特定の情報パッケージの機能タグを定義するメカニズムを定義しません。
This document describes one new SIP method: INFO. This document replaces the definition and registrations found in RFC 2976 [RFC2976].
このドキュメントでは、1つの新しいSIPメソッドについて説明します。情報。このドキュメントは、RFC 2976 [RFC2976]に見られる定義と登録に置き換えられます。
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
この表は、RFC 3261 [RFC3261]の表2および3に拡張されています。
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
Table 1: Summary of Header Fields
表1：ヘッダーフィールドの概要
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
この表は、RFC 3261 [RFC3261]の表2および3に拡張されています。
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：情報関連のヘッダーフィールド
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ヘッダーフィールドのサポートと使用は、レガシー情報の使用のみをサポートするUASには適用されません。
* Not applicable to INFO requests and responses associated with legacy INFO usages.
* レガシー情報の使用に関連する情報のリクエストと応答には適用されません。
** 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.
**関連する招待リクエストにRECV-INFOヘッダーフィールドが含まれている場合、少なくとも1つの信頼できる18x/2xx応答で招待リクエストに送信された場合。
*** Mandatory if the associated request contained a Recv-Info header
field.
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では、情報パッケージヘッダーフィールドの使用について説明します。
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-infoで示された情報パッケージタイプと情報パッケージヘッダーフィールド値にあるものと一致する目的のために、情報パッケージヘッダーフィールドフィールドの情報パッケージタイプ部分の情報パッケージ部分の部分を比較します。RECV-INFOヘッダーフィールド値のオクテット。つまり、情報パッケージ名はケースに敏感です。Info-Package-Paramは、比較チェックアルゴリズムの一部ではありません。
This document does not define values for Info-Package types. Individual Info Package specifications define these values.
このドキュメントは、情報パッケージタイプの値を定義しません。個々の情報パッケージ仕様は、これらの値を定義します。
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-infoを追加します。セクション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ダイアログ内で、ユースケースの適切なメカニズムですか？それは、それが最も合理的で適切な選択だから、それとも単に「簡単だ」からですか？特定のユースケースの不適切なメカニズムを選択すると、メカニズムが使用されている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.
情報メッセージは、アプリケーション情報を搭載しているため、他の多くの種類のSIPメッセージとは異なり、情報メッセージのサイズとレートはアプリケーションによって直接決定されます。これにより、アプリケーション情報トラフィックは、そのインフラストラクチャの他のトラフィックに干渉したり、データレートが高すぎるときに自己干渉したりする可能性があります。
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.
情報要求のためのデフォルトのスロットリングメカニズムはありません。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ロケーションの更新など、他のアプリケーションは、招待ダイアログの使用の寿命の間に高いレートの情報要求を生成する可能性があります。
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.
情報パッケージのデザイナーとそれを使用するアプリケーションは、情報メッセージが運ばれることを保証できないため、ネットワークおよび他のトラフィックに情報メッセージのサイズとレートが与える影響を考慮する必要があります。混雑制御輸送プロトコルのエンドツーエンド。このような輸送プロトコルを介して情報メッセージが送信されたとしても、下流の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メッセージは、500バイトから32Kバイトのオーダーで比較的小さくなる傾向があります。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サブスクライブと通知方法を使用するサブスクリプションベースのイベント[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.
情報要求は常にの一部であり、既存の招待ダイアログの使用法の一部であり、運命を共有していますが、サブスクライブリクエストは個別のダイアログ使用[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.
Stateful SIPプロキシと連続したユーザーエージェント（B2BUAS）を介してメッセージを登録/通知するメッセージは、サブスクリプションダイアログによって引き起こされるリソースの影響を考慮する必要があります。ユーザーごとのサブスクリプションダイアログの数も考慮する必要があります。
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シグナルプレーンベースのメカニズムに関しては、サブスクライブ/通知メッセージは、ダイアログルートセットの一部であるが、アプリケーション情報には関心がない中間SIPエンティティに大きな負担をかける可能性があります。エンドユーザー間で輸送されます。
The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user.
メッセージメソッド[RFC3428]は、通常、ユーザーにレンダリングするためにMIMEコンテンツを送信するために、1回限りのインスタントメッセージ交換を定義します。
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つは、メディアリソース制御プロトコル（MRCP）[SpeechSC-MRCPV2]です。ここでは、透過制御プロトコル（TCP）[RFC0793]またはストリーム制御伝送プロトコルなどのメディアプレーン接続指向チャネルがあります。（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.
もう1つの選択肢は、HTTP [RFC2616]などのSIP非依存メカニズムを使用することです。このモデルでは、UAは情報の転送のためにHTTP要求を指示できるランデブーポイントについて知っています。例には、SIPリクエストURI [RFC4240]で取得するためのプロンプトのエンコードまたはvoiceXML [w3c.rec-voicexml21-20070619]スクリプトでの送信ターゲットのエンコードが含まれます。
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].
このセクションでは、情報方法に必要なRFC 3261で定義されているABNF構文の構文拡張について説明し、情報パッケージとRECV-INFOヘッダーフィールドの定義を追加します。前のセクションでは、セマンティクスについて説明します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に適合しています。
INFOm = %x49.4E.46.4F ; INFO in caps
Method =/ 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
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 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.
情報パッケージ仕様は、この仕様で「必須」または「必須」で指定された動作を弱めてはなりません。ただし、情報パッケージに関連するアプリケーションがそれを必要とする場合、情報パッケージの仕様は「必要な」、「5月」、または「推奨」要件を「必要」に強化する場合があります。
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.
情報パッケージの仕様には、情報パッケージの全体的な説明が含まれている必要があります。情報パッケージに関連付けられた情報リクエストに掲載されている情報の種類、およびUASが情報パッケージを使用できるアプリケーションと機能の種類について。
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では、より多くの情報を提供し、特定のユースケースを解決するために考慮すべき代替メカニズムについて説明します。
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.
情報パッケージの仕様は、UASがヘッダーフィールド値（「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).
情報パッケージ仕様は、RECV-INFOまたは情報パッケージヘッダーフィールドで使用できる情報パッケージパラメーターと、情報パッケージ名を示すヘッダーフィールド値（セクション10.4を参照）を定義できます。
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タイプなどの身体部分を定義するか、身体部分を定義する他のドキュメントを参照する必要があります。
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タイプが情報パッケージに関連付けられている場合、情報パッケージの仕様は、単一の情報要求に複数のボディパーツを含めるために、UASがマルチパートボディパーツを使用する必要があるかどうかを定義する必要があります。
If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document such restrictions.
UASが情報パッケージを使用する方法に制限がある場合、情報パッケージの仕様はそのような制限を文書化する必要があります。
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.
UASが情報パッケージに関連付けられた重複（未解決の）情報リクエストを送信できるかどうかに関連する制限がありますか、またはUAが同じ情報パッケージに関連付けられた以前の情報要求の応答を待たなければならないかどうか。
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.
また、UASが情報パッケージを使用するときに他のSIP拡張機能と機能をサポートおよび使用する必要があるかどうか、およびUASが他の情報パッケージと一緒に情報パッケージを使用する方法に関連する制限がある場合に関連する制限がある場合があります。
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で定義されているように、UASは通常、情報要求に200（OK）応答を送信します。情報パッケージに関連付けられたアプリケーションロジックは、UASが情報パッケージに関連付けられた制限に従わない状況を処理する必要があります。
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.
ダイアログ内の情報パッケージに関連付けられた情報要求をUASが送信できる最大または最小レートがある場合、情報パッケージ仕様はレート値を文書化する必要があります。
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.
レートが異なる場合、情報パッケージの仕様は、UASがレートを示したり交渉したりするために使用できる情報パッケージパラメーターを定義する場合があります。または、レート情報は、情報パッケージに関連付けられたアプリケーションデータ情報の一部にすることができます。
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.
情報パッケージに関連付けられた情報要求に携帯されているアプリケーション情報には、一定レベルのセキュリティが必要な場合、情報パッケージの仕様は、必要なセキュリティを提供するためにUASが使用する必要があるメカニズムを説明する必要があります。
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]を義務付けるだけでは不十分な場合があります。後続のホップを保証する方法は、ペイロードをクリアテキストに転送しません。アプリケーションレベルで安全な輸送を確保する最良の方法は、アプリケーションレベルでセキュリティを持つことです。これを達成する1つの方法は、Secure/Multipurpose Internet Mail Extensions（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]
方法：情報リファレンス：[RFC2976]
to:
に：
Method: INFO 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: 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-INFOコンパクトフォーム：（なし）リファレンス：[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
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の情報リクエストを受け取る意思があることを示します。
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: ...
...
...
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は200（OK）応答をUACに送り返し、UASは情報パッケージRとTの情報リクエストを喜んで受け取ることを示しています。
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: ...
...
...
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
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は、Inviteダイアログの使用状況内で更新リクエストを送信します。UACは（空のRECV-INFOヘッダーフィールドを使用して）情報パッケージの情報リクエストを受け取ることを望んでいないことを示します。
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: ...
...
...
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は200（OK）応答をUACに送り返し、UASは情報パッケージRとTの情報リクエストを喜んで受け取ることを示しています。
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: ...
...
...
The UA sends an INFO request associated with Info Package "foo".
UAは、情報パッケージ「Foo」に関連付けられた情報リクエストを送信します。
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
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拡張機能は、情報パッケージとは無関係に、ボディパーツのペイロードを情報要求に追加することがあります。この場合、情報パッケージのペイロードはマルチパート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: ...
--theboundary
Content-Type: application/mumble
...
<mumble stuff>
<マンブルのもの>
--theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59
-TheBoundary Content-Type：Application/FOO-Xコンテンツ - 分散：情報パッケージコンテンツレングス：59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
私はfoo-xメッセージタイプであり、私は情報パッケージfoo-theboundaryに属します -
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: ...
--theboundary Content-Type: application/foo-x Content-length: 59 I am a foo-x message type, and I belong to Info Package foo
-TheBoundary Content-Type：Application/Foo-Xコンテンツレングス：59私はFoo-Xメッセージタイプです。
<mumble stuff>
<マンブルのもの>
--theboundary Content-Type: application/foo-y Content-length: 59
-TheBoundary Content-Type：Application/FOO-Yコンテンツレングス：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.
情報パッケージに関連付けられているボディパーツペイロードには、「情報パッケージ」以外のコンテンツディスポジションヘッダーフィールド値を持つことができます。この場合、身体部分はマルチパート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: ...
--theboundary Content-Type: application/foo-x Content-Disposition: icon Content-length: 59
-TheBoundary Content-Type：Application/FOO-Xコンテンツ - 分散：アイコンコンテンツレングス：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.
適切なコミュニティレビューなしで情報メッセージの複数の使用法を排除し、無関係な情報リクエストを意図的に送信することにより、Rogue SIP UAが別のUAを混乱させる可能性を排除することにより、インターネットのセキュリティを改善するための情報の使用に関するこのドキュメントの明確化を期待しています。Rogue UASはまだ無関係な情報リクエストを送信できますが、このメカニズムにより、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.
情報パッケージのコンテンツがプライベートの場合、UASはコンテンツへのアクセスを防ぐために、S/MIMEなどのエンドツーエンド暗号化を使用する必要があります。情報の輸送はエンドツーエンドではなく、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.
情報要求は、アプリケーションレベルの情報を輸送します。これの1つの意味は、情報メッセージに基礎となるSIPダイアログシグナルよりも高いレベルの保護が必要になる可能性があることです。特に、たとえばTLSトランスポートを使用して、盗聴または認証および拒否攻撃からSIPシグナリングを保護しない場合、情報要求とそのコンテンツも同様に脆弱になります。SIP/TLSがあっても、SIPホップはUACからUASへのパスに沿って、SIPリクエストを使用して情報リクエストを表示、変更、または傍受できます。これは、一部のアプリケーションが情報ペイロードのエンドツーエンドの暗号化を必要とする場合、たとえば、SIPシグナル自体のホップバイホップ保護などを超えて必要になる場合があります。アプリケーションは必要なセキュリティのレベルを決定するため、個々の情報パッケージはこれらの要件を列挙する必要があります。いずれにせよ、このドキュメントで説明されている情報パッケージメカニズムは、アプリケーションデータの安全でエンドツーエンドの輸送のためのツールを提供します。
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つは、情報要求に招待ベースの認証に使用される同じダイジェストチャレンジメカニズムを再利用できることです。たとえば、整合性のある認証（auth-int）の認証の品質（QOP）値を使用して、リクエストとその本体に挑戦し、中間デバイスが本体の変更を防ぐことができます。ただし、これは、招待チャレンジを実行するために資格情報を知っているデバイスを想定しています。これは、情報リクエストのパスにある、またはファーエンドUASがそのような資格情報を知っていることを想定しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Crocker、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5621] Camarillo、G。、「セッション開始プロトコル（SIP）でのメッセージ本文処理」、RFC 5621、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] Peterson、J.、Jennings、C。、およびR. Sparks、「セッション開始プロトコル（SIP）およびリアルタイムアプリケーションとインフラストラクチャエリアの変更プロセス」、2010年3月、BCP 67、RFC 5727。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976] Donovan、S。、「The SIP Info Method」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「Integrated Services Digital Network（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）マッピング」、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[RFC3372] Vemuri、A。およびJ. Peterson、「電話のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ」、BCP 63、RFC 3372、2002年9月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] Campbell、B.、Rosenberg、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] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きベーシックネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（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] Van Dyke、J.、Burger、E。、およびA. Spitzer、「Media Server Control Markup Language（MSCML）およびProtocol」、RFC 5022、2007年9月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、RFC 5057、2007年11月。
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, March 2008.
[RFC5168] Levin、O.、Even、R。、およびP. Hagendorf、「XML Schema for Media Control」、RFC 5168、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン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] Eggert、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] Saleem、A.、Xin、Y。、およびG. Sharratt、「Media Server Markup Language（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. Turner、「Secure/Multipurpose Internet Mail Extensions（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] Porter、B.、Oshry、M.、Rehor、K.、Auburn、R.、Bodell、M.、Carter、J.、Burke、D.、Baggia、P.、Candell、E.、Burnett、D.、McGlashan、S。、およびA. Lee、「Voice Extensible Markup Language（VoiceXML）2.1」、World Wide Web Consortiumの推奨REC-VOICEXML21-20070619、2007年6月、<http：// wwwww.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] Burnett、D。およびS. Shanmugham、「Media Resource Control Protocolバージョン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月。
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）情報」（2002年12月26日）、および「セッション開始プロトコルの情報方法のパッケージ化と交渉」（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.
アダム・ローチ、アンダース・クリステンセン、アンドリュー・アレン、アルン・アルナチャラム、ベン・キャンベル、ボブ・ペンフィールド、ブラム・バーバーグ、ブライアン・スタッカー、クリス・ボールトン、クリスチャン・ストレディック、カレン・ジェニングス、デール・ウォーリー、ディーン・ウィリス、エリック・レスカルラ、フランク・ミラー、ゴンザロ・カマリロ、ガードン・ビーイアス、ヘンリー・シン・ライヒ、イナキ・バズ・カスティージョ、ジェームズ・ジャクソン、ジェームズ・ラファティ、ジェロエン・ヴァン・ベンメル、ジョエル・ハルパーン、ジョン・エルウェル、ジョナサン・ローゼンバーグ、ジュハ・ヘイナネン、キース・ドレイジ、ケビン・アタード・コンパニョ、マンプリート・シン、マンプリート・シン、メアリー・バーンズ、マイケル・プロクター、ポール・バーンズKyzivat、Peili Xu、Peter Blatherwick、Raj Jain、Rayees Khan、Robert Sparks、Roland Jesske、Roni Even、Salvatore Loreto、Sam Ganesan、Sanjay Sinha、スペンサーDawkins、Steve Langstaff、Sumit Garg、Xavier 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.
ジョン・エルウェルとフランソワ・オーデットはQSIGの参照を手伝いました。さらに、Francois 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.
Arun Arunachalam、Brett Tate、John Elwell、Keith Drage、およびRobert Sparksは、この文書を公開するために、ワーキンググループの最後のコールプロセス中に貴重なフィードバックを提供しました。
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.
Adam Roach、Dean Willis、John Elwell、およびPaul Kyzivatは、情報パッケージのメッセージ本体部分の使用法を整理するために貴重な入力を提供しました。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas、02420フィンランド
EMail: christer.holmberg@ericsson.com
Eric W. Burger Georgetown University
エリック・W・バーガー・ジョージタウン大学
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Hadriel Kaplan Acme Packet 100 Crosby Drive Bedford, MA 01730 USA
ハドリエルカプランACMEパケット100 Crosby Drive Bedford、MA 01730 USA
EMail: hkaplan@acmepacket.com