[要約] RFC 4091は、SDPグループ化フレームワークのための代替ネットワークアドレスタイプ（ANAT）セマンティクスに関するものです。このRFCの目的は、SDPセッションのネットワークアドレスタイプのグループ化をサポートすることです。
Network Working Group G. Camarillo
Request for Comments: 4091 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.
このドキュメントでは、セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクスを定義します。ANATセマンティクスにより、代替タイプのネットワークアドレスが特定のメディアストリームを確立することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope and Relation with Interactive Connectivity
Establishment. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 3
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informational References . . . . . . . . . . . . . . . . 5
A Session Description Protocol (SDP) [2] session description contains the media parameters to be used in establishing a number of media streams. For a particular media stream, an SDP session description contains, among other parameters, the network addresses and the codec to be used in transferring media. SDP allows for a set of codecs per media stream, but only one network address.
セッション説明プロトコル（SDP）[2]セッション説明には、多くのメディアストリームの確立に使用されるメディアパラメーターが含まれています。特定のメディアストリームの場合、SDPセッションの説明には、他のパラメーターの中でも、ネットワークアドレスとメディアの転送に使用されるコーデックが含まれています。SDPでは、メディアストリームごとのコーデックのセットを許可しますが、ネットワークアドレスは1つだけです。
The ability to offer a set of network addresses to establish a media stream is useful in environments with both IPv4-only hosts and IPv6-only hosts, for instance.
メディアストリームを確立するために一連のネットワークアドレスを提供する機能は、たとえばIPv4のみのホストとIPv6のみのホストの両方を持つ環境で役立ちます。
This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework [4]. The ANAT semantics allow for the expression of alternative network addresses (e.g., different IP versions) for a particular media stream.
このドキュメントでは、SDPグループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクスを定義します[4]。ANATセマンティクスにより、特定のメディアストリームの代替ネットワークアドレス（例：異なるIPバージョン）の表現が可能になります。
The ANAT semantics are intended to address scenarios that involve different network address types (e.g., different IP versions). They are not intended to provide alternative transport addresses with the same network type. Systems that need to provide different transport addresses with the same network type should use the SDP format defined in ICE (Interactive Connectivity Establishment) [6] instead.
ANATセマンティクスは、さまざまなネットワークアドレスタイプ（さまざまなIPバージョンなど）を含むシナリオに対処することを目的としています。それらは、同じネットワークタイプの代替輸送アドレスを提供することを意図していません。同じネットワークタイプで異なる輸送アドレスを提供する必要があるシステムは、代わりにICE（インタラクティブ接続確立）[6]で定義されたSDP形式を使用する必要があります。
ICE is used by systems that cannot determine their own transport address as seen from the remote end, but that can provide several possible alternatives. ICE encodes the address that is most likely to be valid in an 'm' line, and the rest of addresses as a= lines after that 'm' line. This way, systems that do not support ICE simply ignore the a= lines and only use the address in the 'm' line. This achieves good backward compatibility.
ICEは、リモートエンドから見られるように独自の輸送アドレスを決定できないシステムで使用されますが、いくつかの可能な選択肢を提供できます。ICEは、「M」行で有効になる可能性が最も高いアドレスをエンコードし、その後のアドレスはその「M」行の後のA =行としてエンコードします。このようにして、氷をサポートしないシステムは、単にa = lineを無視し、「m」行のアドレスのみを使用します。これにより、良好な後方互換性が得られます。
We have chosen to group 'm' lines with different IP versions at the 'm' level (ANAT semantics) rather than at the a= level (ICE format) in order to keep the IPv6 syntax free from ICE parameters used for legacy (IPv4) NATs (Network Address Translators). This yields a syntax much closer to vanilla SDP, where IPv6 addresses are defined in their own 'm' line, rather than in parameters belonging to a different 'm' line.
Legacyに使用されるICEパラメーターをIPv6構文に自由に保つために、a =レベル（ICE形式）ではなく、「M」レベル（ANATセマンティクス）で異なるIPバージョンのグループをグループ化することを選択しました（IPv4））NAT（ネットワークアドレス翻訳者）。これにより、Vanilla SDPにはるかに近い構文が得られ、IPv6アドレスは、別の「M」ラインに属するパラメーターではなく、独自の「M」ラインで定義されます。
Additionally, ICE only allows us to provide a single primary address when the peer does not support ICE. The ANAT semantics avoid relegating certain types of addresses (e.g., IPv6 addresses) to only be a secondary alternate to another address type (e.g., IPv4 addresses).
さらに、ICEは、ピアがICEをサポートしていない場合にのみ、単一のプライマリアドレスを提供することができます。ANATセマンティクスは、特定の種類のアドレス（例：IPv6アドレス）を別のアドレスタイプ（例：IPv4アドレス）と代替の二次的なものにすることを避けます。
Furthermore, the separation between ANAT and ICE helps systems that support IPv4 and IPv6 but that do not need to support ICE (e.g., a multicast server).
さらに、ANATとICEの分離は、IPv4とIPv6をサポートするシステムに役立ちますが、ICE（たとえば、マルチキャストサーバー）をサポートする必要はありません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈され、準拠の実装の要件レベルを示します。
We define a new "semantics" attribute within the SDP grouping framework [4]: ANAT (Alternative Network Address Types).
SDPグループ化フレームワーク[4]内で新しい「セマンティクス」属性を定義します：anat（代替ネットワークアドレスタイプ）。
Media lines grouped using ANAT semantics provide alternative network addresses of different types for a single logical media stream. The entity creating a session description with an ANAT group MUST be ready to receive (or send) media over any of the grouped 'm' lines. The ANAT semantics MUST NOT be used to group media streams whose network addresses are of the same type.
ANATセマンティクスを使用してグループ化されたメディアラインは、単一の論理メディアストリームに対して異なるタイプの代替ネットワークアドレスを提供します。ANATグループを使用してセッションの説明を作成するエンティティは、グループ化された「M」行のいずれかでメディアを受信（または送信）する準備ができている必要があります。ANATセマンティクスは、ネットワークアドレスが同じタイプのメディアストリームをグループ化するために使用してはなりません。
The entity generating a session description may have an order of preference for the alternative network address types offered. The identifiers of the media streams MUST be listed in order of preference in the group line. For example, in the session description in Section 6, the 'm' line with mid=1 has a higher preference than the 'm' line with mid=2.
セッションの説明を生成するエンティティは、提供される代替ネットワークアドレスタイプを好む順序を持つ場合があります。メディアストリームの識別子は、グループラインの好みの順にリストする必要があります。たとえば、セクション6のセッションの説明では、MID = 1の「M」行は、MID = 2の「M」線よりも優先されます。
An offerer using SIP [3] to send its offer SHOULD place the sdp-anat option-tag [5] in a Require header field.
SIP [3]を使用してオファーを使用するオファーは、SDP-Anatオプションタグ[5]を必要ヘッダーフィールドに配置する必要があります。
An answerer receiving a session description that uses the ANAT semantics SHOULD use the address with the highest priority it understands and set the ports of the rest of the 'm' lines of the group to zero.
ANATセマンティクスを使用するセッションの説明を受信する回答者は、グループの残りの「M」行のポートを理解し、設定する最優先事項でアドレスを使用する必要があります。
The session description below contains an IPv4 address and an IPv6 address grouped using ANAT. The format corresponding to the mapping of ICE into SDP [6] can be used in both 'm' lines to provide additional addresses.
以下のセッションの説明には、ANATを使用してグループ化されたIPv4アドレスとIPv6アドレスが含まれています。SDP [6]への氷のマッピングに対応する形式は、両方の「M」行で使用して追加のアドレスを提供できます。
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ANAT 1 2
m=audio 25000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a= <ICE-encoded additional IPv6 addresses (and ports)>
a=mid:1
m=audio 22334 RTP/AVP 0
c=IN IP4 192.0.2.1
a= <ICE-encoded additional IPv4 addresses (and ports)>
a=mid:2
An attacker adding group lines, using the ANAT semantics, to an SDP session description could make an end-point use only one out of all the streams offered by the remote end, when the intention of the remote-end might have been to establish all the streams.
ANATセマンティクスを使用してSDPセッションの説明にグループラインを追加する攻撃者は、リモートエンドの意図がすべてを確立することであった場合に、リモートエンドが提供するすべてのストリームのうち1つだけをエンドポイント使用する可能性があります。ストリーム。
An attacker removing group lines using ANAT semantics could make an end-point establish a higher number of media streams. If the end-point sends media over all of them, the session bandwidth may increase dramatically.
ANATセマンティクスを使用してグループラインを削除する攻撃者は、エンドポイントがより多くのメディアストリームを確立する可能性があります。エンドポイントがすべてのメディアを送信する場合、セッション帯域幅は劇的に増加する可能性があります。
It is thus strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [3], S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [3]. Other applications MAY use a different form of integrity protection.
したがって、SDPセッションの説明に完全性保護を適用することを強くお勧めします。SIP [3]で掲載されたセッションの説明では、S/MIMEは、RFC 3261 [3]に記載されているように、このようなエンドツーエンドの完全性保護を提供するための自然な選択です。他のアプリケーションは、異なる形式の整合性保護を使用する場合があります。
The IANA has registered the following new 'semantics' attribute for the SDP grouping framework [4]:
IANAは、SDPグループのフレームワーク[4]の次の新しい「セマンティクス」属性を登録しています。
Semantics Token Reference
--------------------------------- ----- ---------
Alternative Network Address Types ANAT [RFC4091]
ANAT has been registered in the SDP parameters registry under Semantics for the "group" SDP Attribute.
ANATは、「グループ」SDP属性のセマンティクスの下でSDPパラメーターレジストリに登録されています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[3] 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.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[4] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[5] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, June 2005.
[5] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）の使用法の使用法（ANAT）セッション開始プロトコル（SIP）のセマンティクス」、RFC 4092、2005年6月。
[6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Work in Progress, February 2005.
[6] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：ネットワークアドレス翻訳者の方法論（NAT）マルチメディアセッション確立プロトコルのトラバーサル」、2005年2月、進行中の作業。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
EMail: jdrosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。