Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5768 jdrosen.net
Category: Standards Track April 2010
ISSN: 2070-1721
Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）におけるインタラクティブ接続確立（ICE）のためのサポートを示します
Abstract
抽象
This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed.
この仕様は、セッション開始プロトコル（SIP）で使用するためのメディア特徴タグと、オプションタグを定義します。メディア特徴タグは、ユーザーエージェント（UA）は、それはICEをサポートし、そのレジストラに通信することができます。オプションタグは、UAが続行するコールためにICEのサポートを必要とすることができます。
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/rfc5768.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5768で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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 ....................................................2
2. Terminology .....................................................2
3. Motivation ......................................................3
3.1. Gateways ...................................................3
3.2. Mandating Support for ICE ..................................3
4. Media Feature Tag Definition ....................................3
5. Option Tag Definition ...........................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................4
7.1. Option Tag .................................................4
7.2. Media Feature Tag ..........................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................6
RFC 3264 [RFC3264] defines a two-phase exchange of Session Description Protocol (SDP) [RFC4566] messages for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [RFC3261].
RFC 3264 [RFC3264]はセッション記述プロトコル（SDP）の二相交流[RFC4566]マルチメディアセッションの確立の目的のためのメッセージを定義します。このオファー/アンサーメカニズムは、セッション開始プロトコル（SIP）[RFC3261]などのプロトコルによって使用されます。
Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a flow of media packets, they tend to carry IP addresses within their messages, which is known to be problematic through NAT [RFC3235]. To remedy this, an extension to SDP, called Interactive Connectivity Establishment (ICE) has been defined [RFC5245]. ICE defines procedures by which agents gather a multiplicity of addresses, include all of them in an SDP offer or answer, and then use peer-to-peer Session Traversal Utilities for NAT (STUN) [RFC5389] connectivity checks to determine a valid address.
オファー/アンサーを使用するプロトコルはネットワークアドレス変換（NAT）を介して動作することは困難です。彼らの目的は、メディアパケットの流れを確立することであるので、それらはNAT [RFC3235]を通じて問題があることが知られている彼らのメッセージ内のIPアドレスを運ぶ傾向にあります。この問題を解決するために、インタラクティブ接続確立（ICE）と呼ばれるSDPへの拡張は、[RFC5245]を定義されています。 ICEは、有効なアドレスを決定するために、ピア・ツー・ピアNAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]の接続性チェックを使用し、その後、薬剤はアドレスの多数を収集れる手順を定義SDPオファーまたはアンサーにそれらの全てを含み、。
This specification defines a media feature tag, "sip.ice", and a SIP option tag, "ice", that can be used by SIP User Agents that make use of ICE. Section 3 motivates the need for the media feature tag and option tag, and Section 4 and Section 5 formally define them.
この仕様は、メディア特徴タグ、「sip.ice」を定義し、ICEを利用するSIPユーザエージェントで使用可能なSIPオプションタグ、「氷」、。第3節では、正式にそれらを定義メディア特徴タグとオプションのタグ、および第4節と第5節の必要性に動機を与えます。
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]に記載されているように解釈されます。
There are two primary motivations for defining an option tag and a media feature tag. They are support for gateways, and requiring ICE for a call.
オプションタグとメディア特徴タグを定義するための2つの主要な動機があります。彼らは、通話のためのゲートウェイのサポート、および必要ICEです。
Unfortunately, ICE requires both endpoints to support it in order for it to be used. Within a domain, there will typically be User Agents that do and do not support ICE. In order to facilitate deployment of ICE, it is anticipated that domains will make use of gateways that act as ICE agents on one side, and non-ICE agents on the other side. This would allow a call from domain A into domain B to make use of ICE, even if the device in domain B does not itself yet support ICE. However, when domain B receives a call, it will need to know whether the call needs to pass through such a gateway, or whether it can go to the terminating UA directly.
残念ながら、ICEは、それが使用されるようにするために、それをサポートするために、両方のエンドポイントが必要です。ドメイン内では、一般的に行うと、ICEをサポートしていないユーザーエージェントが存在します。 ICEの展開を容易にするためには、ドメインは、他の側の片側にICE剤として作用ゲートウェイ、および非ICE剤の使用をすることが予想されます。これは、ドメインB内のデバイスは、まだICEをサポートしていませ自体ない場合でも、ICEを利用するために、ドメインBに、ドメインAからの呼び出しが可能になります。しかし、ドメインBがコールを受信したとき、それは、コールが、そのようなゲートウェイを通過する必要がある、またはそれが直接終端UAに行くことができるかどうかかどうかを知っておく必要があります。
In order to make such a determination, this specification defines a media feature tag, "sip.ice", which can be included in the Contact header field of a REGISTER request [RFC3840]. This allows the registrar to track whether or not a UA supports ICE. This information can be accessed by a proxy in order to determine whether or not a call needs to route through a gateway.
そのような決意をするために、この仕様は、REGISTERリクエスト[RFC3840]のContactヘッダーフィールドに含めることができるメディア特徴タグ、「sip.ice」を定義します。これは、レジストラがUAは、ICEをサポートしているかどうかを追跡することができます。この情報は、呼がゲートウェイを介してルーティングする必要があるか否かを判定するためにプロキシによってアクセスすることができます。
Although ICE provides a built in fall back to non-ICE operation when the answerer doesn't support it, there are cases where the offerer would rather abort the call rather than proceed without ICE. Typically, this is because they would like to choose a different m/c-line address for a non-ICE peer than they would for an ICE capable peer.
ICEは、回答がそれをサポートしていないとき、非ICE運転に戻って秋に建て提供しますが、オファー側はむしろ呼び出しを中止するのではなくICEなしで進行する場合があります。彼らはICEできるピアの場合と比べて、非ICEピアの異なるM / Cラインアドレスを選択したいので、典型的に、これは。
To do this, the "ice" SIP option tag can be included in the Require header field of an INVITE request.
これを行うには、「氷」SIPオプションタグは、INVITEリクエストのRequireヘッダーフィールドに含めることができます。
The "sip.ice" media feature tag indicates support for ICE. An agent supports ICE if it is either a lite or full implementation, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol. An agent that supports ICE SHOULD include this media feature tag in the Contact header field of its REGISTER requests and OPTION responses.
「sip.ice」メディア特徴タグは、ICEのサポートを示します。エージェントは、liteのか、完全な実装のいずれかの場合にICEをサポートし、その結果、候補者は、少なくとも一つのトランスポートプロトコルのためのSDP申し出か答えに属性を含めることができます。 ICEをサポートするエージェントは、そのREGISTER要求とOPTION応答のContactヘッダーフィールドにこのメディア特徴タグを含むべきです。
An agent MAY include the media feature tag in the Contact header field of an INVITE or INVITE response; however, doing so is redundant with ICE attributes in the SDP that indicate the same thing. In cases where an INVITE omits an offer, the lack or presence of the media feature tag in the Contact header field cannot be used by the callee (which will be the offerer) to determine whether the caller supports ICE. In cases of third-party call control [RFC3725], the caller may be a controller that does (or doesn't) support ICE, while the answerer may be an agent that does (or doesn't) support ICE.
エージェントは、INVITEまたはINVITE応答のContactヘッダーフィールドにおけるメディア特徴タグを含んでいてもよいです。しかし、そうすることは、同じことを示しているSDPのICE属性を持つ冗長です。オファーを省略しているINVITEの場合に、Contactヘッダーフィールドにおけるメディア特徴タグの欠如または存在は、発信者がICEをサポートするかどうかを決定する（オファーであろう）被呼者によって使用することができません。サードパーティ呼制御[RFC3725]の場合には、発信者が回答がない（またはしない）剤であってもよいが、ICEをサポートする（またはしない）コントローラであってもよいICEをサポートします。
This "ice" OPTION tag SHOULD NOT be used in conjunction with the Supported header field (this SHOULD NOT include responses to OPTION requests). The media feature tag is used as the one and only mechanism for indicating support for ICE. The option tag is meant to be used only with the Require header field. When placed in the Require header field of an INVITE request, it indicates that the User Agent Server (UAS) must support ICE in order to process the call. An agent supports ICE if it is either a full or lite implementation, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol.
この「氷」OPTIONタグ（これはOPTION要求への応答を含めるべきではありません）Supportedヘッダーフィールドと一緒に使用されるべきではありません。メディア特徴タグは、ICEのサポートを示すための唯一のメカニズムとして使用されます。オプションタグは、ヘッダのみを必要とする分野で使用することを意味します。 INVITEリクエストのRequireヘッダーフィールドに置かれたとき、それはユーザエージェントサーバ（UAS）がコールを処理するためにICEをサポートしなければならないことを示しています。エージェントは、それがいずれかの完全またはliteの実装である場合にはICEをサポートし、その結果、候補者は、SDPのオファーに属性または少なくとも一つのトランスポートプロトコルのために答えるなど、することができます。
A malicious intermediary might attempt to modify a SIP message by inserting a Require header field containing the "ice" option tag. If ICE were not supported on the UAS, this would cause the call to fail when it would otherwise succeed. Of course, this attack is not specific to ICE, and can be done using any option tag. This attack is prevented by usage of the SIPS mechanism as defined in RFC 3261.
悪意のある仲介者は「氷」オプションタグを含む要求ヘッダーフィールドを挿入することによりSIPメッセージを変更しようとするかもしれません。 ICEは、UASにサポートされていなかった場合は、これはそう成功するだろうというとき、コールが失敗する原因となります。もちろん、この攻撃は、ICEに特異的ではなく、任意のオプションタグを使用して行うことができます。 RFC 3261で定義されるように、この攻撃はSIPS機構の使用によって防止されます。
Similarly, an intermediary might attempt to remove the media feature tag from a REGISTER request or OPTIONS request, which might cause a call to skip ICE processing when it otherwise might make use of it. This attack is also prevented using the SIPS mechanism.
同様に、仲介者は、それはそれ以外の場合を利用する可能性がある場合ICE処理をスキップするための呼び出しを引き起こすかもしれないREGISTERリクエストまたはOPTIONS要求から、メディア特徴タグを削除しようとする場合があります。この攻撃は、SIPSメカニズムを使用して防止することができます。
This specification defines a new media feature tag and SIP option tag.
この仕様は、新たなメディア特徴タグとSIPオプションタグを定義します。
This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
このセクションでは、RFC 3261のセクション27.1のガイドラインあたりの新しいSIPオプションタグを定義します。
Name: ice
名前：氷
Description: This option tag is used to identify the Interactive Connectivity Establishment (ICE) extension. When present in a Require header field, it indicates that ICE is required by an agent.
説明：このオプションタグはインタラクティブ接続確立（ICE）の拡張子を識別するために使用されます。場合Requireヘッダーフィールドの存在は、ICEがエージェントによって必要とされることを示しています。
This section registers a new media feature tag in the SIP tree, defined in Section 12.1 of RFC 3840 [RFC3840].
このセクションでは、RFC 3840のセクション12.1 [RFC3840]で定義されたSIPツリーに新しいメディア特徴タグを登録します。
Media feature tag name: sip.ice
メディアフィーチャータグ名：sip.ice
ASN.1 Identifier: 1.3.6.1.8.4.22
ASN.1識別子：1.3.6.1.8.4.22
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports Interactive Connectivity Establishment (ICE).
このタグで示されるメディアフィーチャーの概要：この機能タグは、デバイスがインタラクティブ接続確立（ICE）をサポートしていることを示しています。
Values appropriate for use with this feature tag: Boolean.
ブール：この機能タグで使用するための適切な値。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
フィーチャータグは、主に以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図されています。この機能タグは、このような携帯電話やPDAなどのデバイスの機能を記述するために、通信アプリケーションに最も有用です。
Examples of typical use: Routing a call to a phone that can support ICE.
典型的な使用例：ICEをサポートすることができます携帯電話に通話をルーティング。
Related standards or documents: RFC 5768
関連する規格または文書：RFC 5768
Security Considerations: Security considerations for this media feature tag are discussed in Section 6 of this document.
セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、このドキュメントのセクション6で議論されています。
[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月。
[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月。
[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）とのオファー/アンサーモデル"。
[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）におけるユーザエージェントの能力を示します"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D.、 "ネットワークアドレス変換（NAT）フレンドリアプリケーションの設計ガイドライン"、RFC 3235、2002年1月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
Author's Address
著者のアドレス
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
ジョナサン・ローゼンバーグjdrosen.netモンマス、NJ US
EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net
電子メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net