Network Working Group G. Camarillo
Request for Comments: 4092 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
Usage of the Session Description Protocol (SDP)
Alternative Network Address Types (ANAT) Semantics
in the Session Initiation Protocol (SIP)
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).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT.
この文書では、SIPにフレームワークをグループ化するセッション記述プロトコル（SDP）の代替ネットワークアドレスタイプ（ANAT）セマンティクスを使用する方法について説明します。特に、我々は、SDP-アナトSIPオプションタグを定義します。このSIPオプションタグはANATを使用するSDPセッション記述のみANATサポートとSIPエンティティによって処理されることが保証されます。そのようなSIPオプションタグの必要性を正当化するために、我々はANAT非対応SIPエンティティがANATでグループ化されたメディアラインを処理しようとした場合、おそらくどうなるかを説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . . 2
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3
4.1. Answerer Supports All the Network Types Offered . . . . 3
4.2. Answerer Does Not Support All the Network Types Offered. 3
4.3. OPTIONS Requests . . . . . . . . . . . . . . . . . . . . 4
5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
SIP [3] UAs (User Agents) often support different network address types. For example, a UA may have an IPv6 address and an IPv4 address. Such a UA will typically be willing to use any of its addresses to establish a media session with a remote UA. If the remote UA only supports IPv6, for instance, both UAs will use IPv6 to send and receive media.
SIP [3]のUA（ユーザエージェント）は、しばしば異なるネットワーク・アドレス・タイプをサポートします。例えば、UAは、IPv6アドレスとIPv4アドレスを有していてもよいです。そのようなUAは通常、リモートUAとのメディアセッションを確立するために、そのアドレスのいずれかを使用することをいとわないだろう。遠隔UAは、IPv6のみをサポートしている場合、例えば、両方のUAは、メディアを送受信するためにIPv6を使用します。
The Alternative Network Address Types (ANAT) semantics [7] of the SDP [2] grouping framework [5] allow UAs to offer [4] alternative addresses of different types in an SDP session description. The IPv4/IPv6 dual-stack SIP UA of our previous example would generate an offer grouping an IPv6 media line and an IPv4 media line using ANAT. Upon receipt of this offer, the answerer [4] would accept one media line and reject the other.
代替ネットワークアドレスタイプ（ANAT）[7] [5] SDP [2]グループ化フレームワークのセマンティクスは、UAがSDPセッション記述において、異なるタイプの[4]別のアドレスを提供することを可能にします。前の例のIPv4の/ IPv6のデュアルスタックSIP UAは、IPv6メディアラインとANATを使用したIPv4メディアラインをグループ化するプランを生成します。このオファーを受信すると、回答[4]つのメディア行を受け入れ、他方を拒否する。
If the recipient of an offer that uses ANAT supports the ANAT semantics, everything works as described in the ANAT specification [7]. Nevertheless, the recipient of such an offer (i.e., the answerer) may not support ANAT. In this case, different implementations of the answerer would react in different ways. This document discusses the answerer's behaviors that are most likely to be found and describes their consequences. To avoid these consequences, we define the sdp-anat SIP option-tag.
ANATを使用していますオファーの受信者がANATセマンティクスをサポートしている場合ANAT仕様で説明したように、すべてが[7]動作します。それにもかかわらず、そのようなオファー（すなわち、回答者）の受信者はANATをサポートしないかもしれません。この場合には、回答の異なる実装は、様々な方法で反応するであろう。この文書が見つかりました、その結果を説明される可能性が最も高い回答者の行動を説明します。これらの結果を回避するために、我々は、SDP-アナトSIPオプションタグを定義します。
The sdp-anat option-tag can be used to ensure that an offer using ANAT is not processed by answerers without support for ANAT. This option-tag can also be used to explicitly discover the capabilities of a UA (i.e., whether it supports ANAT).
SDP-アナトオプションタグはANATを使用してオファーがANATのためのサポートなしで回答によって処理されていないことを保証するために使用することができます。このオプションタグは、（それがANATをサポートしているかどうか、すなわち）明示的にUAの能力を発見するために使用することができます。
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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
We define the option-tag sdp-anat for use in the Require and Supported SIP [3] header fields. SIP user agents that place this option-tag in a Supported header field understand the ANAT semantics as defined in [7].
我々は、SIPを必要とし、サポートされている[3]ヘッダーフィールドで使用するためのオプションタグSDP-アナトを定義します。 [7]で定義されるようにサポートされているヘッダフィールドには、このオプションタグを配置するSIPユーザエージェントは、ANATセマンティクスを理解します。
Answerers without support for ANAT will react in different ways upon receipt of an offer using ANAT. We expect that, even under the same circumstances, different implementations will behave in different ways. In this section, we analyze these behaviors (i.e., the following subsections assume that the answerer does not support ANAT).
ANATのサポートなしの回答はANATを使用してオファーの受信時にさまざまな方法で反応します。私たちも、同じような状況の下で、異なる実装が異なる方法で動作します、と予想しています。このセクションでは、これらの行動は（すなわち、次の項では、回答がANATをサポートしていないと仮定）を分析します。
If the answerer supports all the network types in the offer, it may accept the offer and establish all the media streams in it. This behavior is not what the offerer expects because it results in too many media streams being established. If the answerer starts sending media over all of them, the result may be a high bandwidth usage.
回答が提供中のすべてのネットワーク・タイプをサポートしている場合、それは申し出を受け入れ、その中のすべてのメディアストリームを確立することができます。この動作は、それがあまりにも多くのメディアストリームが確立され、その結果ので、オファー側が期待するものではありません。回答は、それらのすべてを介してメディアの送信を開始した場合、その結果は、高帯域幅の使用状況かもしれません。
The answerer may also reject the offer, because although it supports all the network types in it, the answerer may not support them simultaneously. The error response sent by the answerer will most likely not be explicit enough about the situation. So, the offerer will not understand what went wrong.
それはその中のすべてのネットワーク・タイプをサポートしていますが、回答はそれらを同時にサポートしていない可能性があるため、回答も、申し出を拒否することができます。回答によって送信されたエラー応答が最も可能性の高い状況について十分に明示されません。だから、オファー側は、何が悪かったのか理解できないだろう。
In the previous scenarios, the sdp-anat option-tag would avoid the establishment of too many media streams and would allow the answerer to explicitly inform the offerer that the answerer did not support ANAT.
前のシナリオでは、SDP-アナトオプションタグは、あまりにも多くのメディアストリームの確立を避けるだろうと回答が明示的に回答がANATをサポートしていませんでしたオファー側に通知することが可能になります。
If the answerer does not support all the network types in the offer, it may only establish the media streams whose address types it understands and reject the rest. This would be an acceptable behavior from the offerer's point of view.
回答が提供中のすべてのネットワーク・タイプをサポートしていない場合は、それだけでそのアドレスの種類、それは理解し、残りを拒否するメディアストリームを確立することができます。これは、ビューのオファー側の視点から許容動作になります。
On the other hand, the answerer may also reject the offer because it contains unknown address types. The error response sent by the answerer will most likely not be explicit enough about the situation. So, the offerer will not understand what went wrong.
それは未知のアドレスの種類が含まれているため、一方で、回答も申し出を拒否することができます。回答によって送信されたエラー応答が最も可能性の高い状況について十分に明示されません。だから、オファー側は、何が悪かったのか理解できないだろう。
In the previous scenario, the sdp-anat option-tag would allow the answerer to explicitly inform the offerer that the answerer did not support ANAT.
前のシナリオでは、SDP-アナトオプションタグは、回答が明示的に回答がANATをサポートしていませんでしたオファー側に通知することが可能になります。
Although RFC 3388 [5] provides servers with a means to indicate support for ANAT in an SDP description, many servers do not include an SDP description in their responses to OPTIONS requests. The sdp-anat option-tag makes it possible to discover if any server supports ANAT, since they would include this option-tag in a Supported header field in their responses.
RFC 3388 [5] SDP記述でANATのサポートを示すための手段でサーバを提供していますが、多くのサーバは、OPTIONS要求への応答のSDP記述が含まれていません。 SDP-アナトオプションタグは、任意のサーバがANATをサポートしている場合、彼らは彼らの応答にSupportedヘッダーフィールドにこのオプションタグが含まれることから、発見することが可能となります。
As discussed in the previous section, the use of the sdp-anat option-tag makes SIP messages more explicit about ANAT support. So, SIP entities generating an offer that uses the ANAT semantics SHOULD place the sdp-anat option-tag in a Require header field. SIP entities that support the ANAT semantics MUST understand the sdp-anat option-tag.
前のセクションで説明したように、SDP-アナトオプションタグの使用はANATサポートについてSIPメッセージがより明確になります。だから、ANATセマンティクスを使用するプランを生成するSIPエンティティはRequireヘッダーフィールドでSDP-アナトオプションタグを配置する必要があります。 ANATセマンティクスをサポートするSIPエンティティは、SDP-アナトオプションタグを理解する必要があります。
An attacker may attempt to add the sdp-anat option tag to the Require header field of a message to perform a DoS attack. If the UAS does not support ANAT, it will return an error response instead of processing the message.
攻撃者は、DoS攻撃を実行するために、メッセージの要求ヘッダーフィールドにSDP-アナトオプションタグを追加することを試みることができます。 UASがANATをサポートしていない場合、それはメッセージを処理するのではなく、エラー応答を返します。
An attacker may attempt to remove the sdp-anat option-tag from the Require header field of a message. This may result in the establishment of too many media streams.
攻撃者は、メッセージの要求ヘッダフィールドからSDP-アナトオプションタグを除去しようと試みることができます。これは、あまりにも多くのメディアストリームの確立をもたらすことができます。
To avoid the previous attacks, integrity protection of the Require header field is RECOMMENDED. The natural choice to integrity protect header fields in SIP is S/MIME [6].
以前の攻撃を避けるために、Requireヘッダーフィールドの完全性保護を推奨します。完全性の自然な選択は、SIPのヘッダフィールドを保護するS / MIMEである[6]。
This document defines a SIP option-tag (sdp-anat) in Section 3. It has been registered by the IANA in the SIP parameter registry.
この文書では、それは、SIPパラメータのレジストリにIANAによって登録された第3のSIPオプションタグ（SDP-アナト）を定義します。
SIP user agents that place the sdp-anat option-tag in a Supported header field understand the ANAT semantics.
SupportedヘッダーフィールドでSDP-アナトオプションタグを配置SIPユーザエージェントは、ANATの意味を理解しています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.および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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"、2002年6月。
[5] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[5]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月。
[6] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[6]ピーターソン、J.、 "セッション開始プロトコル（SIP）のためのS / MIMEのAdvanced Encryption Standard（AES）の要件"、RFC 3853、2004年7月。
[7] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[7]キャマリロ、G.およびJ.ローゼンバーグ、RFC 4091、2005年6月 "セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス"。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
EMail: jdrosen@cisco.com
メールアドレス：jdrosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。