RFC 4092 - Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4092
タイトル : RFC 4092 - セッション説明プロトコル（SDP）オルタナティブネットワークアドレスタイプ（ANAT）セマンティクスのセッション開始プロトコル（SIP）の使用
翻訳編集 : 自動生成

[要約] RFC 4092は、SIPでSDPの代替ネットワークアドレスタイプ（ANAT）セマンティクスを使用する方法について説明しています。このRFCの目的は、SIPセッションのネットワークアドレスタイプの選択肢を拡張し、異なるネットワーク環境でのセッションの確立をサポートすることです。

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)

セッション説明プロトコル（SDP）オルタナティブネットワークアドレスタイプ（ANAT）セマンティクスのセッション開始プロトコル（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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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-Anat SIPオプションタグを定義します。このSIPオプションタグにより、ANATを使用するSDPセッションの説明は、ANATサポートを備えたSIPエンティティのみによって処理されることが保証されます。このようなSIPオプションタグの必要性を正当化するために、Anat-Unaware 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

1. Introduction

1. はじめに

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] UAS（ユーザーエージェント）は、多くの場合、さまざまなネットワークアドレスタイプをサポートしています。たとえば、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.

SDP [2]グループ化フレームワーク[5]の代替ネットワークアドレスタイプ（ANAT）セマンティクス[7]により、UASはSDPセッションの説明でさまざまなタイプの代替アドレスを提供できます。前の例のIPv4/IPv6デュアルスタックSIP UAは、ANATを使用してIPv6メディアラインとIPv4メディアラインをグループ化するオファーを生成します。このオファーを受け取ると、回答者[4]は1つのメディアラインを受け入れ、もう1つのメディアラインを拒否します。

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]に記載されているとおりに機能します。それにもかかわらず、そのような申し出（つまり、回答者）の受信者はアナットをサポートしない場合があります。この場合、回答者の異なる実装はさまざまな方法で反応します。このドキュメントでは、発見される可能性が最も高い回答者の行動について説明し、その結果を説明しています。これらの結果を回避するために、SDP-Anat 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の機能を明示的に発見することもできます（つまり、ANATをサポートするかどうか）。

2. Terminology

2. 用語

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]に記載されているように解釈され、準拠の実装の要件レベルを示します。

3. The sdp-anat Option-Tag

3. SDP-Anatオプションタグ

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-Anatを定義します。[7]で定義されているように、このオプションタグをサポートされているヘッダーフィールドに配置するSIPユーザーエージェントは、ANATセマンティクスを理解しています。

4. Backward Compatibility

4. 後方互換性

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をサポートしていないと想定しています）。

4.1. Answerer Supports All the Network Types Offered

4.1. 回答者は、提供されるすべてのネットワークタイプをサポートします

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オプションタグは、あまりにも多くのメディアストリームの確立を回避し、応答者に応募者にANATをサポートしていないことを明示的に通知することができます。

4.2. Answerer Does Not Support All the Network Types Offered

4.2. 回答者は、提供されるすべてのネットワークタイプをサポートしていません

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オプションタグにより、回答者は応募者にAnatをサポートしていないことを提供者に明示的に通知することができます。

4.3. OPTIONS Requests

4.3. オプションリクエスト

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のサポートを示す手段をサーバーに提供していますが、多くのサーバーにはオプションリクエストへの応答にSDP説明が含まれていません。SDP-Anatオプションタグにより、サーバーがANATをサポートするかどうかを発見することができます。これは、サポートされているヘッダーフィールドにこのオプションタグをレスポンスに含めるからです。

5. Option-Tag Usage

5. オプションタグの使用

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サポートについてより明確になります。したがって、ANATセマンティクスを使用するオファーを生成するSIPエンティティは、SDP-Anatオプションタグを必要ヘッダーフィールドに配置する必要があります。ANATセマンティクスをサポートするSIPエンティティは、SDP-Anatオプションタグを理解する必要があります。

6. Security Considerations

6. セキュリティに関する考慮事項

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-Anatオプションタグを追加しようとする場合があります。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-Anatオプションタグを削除しようとする場合があります。これにより、メディアストリームが多すぎる可能性があります。

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].

以前の攻撃を回避するには、要求ヘッダーフィールドの整合性保護が推奨されます。SIPのヘッダーフィールドを整合性保護する自然な選択は、S/MIMEです[6]。

7. IANA Considerations

7. IANAの考慮事項

This document defines a SIP option-tag (sdp-anat) in Section 3. It has been registered by the IANA in the SIP parameter registry.

このドキュメントは、セクション3のSIPオプションタグ（SDP-Anat）を定義しています。SIPパラメーターレジストリにIANAによって登録されています。

SIP user agents that place the sdp-anat option-tag in a Supported header field understand the ANAT semantics.

サポートされているヘッダーフィールドにSDP-Anatオプションタグを配置するSIPユーザーエージェントは、アナットセマンティクスを理解しています。

8. Normative References

8. 引用文献

[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[4] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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] Camarillo、G.、Eriksson、G.、Holler、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] Peterson、J。、「S/MIME Advanced暗号化標準（AES）セッション開始プロトコル（SIP）の要件」、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] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。

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

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。