RFC3605 日本語訳
3605 Real Time Control Protocol (RTCP) attribute in SessionDescription Protocol (SDP). C. Huitema. October 2003. (Format: TXT=17270 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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ページ]
一覧
スポンサーリンク