RFC4092 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 4092                                      Ericsson
Category: Standards Track                                   J. Rosenberg
                                                           Cisco Systems
                                                               June 2005

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 4092年のエリクソンカテゴリ: 標準化過程J.ローゼンバーグシスコシステムズ2005年6月

            Usage of the Session Description Protocol (SDP)
          Alternative Network Address Types (ANAT) Semantics
                in the Session Initiation Protocol (SIP)

セッションの記述のプロトコルの(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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のSession記述プロトコル(SDP)組分け枠組みのAlternative Network Address Types(ANAT)意味論を使用する方法を説明します。 特に、私たちはsdp-anat 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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 sdp-anat Option-タグ.2 4。 後方の互換性. . . . . . . . . . . . . . . . . . . . 3 4.1。 Answererは.34.2に提供されたすべてのネットワークタイプを支持します。 Answererはタイプが提供したすべてのネットワークをサポートしません。 3 4.3. オプションは.4 5を要求します。 オプションタグ用法. . . . . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 4 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 4 8。 引用規格. . . . . . . . . . . . . . . . . . . . . 5

Camarillo & Rosenberg       Standards Track                     [Page 1]

RFC 4092                   ANAT Usage in SDP                   June 2005

キャマリロとローゼンバーグStandardsは2005年6月にSDPのRFC4092ANAT用法を追跡します[1ページ]。

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を支持するだけであると、両方のUAsは、メディアを送って、受け取るのに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.

枠組み[5]を分類するSDP[2]のAlternative Network Address Types(ANAT)意味論[7]で、UAsはSDPセッション記述で[4] 異なったタイプの代替アドレスを提供できます。 私たちの前の例のIPv4/IPv6デュアルスタックSIP UAはANATを使用することでIPv6メディア線とIPv4メディア線を分類する申し出を発生させるでしょう。 この申し出を受け取り次第、answerer[4]は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]で説明されるように働いています。 それにもかかわらず、そのような申し出(すなわち、answerer)の受取人はANATを支持しないかもしれません。 この場合、answererの異なった実現は異なった方法で反応するでしょう。 このドキュメントは、answererの最も見つけられそうな振舞いについて議論して、それらの結果について説明します。 これらの結果を避けるために、私たちは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).

ANATを使用する申し出がANATのサポートなしでanswerersによって処理されないのを保証するのにsdp-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.

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実現のために要件レベルを示すべきであるかをさせましょう。

3.  The sdp-anat Option-Tag

3. sdp-anat Option-タグ

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

私たちはRequireとSupported SIP[3]ヘッダーフィールドにおける使用のためにオプションタグsdp-anatを定義します。 このオプションタグをSupportedヘッダーフィールドに置くSIPユーザエージェントが[7]で定義されるようにANAT意味論を理解しています。

Camarillo & Rosenberg       Standards Track                     [Page 2]

RFC 4092                   ANAT Usage in SDP                   June 2005

キャマリロとローゼンバーグStandardsは2005年6月にSDPのRFC4092ANAT用法を追跡します[2ページ]。

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のサポートのないAnswerersは、申し出を受け取り次第ANATを使用することで異なった方法で反応するでしょう。 私たちは、異なった実現が同じ状況でさえ異なった方法で振る舞うと予想します。 このセクションでは、私たちはこれらの振舞いを分析します(すなわち、以下の小区分は、answererがANATを支持しないと仮定します)。

4.1.  Answerer Supports All the Network Types Offered

4.1. Answererはタイプが提供したすべてのネットワークをサポートします。

   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.

answererが申し出ですべてのネットワークタイプを支持するなら、それは、それに申し出を受け入れて、すべてのメディアの流れを確立するかもしれません。 確立されるあまりに多くのメディアの流れをもたらすので、この振舞いは申出人が予想することではありません。 answererがそれらのすべて上にメディアを送り始めるなら、結果は高帯域用法であるかもしれません。

   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.

また、answererは申し出を拒絶するかもしれません、それのすべてのネットワークタイプを支持しますが、answererが同時に彼らを支持しないかもしれないので。 answererによって送られた誤り応答はたぶん状況に関して十分明白でなくなるでしょう。 それで、申出人は、何が支障をきたしたかを理解しないでしょう。

   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オプションタグは、あまりに多くのメディアの流れの設立を避けて、answererが、answererがANATを支持しなかったことを明らかに申出人に知らせるのを許容するでしょう。

4.2.  Answerer Does Not Support All the Network Types Offered

4.2. Answererはタイプが提供したすべてのネットワークをサポートしません。

   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.

answererが申し出ですべてのネットワークタイプを支持するというわけではないなら、それは、それがアドレスタイプを理解しているメディアの流れを確立するだけであり、残りを拒絶するかもしれません。 これは申出人の観点からの是認される行動でしょう。

   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.

他方では、また、未知のアドレスタイプを含んでいるので、answererは申し出を拒絶するかもしれません。 answererによって送られた誤り応答はたぶん状況に関して十分明白でなくなるでしょう。 それで、申出人は、何が支障をきたしたかを理解しないでしょう。

   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オプションタグで、answererは、answererがANATを支持しなかったことを明らかに申出人に知らせることができるでしょう。

Camarillo & Rosenberg       Standards Track                     [Page 3]

RFC 4092                   ANAT Usage in SDP                   June 2005

キャマリロとローゼンバーグStandardsは2005年6月にSDPのRFC4092ANAT用法を追跡します[3ページ]。

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.

RFC3388[5]はSDP記述でANATのサポートを示す手段をサーバに提供しますが、多くのサーバはOPTIONS要求への彼らの応答におけるSDP記述を含んでいません。 sdp-anatオプションタグで何かサーバがANATを支持するかどうか発見するのが可能になります、彼らはSupportedヘッダーフィールドに応答でこのオプションタグを含んでいるでしょう、したがって。

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意味論SHOULDを使用する申し出を発生させるSIP実体がsdp-anatオプションタグをRequireヘッダーフィールドに置きます。 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攻撃を実行するメッセージのRequireヘッダーフィールドに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.

攻撃者は、メッセージのRequireヘッダーフィールドから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].

前の攻撃を避けるために、Requireヘッダーフィールドの保全保護はRECOMMENDEDです。 保全への自然な選択はヘッダーフィールドを保護します。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オプションタグをSupportedヘッダーフィールドに置くSIPユーザエージェントがANAT意味論を理解しています。

Camarillo & Rosenberg       Standards Track                     [Page 4]

RFC 4092                   ANAT Usage in SDP                   June 2005

キャマリロとローゼンバーグStandardsは2005年6月にSDPのRFC4092ANAT用法を追跡します[4ページ]。

8.  Normative References

8. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、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)で立ち並んでいます」、RFC3388、2002年12月。

   [6]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
        Requirement for the Session Initiation Protocol (SIP)", RFC
        3853, July 2004.

[6] ピーターソン、J.、「セッション開始プロトコル(一口)のためのS/MIMEエー・イー・エス(AES)要件」、RFC3853、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.ローゼンバーグ、「代替のネットワーク・アドレスはセッション記述プロトコル(SDP)組分け枠組みのために(ANAT)意味論をタイプします」、RFC4091、2005年6月。

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)

   EMail: jdrosen@cisco.com

メール: jdrosen@cisco.com

Camarillo & Rosenberg       Standards Track                     [Page 5]

RFC 4092                   ANAT Usage in SDP                   June 2005

キャマリロとローゼンバーグStandardsは2005年6月にSDPのRFC4092ANAT用法を追跡します[5ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

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

Camarillo & Rosenberg       Standards Track                     [Page 6]

キャマリロとローゼンバーグ標準化過程[6ページ]