RFC3605 日本語訳

Network Working Group                                         C. Huitema
Request for Comments: 3605                                     Microsoft
Category: Standards Track                                   October 2003

Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3605年のマイクロソフトカテゴリ: 標準化過程2003年10月

            Real Time Control Protocol (RTCP) attribute in
                  Session Description Protocol (SDP)

(RTCP)がSession記述プロトコルで結果と考える本当のTime Controlプロトコル(SDP)

Status of this Memo

この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 (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   The Session Description Protocol (SDP) is used to describe the
   parameters of media streams used in multimedia sessions.  When a
   session requires multiple ports, SDP assumes that these ports have
   consecutive numbers.  However, when the session crosses a network
   address translation device that also uses port mapping, the ordering
   of ports can be destroyed by the translation.  To handle this, we
   propose an extension attribute to SDP.

Session記述プロトコル(SDP)は、マルチメディアセッションのときに使用されたメディアストリームのパラメタについて説明するのに使用されます。 セッションが複数のポートを必要とするとき、SDPは、これらのポートには一連番号があると仮定します。 しかしながら、セッションがまた、ポートマッピングを使用するネットワーク・アドレス翻訳デバイスに交差するとき、翻訳でポートの注文を破壊できます。 これを扱うために、私たちは拡大属性をSDPに提案します。

1.  Introduction

1. 序論

   The session invitation protocol (SIP, [RFC3261]) is often used to
   establish multi-media sessions on the Internet.  There are often
   cases today in which one or both ends of the connection are hidden
   behind a network address translation device [RFC2766].  In this case,
   the SDP text must document the IP addresses and UDP ports as they
   appear on the "public Internet" side of the NAT.  In this memo, we
   will suppose that the host located behind a NAT has a way to obtain
   these numbers.  A possible way to learn these numbers is briefly
   outlined in section 3, however, just learning the numbers is not
   enough.

セッション招待プロトコル(SIP、[RFC3261])は、インターネットのマルチメディアセッションを証明するのにしばしば使用されます。 今日の接続の1か両端がネットワーク・アドレス翻訳デバイス[RFC2766]の後ろに隠される場合がしばしばあります。 この場合、SDPテキストは「公共のインターネット」というNATの側に載っているようにIPアドレスとUDPポートを記録しなければなりません。 このメモでは、私たちは、NATの後ろに位置するホストがこれらの数を得る方法を持っていると思うつもりです。 これらの数を学ぶ可能な方法はセクション3で簡潔に概説されていて、しかしながら、ただ数を学ぶのは十分ではありません。

   The SIP messages use the encoding defined in SDP [RFC2327] to
   describe the IP addresses and TCP or UDP ports used by the various
   media.  Audio and video are typically sent using RTP [RFC3550], which
   requires two UDP ports, one for the media and one for the control
   protocol (RTCP).  SDP carries only one port number per media, and

SIPメッセージはポートが様々なメディアで使用したIPのアドレスとTCPかUDPについて説明するためにSDP[RFC2327]で定義されたコード化を使用します。 オーディオとビデオにRTP[RFC3550]を通常使用させます。(RTPは2つのUDPポート、メディアのためのもの、および制御プロトコル(RTCP)のためのものを必要とします)。 そしてSDPが1メディアあたり1つのポートナンバーだけを運ぶ。

Huitema                     Standards Track                     [Page 1]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[1ページ]RFC3605

   states that "other ports used by the media application (such as the
   RTCP port) should be derived algorithmically from the base media
   port."  RTCP port numbers were necessarily derived from the base
   media port in older versions of RTP (such as [RFC1889]), but now that
   this restriction has been lifted, there is a need to specify RTCP
   ports explicitly in SDP.  Note, however, that implementations of RTP
   adhering to the earlier [RFC1889] specification may not be able to
   make use of the SDP attributes specified in this document.

「ベースメディア港からメディアアプリケーション(RTCPポートなどの)で使用される他のポートをalgorithmicallyに得るべきです。」と述べます。 必ずRTP([RFC1889]などの)の旧式のバージョンでベースメディア港からRTCPポートナンバーを得ましたが、この制限が提案されたので、SDPで明らかにRTCPポートを指定する必要があります。 しかしながら、以前の[RFC1889]仕様を固く守るRTPの実装が本書では指定されたSDP属性を利用できないかもしれないことに注意してください。

   When the NAT device performs port mapping, there is no guarantee that
   the mappings of two separate ports reflects the sequencing and the
   parity of the original port numbers; in fact, when the NAT manages a
   pool of IP addresses, it is even possible that the RTP and the RTCP
   ports may be mapped to different addresses.  In order to successfully
   establish connections despite the misordering of the port numbers and
   the possible parity switches caused by the NAT, we propose to use a
   specific SDP attribute to document the RTCP port and optionally the
   RTCP address.

NATデバイスがポートマッピングを実行するとき、2つの別々のポートに関するマッピングが元のポートナンバーの配列と同等を反映するという保証が全くありません。 事実上、NATがIPアドレスのプールを管理するとき、RTPとRTCPポートが異なったアドレスに写像されるのは、可能でさえあります。 私たちは、NATによって引き起こされたポートナンバーと可能なパリティスイッチのmisorderingにもかかわらず、首尾よく関係を樹立するために任意にRTCPポートを記録するのに特定のSDP属性を使用するよう提案します。RTCPアドレス。

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Description of the Solution

2. ソリューションの記述

   The main part of our solution is the declaration of an SDP attribute
   for documenting the port used by RTCP.

私たちのソリューションの主部はRTCPによって使用されたポートを記録するためのSDP属性の宣言です。

2.1.  The RTCP Attribute

2.1. RTCP属性

   The RTCP attribute is used to document the RTCP port used for media
   stream, when that port is not the next higher (odd) port number
   following the RTP port described in the media line.  The RTCP
   attribute is a "value" attribute, and follows the general syntax
   specified page 18 of [RFC2327]: "a=<attribute>:<value>".  For the
   RTCP attribute:

RTCP属性はメディアストリームに使用されるRTCPポートを記録するのに使用されます、そのポートがメディア系列で説明されたRTPポートに続く次の、より高い(変な)ポートナンバーでないときに。 RTCP属性は、「値」属性であり、18一般的な構文指定された[RFC2327]ページに従います: 「=<属性>: <値の>。」 RTCPに関しては、以下を結果と考えてください。

   *  the name is the ascii string "rtcp" (lower case),

* 名前はASCIIストリング"rtcp"(小文字)です。

   *  the value is the RTCP port number and optional address.

* 値は、RTCPポートナンバーと任意のアドレスです。

   The formal description of the attribute is defined by the following
   ABNF [RFC2234] syntax:

属性の形式的記述は以下のABNF[RFC2234]構文で定義されます:

   rtcp-attribute =  "a=rtcp:" port  [nettype space addrtype space
                         connection-address] CRLF

rtcp-属性=、「a=rtcp:」 ポート[nettype宇宙addrtype宇宙接続アドレス]CRLF

Huitema                     Standards Track                     [Page 2]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[2ページ]RFC3605

   In this description, the "port", "nettype", "addrtype" and
   "connection-address" tokens are defined as specified in "Appendix A:
   SDP Grammar" of [RFC2327].

この記述では、「ポート」、"nettype"、"addrtype"、およびトークンが定義される「接続アドレス」は「付録A:」で指定しました。 [RFC2327]の「SDP文法。」

   Example encodings could be:

例のencodingsは以下の通りであるかもしれません。

    m=audio 49170 RTP/AVP 0
    a=rtcp:53020

オーディオの49170RTP/AVP0m=a=rtcp: 53020

    m=audio 49170 RTP/AVP 0
    a=rtcp:53020 IN IP4 126.16.64.4

オーディオの49170RTP/AVP0m=a=rtcp: 53020IN IP4 126.16.64、.4

    m=audio 49170 RTP/AVP 0
    a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD

m=オーディオの49170RTP/AVP0a=rtcp: 53020IN IP6 2001:2345:6789: ABCD: EF01: 2345:6789:ABCD

   The RTCP attribute MAY be used as a media level attribute; it MUST
   NOT be used as a session level attribute.  Though the examples below
   relate to a method that will return only unicast addresses, both
   unicast and multicast values are valid.

メディアが属性を平らにするとき、RTCP属性は使用されているかもしれません。 セッションレベル属性としてそれを使用してはいけません。 以下の例はユニキャストアドレスだけを返すメソッドに関連しますが、ユニキャストとマルチキャスト値の両方が有効です。

3.  Discussion of the Solution

3. ソリューションの議論

   The implementation of the solution is fairly straightforward.  The
   questions that have been most often asked regarding this solution are
   whether this is useful, i.e., whether a host can actually discover
   port numbers in an unmodified NAT, whether it is sufficient, i.e.,
   whether or not there is a need to document more than one ancillary
   port per media type, and whether why should not change the media
   definition instead of adding a new attribute.

ソリューションの実装はかなり簡単です。 このソリューションに関してたいてい行われた質問はこれが役に立つかどうかということです、すなわち、ホストが実際に変更されていないNATにおけるポートナンバーを発見できるか否かに関係なく、それが十分であるか否かに関係なく、すなわち、メディアタイプあたり1つ以上の付属のポートを記録する必要があって、なぜが新しい属性を加えることの代わりにメディア定義を変えるべきでないかか否かに関係なく。

3.1.  How do we Discover Port Numbers?

3.1. どのようにがするか、私たち、Discover Port民数記?

   The proposed solution is only useful if the host can discover the
   "translated port numbers", i.e., the value of the ports as they
   appear on the "external side" of the NAT.  One possibility is to ask
   the cooperation of a well connected third party that will act as a
   server according to STUN [RFC3489].  We thus obtain a four step
   process:

ホストが「翻訳されたポートナンバー」を発見できる場合にだけ、提案されたソリューションは役に立ちます、すなわち、ポートの値。NATの「外部側」に現れるように。 1つの可能性はSTUN[RFC3489]によると、サーバとして務めるよく接続された第三者の協力を尋ねることです。 その結果、私たちは4ステッププロセスを得ます:

   1 - The host allocates two UDP ports numbers for an RTP/RTCP pair,

1--ホストは1RTP/RTCP組の数を2つのUDPポートに割り当てます。

   2 - The host sends a UDP message from each port to the STUN server,

2--ホストは各ポートからSTUNサーバにUDPメッセージを送ります。

   3 - The STUN server reads the source address and port of the packet,
       and copies them in the text of a reply,

3--STUNサーバは、パケットのソースアドレスとポートを読んで、回答のテキストにそれらをコピーします。

Huitema                     Standards Track                     [Page 3]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[3ページ]RFC3605

   4 - The host parses the reply according to the STUN protocol and
       learns the external address and port corresponding to each of the
       two UDP ports.

4--ホストは、STUNプロトコルによって回答を分析して、それぞれの2つのUDPポートに対応する外部アドレスとポートを学びます。

   This algorithm supposes that the NAT will use the same translation
   for packets sent to the third party and to the "SDP peer" with which
   the host wants to establish a connection.  There is no guarantee that
   all NAT boxes deployed on the Internet have this characteristic.
   Implementers are referred to the STUN specification [RFC3489] for an
   extensive discussion of the various types of NAT.

このアルゴリズムは、NATが第三者と、そして、ホストと取引関係を築きたい「SDP同輩」に送られたパケットに同じ翻訳を使用すると思います。 インターネットで配布されたすべてのNAT箱がこの特性を持っているという保証が全くありません。 Implementersは様々なタイプのNATの大規模な議論のためのSTUN仕様[RFC3489]を参照されます。

3.2.  Do we need to Support Multiple Ports?

3.2. 私たちがSupport Multiple Portsに必要ですか?

   Most media streams are transmitted using a single pair of RTP and
   RTCP ports.  It is possible, however, to transmit a single media over
   several RTP flows, for example using hierarchical encoding.  In this
   case, SDP will encode the port number used by RTP on the first flow,
   and the number of flows, as in:

ほとんどのメディア小川が、1組のRTPとRTCPポートを使用することで伝えられます。 しかしながら、例えば、階層符号化を使用して、数回のRTP流れの上にただ一つのメディアを伝えるのは可能です。 この場合、SDPは最初の流れ、および流れの数でRTPによって使用されたポートナンバーをコード化するでしょう、以下のように

      m=video 49170/2 RTP/AVP 31

mはビデオ49170/2RTP/AVP31と等しいです。

   In this example, the media is sent over 2 consecutive pairs of ports,
   corresponding respectively to RTP for the first flow (even number,
   49170), RTCP for the first flow (odd number, 49171), RTP for the
   second flow (even number, 49172), and RTCP for the second flow (odd
   number, 49173).

この例、メディアには、ポートの移動している連続した2組があります、それぞれ最初の流れ(偶数、49170)のためのRTP、最初の流れ(奇数、49171)のためのRTCP、2番目の流れ(偶数、49172)のためのRTP、および2番目の流れ(奇数、49173)のためのRTCPに対応している。

   In theory, it would be possible to modify SDP and document the many
   ports corresponding to the separate encoding layers.  However,
   layered encoding is not much used in practice, and when used is
   mostly used in conjunction with multicast transmission.  The
   translation issues documented in this memo apply uniquely to unicast
   transmission, and thus there is no short term need for the support of
   multiple port descriptions.  It is more convenient and more robust to
   focus on the simple case in which a media is sent over exactly one
   RTP/RTCP stream.

理論上、SDPを変更して、別々のコード化層に対応する多くのポートを記録するのは可能でしょう。 しかしながら、層にされたコード化は実際にはあまり使用されません、そして、使用されるいつがマルチキャスト送信に関連してほとんど使用されるか。 このメモに記録された翻訳問題は唯一ユニキャスト送信に適用されます、そして、その結果、複数のポート記述のサポートの短期間必要は全くありません。 メディアがどれであるかでまさに1つのRTP/RTCPストリームの上に送られた簡単なケースに焦点を合わせるのは、より便利であって、より強健です。

3.3.  Why not Expand the Media Definition?

3.3. なぜメディア定義を広げませんか?

   The RTP ports are documented in the media description line, and it
   would seem convenient to document the RTCP port at the same place,
   rather than create an RTCP attribute.  We considered this design
   alternative and rejected it for two reasons: adding an extra port
   number and an option address in the media description would be
   awkward, and more importantly it would create problems with existing
   applications, which would have to reject the entire media description
   if they did not understand the extension.  On the contrary, adding an
   attribute has a well defined failure mode: implementations that don't

RTPポートはメディア記述系列に記録されます、そして、RTCP属性を作成するより同じ場所にむしろRTCPポートを記録するのは便利に思えるでしょう。 私たちは、このデザイン代替手段を考えて、2つの理由でそれを拒絶しました: 付加的なポートナンバーとメディア記述におけるオプションアドレスを加えるのは無器用でしょう、そして、より重要に、それは既存のアプリケーションに関する問題を生じさせるでしょう。(彼らが拡大を理解していないなら、アプリケーションは全体のメディア記述を拒絶しなければならないでしょうに)。 これに反して、属性を加えるのにおいて、よく定義された故障モードがあります: そうしない実装

Huitema                     Standards Track                     [Page 4]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[4ページ]RFC3605

   understand the "a=rtcp" attribute will simply ignore it; they will
   fail to send RTCP packets to the specified address, but they will at
   least be able to receive the media in the RTP packets.

"a=rtcp"属性が単にそれを無視するのを理解してください。 指定されたアドレスへのパケットをRTCPに送らないでしょうが、彼らはRTPパケットにメディアを少なくとも受け取ることができるでしょう。

4.  UNSAF Considerations

4. UNSAF問題

   The RTCP attribute in SDP is used to enable establishment of RTP/RTCP
   flows through NAT.  This mechanism can be used in conjunction with an
   address discovery mechanism such as STUN [RFC3489].  STUN is a short
   term fix to the NAT traversal problem, which requires thus
   consideration of the general issues linked to "Unilateral self-
   address fixing" [RFC3424].

SDPのRTCP属性は、NATを通したRTP/RTCP流れの設立を可能にするのに使用されます。 STUN[RFC3489]などのアドレス発見メカニズムに関連してこのメカニズムを使用できます。 STUNはNAT縦断問題への短期間フィックスです。(その結果、それは、「一方的な自己アドレス修理[RFC3424]」にリンクされた一般答弁の考慮を必要とします)。

   The RTCP attribute addresses a very specific problem, the
   documentation of port numbers as they appear after address
   translation by a port-mapping NAT.  The RTCP attribute SHOULD NOT be
   used for other applications.

RTCP属性はアドレス変換の後にポートを写像するNATで現れるように非常に特定の問題、ポートナンバーのドキュメンテーションを扱います。 RTCPはSHOULD NOTを結果と考えます。他のアプリケーションのために、使用されます。

   We expect that, with time, one of two exit strategies can be
   developed.  The IETF may develop an explicit "middlebox control"
   protocol that will enable applications to obtain a pair of port
   numbers appropriate for RTP and RTCP.  Another possibility is the
   deployment of IPv6, which will enable use of "end to end" addressing
   and guarantee that the two hosts will be able to use appropriate
   ports.  In both cases, there will be no need for documenting a "non
   standard" RTCP port with the RTCP attribute.

私たちは、時間で2つの撤退戦略の1つを開発できると予想します。 IETFはアプリケーションが1組のRTPに、適切なポートナンバーとRTCPを入手するのを可能にする明白な「middleboxコントロール」プロトコルを開発するかもしれません。 別の可能性はIPv6の展開です。(IPv6は、「終わらせる終わり」アドレシングの使用を可能にして、2人のホストが適切なポートを使用できるのを保証するでしょう)。 どちらの場合も、RTCP属性がある「非標準」のRTCPポートを記録する必要は全くないでしょう。

5.  Security Considerations

5. セキュリティ問題

   This SDP extension is not believed to introduce any significant
   security risk to multi-media applications.  One could conceive that a
   malevolent third party would use the extension to redirect the RTCP
   fraction of an RTP exchange, but this requires intercepting and
   rewriting the signaling packet carrying the SDP text; if an
   interceptor can do that, many more attacks are available, including a
   wholesale change of the addresses and port numbers at which the media
   will be sent.

このSDP拡張子がどんな重要なセキュリティリスクもマルチメディアアプリケーションに紹介すると信じられていません。 1つは、意地の悪い第三者がRTP交換のRTCP部分を向け直すのに拡張子を使用すると想像するかもしれませんが、これはSDPテキストを運びながらシグナリングパケットを妨害して、書き直すのを必要とします。 迎撃戦闘機がそれができるなら、ずっと多くの攻撃が利用可能です、メディアが送られるアドレスとポートナンバーの大異動を含んでいて。

   In order to avoid attacks of this sort, when SDP is used in a
   signaling packet where it is of the form application/sdp, end-to-end
   integrity using S/MIME [RFC3369] is the technical method to be
   implemented and applied.  This is compatible with SIP [RFC3261].

SDPがそれがフォームアプリケーション/sdpのものであるところでシグナリングパケットで使用されるとき、この種類の攻撃を避けて、終わりから終わりへのS/MIME[RFC3369]を使用する保全は実装している、適用されるべき技術的なメソッドです。 これはSIP[RFC3261]と互換性があります。

6.  IANA Considerations

6. IANA問題

   This document defines a new SDP parameter, the attribute field
   "rtcp", which per [RFC2327] has been registered by IANA.  This
   attribute field is designed for use at media level only.

このドキュメントは新しいSDPパラメタ、[RFC2327]単位でIANAによって登録された属性分野"rtcp"を定義します。 この属性分野は使用のためにメディアレベルだけで設計されています。

Huitema                     Standards Track                     [Page 5]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[5ページ]RFC3605

7.  Intellectual Property Statement

7. 知的所有権声明

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.

IETFは正当性、実装に関係するか、または本書では説明された他の技術を使用すると主張されるかもしれないどんな知的所有権や他の権利の範囲またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

8.  Acknowledgements

8. 承認

   The original idea for using the "rtcp" attribute was developed by Ann
   Demirtjis.  The document was reviewed by the MMUSIC and AVT working
   groups of the IETF.

"rtcp"属性を使用するための着想はアンDemirtjisによって開発されました。 ドキュメントはIETFのMMUSICとAVTワーキンググループによって再検討されました。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [RFC1889]  Schulzrinne, H., Casner, S.,  Frederick, R. and V.
              Jacobson. "RTP: A Transport Protocol for Real-Time
              Applications", RFC 1889, January 1996.

[RFC1889] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン。 「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

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

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

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

エド[RFC2234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

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

[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

Huitema                     Standards Track                     [Page 6]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[6ページ]RFC3605

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy.
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

[RFC3489] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ。 「気絶させてください--ユーザデータグラムの簡単な縦断はネットワークアドレス変換機構(NATs)を通して(UDP)について議定書の中で述べる」RFC3489、2003年3月。

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R. and V.
              Jacobson. "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン。 「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。

9.2.  Informative References

9.2. 有益な参照

   [RFC2766]  Tsirtsis, G. and P. Srisuresh. "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

[RFC2766] Tsirtsis、G.、およびP.Srisuresh。 「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、2000年2月。

   [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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
              3369, August 2002.

[RFC3369] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3369、2002年8月。

   [RFC3424]  Daigle, L., "IAB considerations for UNilateral Self-
              Address Fixing (UNSAF) across network address
              translation", RFC 3424, November 2002.

[RFC3424]Daigle、L.、「ネットワークアドレス変換の向こう側のUNilateral SelfアドレスFixing(UNSAF)のためのIAB問題」、RFC3424、2002年11月。

10.  Author's Address

10. 作者のアドレス

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399

   EMail: huitema@microsoft.com

メール: huitema@microsoft.com

Huitema                     Standards Track                     [Page 7]

RFC 3605                 RTCP attribute in SDP              October 2003

RTCPが2003年10月にSDPで結果と考えるHuitema Standards Track[7ページ]RFC3605

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Huitema                     Standards Track                     [Page 8]

Huitema標準化過程[8ページ]