[要約] RFC 5768は、SIPでのICEのサポートを示すための方法を提案しています。目的は、SIPセッションの確立と通信の品質を向上させることです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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 ....................................................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]メッセージの2相交換を定義します。このオファー/回答メカニズムは、セッション開始プロトコル（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）を介して操作が困難です。彼らの目的はメディアパケットのフローを確立することであるため、メッセージ内にIPアドレスを運ぶ傾向があります。これは、NAT [RFC3235]を介して問題があることが知られています。これを改善するために、Interactive Connectivity Indecivity（ICE）と呼ばれるSDPへの拡張が定義されています[RFC5245]。ICEは、エージェントが多数のアドレスを収集し、すべてのアドレスをSDPオファーまたは回答に含める手順を定義し、その後、NAT（STUN）[RFC5389]接続性チェックのピアツーピアセッショントラバーサルユーティリティを使用して有効なアドレスを決定します。
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オプションタグ「Ice」を定義します。セクション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つの主要な動機があります。彼らはゲートウェイのサポートであり、電話に氷を要求します。
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をサポートしていないユーザーエージェントがあります。氷の展開を容易にするために、ドメインは片側の氷のエージェントとして機能するゲートウェイ、反対側の非氷のエージェントを使用することが予想されます。これにより、ドメインAからドメインBへの呼び出しが可能になり、ドメインBのデバイス自体がまだ氷をサポートしていない場合でも、氷を使用します。ただし、ドメイン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.
このような決定を下すために、この仕様はメディア機能タグ「SIP.ICE」を定義します。これは、レジスタリクエスト[RFC3840]のコンタクトヘッダーフィールドに含めることができます。これにより、レジストラは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は、回答者がそれをサポートしていないときに非氷の操作に戻るfall fall fall fallを提供しますが、オファーが氷なしで進むのではなく、むしろ通話を中止する場合があります。通常、これは、氷の能力のある仲間とは異なる非氷のピア用の別のM/C-Lineアドレスを選択したいからです。
To do this, the "ice" SIP option tag can be included in the Require header field of an INVITE request.
これを行うには、「ICE」SIPオプションタグを招待リクエストの要求ヘッダーフィールドに含めることができます。
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をサポートし、その結果、少なくとも1つの輸送プロトコルのSDPオファーまたは回答に候補属性を含めることができます。ICEをサポートするエージェントは、レジスタリクエストとオプション応答のコンタクトヘッダーフィールドにこのメディア機能タグを含める必要があります。
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.
エージェントには、招待または招待対応のコンタクトヘッダーフィールドにメディア機能タグを含めることができます。ただし、そうすることは、同じことを示すSDPの氷の属性で冗長です。招待状がオファーを省略した場合、コンタクトヘッダーフィールドのメディア機能タグの欠如または存在は、Callee（提供者になる）が使用することはできません。サードパーティのコールコントロール[RFC3725]の場合、発信者は氷をサポートする（またはしない）コントローラーである可能性がありますが、応答者は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.
この「ICE」オプションタグは、サポートされているヘッダーフィールドと組み合わせて使用しないでください（オプションリクエストへの応答を含めるべきではありません）。メディア機能タグは、氷のサポートを示すための唯一のメカニズムとして使用されます。オプションタグは、要求ヘッダーフィールドでのみ使用することを目的としています。招待リクエストの要求ヘッダーフィールドに配置された場合、ユーザーエージェントサーバー（UAS）がコールを処理するためにICEをサポートする必要があることを示します。エージェントは、ICEが完全またはLiteの実装のいずれかである場合、ICEをサポートし、その結果、少なくとも1つの輸送プロトコルの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.
悪意のある仲介者は、「ICE」オプションタグを含む必要なヘッダーフィールドを挿入することにより、SIPメッセージの変更を試みる場合があります。UASに氷が支えられていない場合、これにより、それ以外の場合は成功したときに呼び出しが失敗します。もちろん、この攻撃は氷に固有ではなく、任意のオプションタグを使用して実行できます。この攻撃は、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.
同様に、仲介者は、レジスタリクエストまたはオプションリクエストからメディア機能タグを削除しようとする場合があります。この攻撃は、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）拡張機能を識別するために使用されます。必要なヘッダーフィールドに存在する場合、エージェントが氷が必要であることを示します。
This section registers a new media feature tag in the SIP tree, defined in Section 12.1 of RFC 3840 [RFC3840].
このセクションでは、RFC 3840 [RFC3840]のセクション12.1で定義されている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.
この機能タグ：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.
典型的な使用の例：氷をサポートできる電話に通話をルーティングします。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[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月。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
Author's Address
著者の連絡先
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
Jonathan Rosenberg Jdrosen.netモンマス、ニュージャージー州
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net