Network Working Group M. Westerlund
Request for Comments: 3890 Ericsson
Category: Standards Track September 2004
A Transport Independent Bandwidth Modifier
for the Session Description Protocol (SDP)
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.
この文書では、セッション記述プロトコル（SDP）輸送独立したアプリケーション固有の最大トランスポートオーバーヘッドを含まない（TIAS）帯域幅修飾子を定義します。代わりに、追加のパケットレート属性が定義されています。最大パケットレートと共に輸送独立したビットレート値は、実際に使用されるトランスポートを介して実ビットレートを計算するために使用することができます。
The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear.
既存のSDP帯域幅修飾子とその値は、トランスポートとIP層のために必要な帯域幅が含まれます。セッションアナウンスメントプロトコル（SAP）のようなプロトコルを用いてSDPを使用する場合は、セッション開始プロトコル（SIP）、リアルタイムストリーミングプロトコル（RTSP）、および関与する宿主としては、例えば、異なるIPバージョンの異なるトランスポートオーバーヘッドを有します、下位層の帯域幅が含まれているものの解釈は明らかではありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3
1.1.1. Conference Total . . . . . . . . . . . . . . . . 3
1.1.2. Application Specific Maximum . . . . . . . . . . 3
1.1.3. RTCP Report Bandwidth. . . . . . . . . . . . . . 4
1.2. IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . . 4
1.3. Further Mechanisms that Change the Bandwidth
Utilization. . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. IPsec. . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Header Compression . . . . . . . . . . . . . . . 5
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
3. The Bandwidth Signaling Problems . . . . . . . . . . . . . . . 6
3.1. What IP Version is Used. . . . . . . . . . . . . . . . . 6
3.2. Taking Other Mechanisms into Account . . . . . . . . . . 7
3.3. Converting Bandwidth Values. . . . . . . . . . . . . . . 8
3.4. RTCP Problems. . . . . . . . . . . . . . . . . . . . . . 8
3.5. Future Development . . . . . . . . . . . . . . . . . . . 9
3.6. Problem Conclusion . . . . . . . . . . . . . . . . . . . 9
4. Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11
6.2.1. Usage. . . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Definition . . . . . . . . . . . . . . . . . . . 12
6.2.3. Usage Rules. . . . . . . . . . . . . . . . . . . 13
6.3. Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13
6.4. Converting to Transport-Dependent Values . . . . . . . . 14
6.5. Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15
6.5.1. Motivation for this Solution. . . . . . . . . . . 15
6.6. ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16
6.7. Example. . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17
7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
This specification is structured in the following way: In this section, some information regarding SDP bandwidth modifiers, and different mechanisms that affect transport overhead are asserted. In section 3, the problems found are described, including problems that are not solved by this specification. In section 4 the scope of the problems this specification solves is presented. Section 5 contains the requirements applicable to the problem scope. Section 6 defines the solution, which is a new bandwidth modifier, and a new maximum packet rate attribute. Section 7 looks at the protocol interaction for SIP, RTSP, and SAP. The security considerations are discussed in section 8. The remaining sections are the necessary IANA considerations, acknowledgements, reference list, author's address, and copyright and IPR notices.
この仕様は、次のように構成されています。このセクションでは、いくつかの情報についてのSDP帯域幅修飾、およびトランスポート・オーバーヘッドに影響を与える異なるメカニズムがアサートされています。セクション3では、検出された問題は、本明細書によって解決されない問題を含む、記載されています。セクション4では、本明細書は解決する問題の範囲が提示されます。第5節では、問題の範囲に該当する要件が含まれています。第6節は、新しい帯域幅修飾子ですソリューション、および新しい最大パケットレート属性を定義します。第7節は、SIP、RTSP、およびSAP用のプロトコルの相互作用を調べます。セキュリティ上の考慮事項は、残りのセクションでは、必要なIANAの考慮、謝辞、参考文献リスト、著者のアドレス、著作権や知的財産権の告知ですセクション8で説明されています。
Today the Session Description Protocol (SDP) [1] is used in several types of applications. The original application is session information and configuration for multicast sessions announced with Session Announcement Protocol (SAP) [5]. SDP is also a vital component in media negotiation for the Session Initiation Protocol (SIP) [6] by using the offer answer model [7]. The Real-Time Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the client what media and codec(s) comprise a multi-media presentation.
今日のセッション記述プロトコル（SDP）は、[1]アプリケーションのいくつかのタイプに使用されます。元のアプリケーションは、セッションアナウンスメントプロトコル（SAP）で発表されたマルチキャストセッションのセッション情報および構成である[5]。 SDP [7]オファーアンサーモデルを使用して、セッション開始プロトコル（SIP）のメディアネゴシエーションにおける重要な成分[6]です。リアルタイムストリーミングプロトコル（RTSP）[8]また、メディアおよびコーデック（s）は、マルチメディアプレゼンテーションを構成するものをクライアントに宣言するためにSDPを使用しています。
In SDP [1] there exists a bandwidth attribute, which has a modifier used to specify what type of bit-rate the value refers to. The attribute has the following form:
SDP [1]の値が参照ビットレートの種類を指定するために使用される改質剤を有する帯域幅属性が、存在します。属性の形式は次のとおりです。
b=<modifier>:<value>
B = <修飾子>：<値>
Today there are four defined modifiers used for different purposes.
今日、異なる目的のために使用される4つの定義された修飾子があります。
The Conference Total is indicated by giving the modifier "CT". Conference total gives a maximum bandwidth that a conference session will use. Its purpose is to decide if this session can co-exist with any other sessions, defined in RFC 2327 [1].
会議の合計は、修飾語「CT」を与えることによって示されます。会議の合計は、会議セッションが使用する最大帯域幅を提供します。その目的は、このセッションは、RFC 2327で定義され、他のセッションと共存できるかどうかを決定することである[1]。
The Application Specific maximum bandwidth is indicated by the modifier "AS". The interpretation of this attribute is dependent on the application's notion of maximum bandwidth. For an RTP application, this attribute is the RTP session bandwidth as defined in RFC 3550 [4]. The session bandwidth includes the bandwidth that the RTP data traffic will consume, including the lower layers, down to the IP layer. Therefore, the bandwidth is in most cases calculated over RTP payload, RTP header, UDP, and IP, defined in RFC 2327 [1].
アプリケーション固有の最大帯域幅は、修飾語「AS」で示されています。この属性の解釈は、最大帯域幅のアプリケーションの概念に依存しています。 RTPアプリケーションの場合、この属性は、RFC 3550で定義されているRTPセッション帯域幅である[4]。セッション帯域幅は、RTPデータトラフィックはIP層まで、下位層を含む、消費されることに帯域幅を含んでいます。したがって、帯域幅は、[1] RFC 2327で定義されたRTPペイロード、RTPヘッダ、UDP、およびIP、上で計算ほとんどの場合です。
In RFC 3556 [9], two bandwidth modifiers are defined. These modifiers, "RS" and "RR", define the amount of bandwidth that is assigned for RTCP reports by active data senders and RTCP reports by other participants (receivers), respectively.
RFC 3556に[9]二帯域幅調整剤が定義されています。これらの改質剤、「RS」と「RR」は、それぞれ、アクティブなデータ送信者がRTCPレポートに割り当てられたとRTCPは、他の参加者（受信機）によって報告されている帯域幅の量を定義します。
Today there are two IP versions, 4 [14] and 6 [13], used in parallel on the Internet, creating problems. However, there exist a number of possible transition mechanisms.
今日のインターネット上で並行して使用される2つのIPバージョン4 [14]及び図6 [13]、問題の作成があります。しかしながら、可能な遷移機構の数が存在します。
- The nodes which wish to communicate must share the IP version; typically this is done by deploying dual-stack nodes. For example, an IPv4 only host cannot communicate with an IPv6 only host.
- 通信したいノードは、IPバージョンを共有する必要があります。通常、これはデュアルスタックノードを展開することによって行われます。例えば、IPv4の唯一のホストは、IPv6のみのホストと通信することができません。
- If communication between nodes which do not share a protocol version is required, use of a translation or proxying mechanism would be required. Work is underway to specify such a mechanism for this purpose.
- プロトコルのバージョンを共有しないノード間の通信が必要な場合、翻訳又はプロキシ機構の使用が必要とされるであろう。作業は、この目的のために、このようなメカニズムを指定するために進行中です。
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ------------- | |
| ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- |
------------------ ----------------------
Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
IPv6とIPv4アドレスとの間の図1変換またはプロキシ。
- IPv6 nodes belonging to different domains running IPv6, but lacking IPv6 connectivity between them, solve this by tunneling over the IPv4 net, see Figure 2. Basically, the IPv6 packets are sent as payload in IPv4 packets between the tunneling end-points at the edge of each IPv6 domain. The bandwidth required over the IPv4 domain will be different from IPv6 domains. However, as the tunneling is normally not performed by the application end-point, this scenario can not usually be taken into consideration.
- IPv6がIPv6を実行している別のドメインに属するノードが、それらの間のIPv6接続性を欠くことは、IPv4のネット上にトンネリングすることによって、これを解決するため、図2は、基本的に、IPv6パケットがでトンネルエンドポイント間でIPv4パケットにペイロードとして送信される参照各IPv6ドメインのエッジ。 IPv4のドメイン上で必要な帯域幅は、IPv6ドメインとは異なります。トンネリングは、通常のアプリケーション・エンドポイントによって実行されないようにしかし、このシナリオは、通常、考慮に入れることができません。
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
Figure 2. Tunneling through a IPv4 domain
IPv4のドメインを介して2トンネリング図
IPv4 has a minimum header size of 20 bytes, while the fixed part of the IPv6 header is 40 bytes.
IPv6ヘッダの固定部分が40バイトである間のIPv4は、20バイトの最小ヘッダサイズを有します。
The difference in header sizes means that the bit-rate required for the two IP versions is different. The significance of the difference depends on the packet rate and payload size of each packet.
ヘッダサイズの差は、2つのIPバージョンのために必要なビットレートが異なることを意味します。差の有意性は、各パケットのパケットレートおよびペイロードサイズに依存します。
There exist a number of other mechanisms that also may change the overhead at layers below media transport. We will briefly cover a few of these here.
また、媒体搬送以下層でオーバーヘッドを変更することができる他の多数のメカニズムが存在します。私たちは、ここで簡単にこれらのいくつかをカバーします。
IPsec [19] can be used between end points to provide confidentiality through the application of the IP Encapsulating Security Payload (ESP) [21] or integrity protection using the IP Authentication Header (AH) [20] of the media stream. The addition of the ESP and AH headers increases each packet's size.
IPsecの[19] IPカプセル化セキュリティペイロード（ESP）を適用して機密性を提供するために、エンドポイントとの間で使用することができる[21]またはメディアストリームのIP認証ヘッダ（AH）[20]を使用して完全性保護。 ESPとAHヘッダの追加は、各パケットのサイズが大きくなります。
To provide virtual private networks, complete IP packets may be encapsulated between an end node and the private networks security gateway, thus providing a secure tunnel that ensures confidentiality, integrity, and authentication of the packet stream. In this case, the extra IP and ESP header will significantly increase the packet size.
仮想プライベートネットワークを提供するために、完全なIPパケットは、このようにパケットストリームの機密性、完全性、および認証を確実に安全なトンネルを提供する、エンドノードとプライベートネットワークのセキュリティゲートウェイとの間に封入することができます。この場合、余分なIPおよびESPヘッダが大幅にパケットサイズを増加します。
Another mechanism that alters the actual overhead over links is header compression. Header compression uses the fact that most network protocol headers have either static or predictable values in their fields within a packet stream. Compression is normally only done on a per hop basis, i.e., on a single link. The normal reason for doing header compression is that the link has fairly limited bandwidth and significant gain in throughput is achieved.
リンク上で実際のオーバーヘッドを変化させる別の機構は、ヘッダ圧縮です。ヘッダ圧縮は、ほとんどのネットワークプロトコルヘッダは、パケットストリーム内のそれぞれの分野では、静的または予測可能な値のいずれかを持っているという事実を使用しています。圧縮は、通常、シングルリンクのみで、すなわち、ホップごとに行われます。ヘッダ圧縮を行うため、通常の理由は、リンクがかなり限られた帯域幅とスループットの大幅なゲインが達成さを持っていることです。
There exist several different header compression standards. For compressing IP headers only, there is RFC 2507 [10]. For compressing packets with IP/UDP/RTP headers, CRTP [11] was created at the same time. More recently, the Robust Header Compression (ROHC) working group has been developing a framework and profiles [12] for compressing certain combinations of protocols, like IP/UDP, and IP/UDP/RTP.
いくつかの異なるヘッダ圧縮の規格が存在します。唯一のIPヘッダを圧縮するために、RFC 2507 [10]があります。 IP / UDP / RTPヘッダのパケットを圧縮するために、CRTP [11]を同時に作成されました。さらに最近では、ロバストヘッダ圧縮は（ROHC）ワーキンググループは、IP / UDP、およびIP / UDP / RTPのように、プロトコルの特定の組み合わせを圧縮するためのフレームワークおよびプロファイル[12]を開発してきました。
ALG - Application Level Gateway. bps - bits per second. RTSP - Real-Time Streaming Protocol, see [8]. SDP - Session Description Protocol, see [1]. SAP - Session Announcement Protocol, see [5]. SIP - Session Initiation Protocol, see [6]. TIAS - Transport Independent Application Specific maximum, a bandwidth modifier.
ALG - アプリケーションレベルゲートウェイ。 BPS - ビット毎秒。 RTSP - リアルタイムストリーミングプロトコル、[8]を参照してください。 SDP - セッション記述プロトコル、[1]を参照してください。 SAP - セッションアナウンスメントプロトコル、[5]を参照してください。 SIP - セッション開始プロトコル、[6]を参照してください。 TIAS - トランスポートに依存しないアプリケーション固有の最大帯域幅修飾子。
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 BCP 14, RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[3]。
When an application wants to use SDP to signal the bandwidth required for this application, some problems become evident due to the inclusion of the lower layers in the bandwidth values.
アプリケーションは、このアプリケーションに必要な帯域を通知するSDPを使用したい場合、いくつかの問題が原因帯域幅値の下位層の包含に明らかになる。
If one signals the bandwidth in SDP, for example, using "b=AS:" as an RTP based application, one cannot know if the overhead is calculated for IPv4 or IPv6. An indication of which protocol has been used when calculating the bandwidth values is given by the "c=" connection address line. This line contains either a multicast group address or a unicast address of the data source or sink. The "c=" line's address type may be assumed to be of the same type as the one used in the bandwidth calculation, although no document specifying this point seems to exist.
一つはSDPで帯域幅を通知した場合、例えば、「B = AS：」を使用してオーバーヘッドがIPv4またはIPv6のために計算されている場合、RTPベースのアプリケーションのように、一方が知ることができません。帯域幅の値を計算する際に使用されたプロトコルの表示は、「C =」接続アドレスラインによって与えられます。この行は、マルチキャストグループアドレス又はデータソースまたはシンクのユニキャストアドレスのいずれかを含みます。この点を指定しない文書が存在すると思わないが、「C =」行のアドレスタイプは、帯域幅の計算に使用されるものと同じタイプのものであると仮定することができます。
In cases of SDP transported by RTSP, this is even less clear. The normal usage for a unicast on-demand streaming session is to set the connection data address to a null address. This null address does have an address type, which could be used as an indication. However, this is also not clarified anywhere.
RTSPによって運ばSDPの場合、これはさらに少なく明らかです。ユニキャストのオンデマンドストリーミングセッションのための通常の使用はヌルアドレスへの接続データのアドレスを設定することです。このヌルアドレスを指標として用いることができるアドレスの種類を持っています。しかし、これはまた、どこにも明らかにされていません。
Figure 1, illustrates a connection scenario between a streaming server A and a client B over a translator. When B receives the SDP from A over RTSP, it will be very difficult for B to know what the bandwidth values in the SDP represent. The following possibilities exist:
図1は、トランスレータ上ストリーミングサーバAとクライアントBとの間の接続シナリオを示します。 Bは、RTSPを介してAからSDPを受信すると、BはSDP内の帯域幅の値が何を表すかを知っているために、それは非常に困難になります。以下の可能性が存在します。
1. The SDP is unchanged and the "c=" null address is of type IPv4. The bandwidth value represents the bandwidth needed in an IPv4 network.
1. SDPは不変であり、「C =」ヌルアドレスがIPv4のタイプのものです。帯域幅の値は、IPv4ネットワークで必要な帯域幅を表します。
2. The SDP has been changed by an Application Level Gateway (ALG). The "c=" address is changed to an IPv6 type. The bandwidth value is unchanged.
2. SDPは、アプリケーションレベルゲートウェイ（ALG）によって変更されています。 「C =」アドレスは、IPv6タイプに変更されます。帯域幅の値は変更されません。
3. The SDP is changed and both "c=" address type and bandwidth value is converted. Unfortunately, this can seldom be done, see 3.3.
3. SDPが変更され、「C =」アドレスタイプと帯域幅の値の両方が変換されます。残念ながら、これはめったに行われないことができ、3.3を参照してください。
In case 1, the client can understand that the server is located in an IPv4 network and that it uses IPv4 overhead when calculating the bandwidth value. The client can almost never convert the bandwidth value, see section 3.3.
ケース1において、クライアントは、サーバがIPv4ネットワークに位置し、帯域幅の値を計算するとき、それは、IPv4のオーバーヘッドを使用することであることを理解することができます。クライアントは、帯域幅の値を変換することはほとんどないことができ、セクション3.3を参照してください。
In case 2, the client does not know that the server is in an IPv4 network and that the bandwidth value is not calculated with IPv6 overhead. In cases where a client uses this value to determine if its end of the network has sufficient resources the client will underestimate the required bit-rate, potentially resulting in bad application performance.
ケース2では、クライアントはサーバがIPv4ネットワーク内にあり、帯域幅の値がIPv6オーバーヘッドで計算されていないことを知りません。ネットワークのその端部が十分なリソースを持っている場合、クライアントが決定するために、この値を使用する場合には、クライアントは、潜在的に悪いアプリケーションのパフォーマンスが得られ、必要なビットレートを過小評価します。
In case 3, everything works correctly. However, this case will be very rare. If one tries to convert the bandwidth value without further information about the packet rate, significant errors may be introduced into the value.
ケース3では、すべてが正常に動作します。ただし、この場合は非常にまれでしょう。 1は、パケットレートについてのさらなる情報なしに帯域幅の値を変換しようとした場合、重大なエラーが値に導入することができます。
Section 1.2 and 1.3 lists a number of reasons, like header compression and tunnels, that would change lower layer header sizes. For these mechanisms there exist different possibilities to take them into account.
セクション1.2および1.3リスト下層ヘッダサイズを変化するヘッダ圧縮やトンネル等の理由により、数。これらのメカニズムのためにそれらを考慮するためにさまざまな可能性が存在します。
Using IPsec directly between end-points should definitely be known to the application, thus enabling it to take the extra headers into account. However the same problem also exists with the current SDP bandwidth modifiers where a receiver is not able to convert these values taking the IPsec headers into account.
直接エンドポイント間でIPsecを使用すると、間違いなくこれ口座に余分なヘッダを取るためにそれを可能にするアプリケーションに知られている必要があります。しかし、同じ問題は、受信機が考慮のIPsecヘッダを取って、これらの値を変換することができない現在のSDP帯域幅修飾子で存在します。
It is less likely that an application would be aware of the existence of a virtual private network. Thus the generality of the mechanism to tunnel all traffic may prevent the application from even considering whether it would be possible to convert the values.
アプリケーションが仮想プライベートネットワークの存在を認識しているであろう可能性は低いです。したがってトンネルのメカニズムの一般性は、すべてのトラフィックがあっても、値を変換することが可能であるかどうかを検討からアプリケーションを防止することができます。
When using header compression, the actual overhead will be less deterministic, but in most cases an average overhead can be determined for a certain application. If a network node knows that some type of header compression is employed, this can be taken into consideration. For RSVP [15], there exists an extension, RFC 3006 [16], that allows the data sender to inform network nodes about the compressibility of the data flow. To be able to do this with any accuracy, the compression factor and packet rate or size is needed, as RFC 3006 provides.
ヘッダー圧縮を使用する場合、実際のオーバーヘッドはそれほど決定的であろうが、ほとんどの場合、平均オーバーヘッドは、特定のアプリケーションのために決定することができます。ネットワークノードは、ヘッダ圧縮のいくつかのタイプが採用されていることを知っている場合、これは考慮することができます。 RSVPのために[15]、データ送信側がデータフローの圧縮についてネットワークノードに通知することを可能にする拡張、RFC 3006 [16]、が存在します。 RFC 3006が提供するような任意の精度でこれを行うことができるように、圧縮率及びパケットレートまたはサイズは、必要とされます。
If one would like to convert a bandwidth value calculated using IPv4 overhead to IPv6 overhead, the packet rate is required. The new bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" * 20 bytes, where 20 bytes is the usual difference between IPv6 and IPv4 headers. The overhead difference may be some other value in cases when IPv4 options [14] or IPv6 extension headers [13] are used.
1は、IPv6のオーバーヘッドへのIPv4オーバーヘッドを用いて計算した帯域幅の値を変換したい場合は、パケット速度が要求されます。 IPv6のための新たな帯域幅の値は、「IPv4の帯域幅」+「パケットレート」* 20のバイトは、IPv6とIPv4ヘッダとの間の通常の差である20バイト、正常です。オーバーヘッド差は、IPv4オプション[14]またはIPv6拡張ヘッダ[13]が使用される場合には他の値であってもよいです。
As converting requires the packet rate of the stream, this is not possible in the general case. Many codecs have either multiple possible packet/frame rates or can perform payload format aggregation, resulting in many possible rates. Therefore, some extra information in the SDP will be required. The "a=ptime:" parameter may be a possible candidate. However, this parameter is normally only used for audio codecs. Its definition [1] is that it is only a recommendation, which the sender may disregard. A better parameter is needed.
変換は、ストリームのパケットレートを必要とするように、これは一般的なケースでは不可能です。多くのコーデックは、複数の可能なパケット/フレームレートのいずれかを持っているか、多くの可能な速度が得られ、ペイロードフォーマットの集約を行うことができます。したがって、SDPでいくつかの追加情報が必要になります。 「= PTIME A：」パラメータが可能な候補かもしれません。しかし、このパラメータは、通常のみオーディオコーデックのために使用されています。その定義は、[1]送信者が無視できるだけの推薦、ということです。より良いパラメータが必要とされています。
When RTCP is used between hosts in IPv4 and IPv6 networks over translator, similar problems exist. The RTCP traffic going from the IPv4 domain will result in a higher RTCP bit-rate than intended in the IPv6 domain due to the larger headers. This may result in up to a 25% increase in required bandwidth for the RTCP traffic. The largest increase will be for small RTCP packets when the number of
RTCPは、翻訳上のIPv4およびIPv6ネットワーク内のホスト間で使用される場合、同様の問題が存在します。 IPv4のドメインから行くRTCPトラフィックは、より大きなヘッダによるIPv6ドメインに意図したよりも高いRTCPビットレートになります。これは、RTCPトラフィックに必要な帯域幅の25％増までになることがあります。最大の増加は、小さなRTCPパケットのためになるときの数
IPv4 hosts is much larger than the number of IPv6 hosts. Fortunately, as RTCP has a limited bandwidth compared to RTP, it will only result in a maximum of 1.75% increase of the total session bandwidth when RTCP bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily result in short term effects of the same magnitude, so this increase may be considered tolerable. The increase in bandwidth will in most cases be less.
IPv4ホストは、IPv6ホストの数よりもはるかに大きいです。 RTCPは、RTPと比較して限られた帯域幅を有するようにRTCP帯域幅がRTP帯域幅の5％である場合幸いにも、それだけで、総セッション帯域幅の1.75％増加の最大になります。 RTCPのランダム化は簡単に同じ大きさの短期的な効果をもたらすことができるので、この増加は許容と考えることができます。帯域幅の増加は、ほとんどの場合、少なくなります。
At the same time, this results in unfairness in the reporting between an IPv4 and IPv6 node. In the worst case scenario, the IPv6 node may report with 25% longer intervals.
同時に、これはIPv4とIPv6ノードとの間のレポートで不公平が生じます。最悪のシナリオでは、IPv6ノードは、25％より長い間隔で報告することができます。
These problems have been considered insignificant enough to not be worth any complex solutions. Therefore, only a simple algorithm for deriving RTCP bandwidth is defined in this specification.
これらの問題は、任意の複雑なソリューション価値がないように十分に重要でないと考えられてきました。したがって、RTCP帯域幅を導出するための単純なアルゴリズムは、この仕様で定義されています。
Today there is work in the IETF to design a new datagram transport protocol suitable for real-time media. This protocol is called the Datagram Congestion Control Protocol (DCCP). It will most probably have a different header size than UDP, which is the protocol most often used for real-time media today. This results in even more possible transport combinations. This may become a problem if one has the possibility of using different protocols, which will not be determined prior to actual protocol SETUP. Thus, pre-calculating this value will not be possible, which is one further motivation why a transport independent bandwidth modifier is needed.
今日、IETFでの作業がリアルタイムメディアに適した新しいデータグラムトランスポートプロトコルを設計することがあります。このプロトコルは、データグラム輻輳制御プロトコル（DCCP）と呼ばれています。それはおそらく、ほとんどの場合、今日のリアルタイムメディアのために使用されるプロトコルであるUDP、より異なるヘッダサイズを持つことになります。これは、さらに多くの可能なトランスポートの組み合わせになります。一つは、実際のプロトコルSETUP前に決定されない異なるプロトコルを使用する可能性を持っている場合、これは問題になることができます。したがって、この値を事前に計算することは、トランスポート独立した帯域幅修飾子が必要な理由一つのさらなる動機である、ことはできません。
DCCP's congestion control algorithms will control how much bandwidth can really be utilized. This may require further work with specifying SDP bandwidth modifiers to declare the dynamic possibilities of an application's media stream. For example, min and max media bandwidth the application is capable of producing at all, or for media codecs only capable of producing certain bit-rates, enumerating possible rates. However, this is for future study and outside the scope of the present solution.
DCCPの輻輳制御アルゴリズムは、実際に利用することができますどのくらいの帯域幅を制御します。これは、アプリケーションのメディアストリームの動的な可能性を宣言するためにSDP帯域幅修飾子を指定すると、さらに作業が必要な場合があります。例えば、最小および最大のメディア帯域幅のためにアプリケーションが全く産生することができる、または、特定のビットレートを製造可能な速度を列挙することができるだけメディアコーデックの。しかし、これは今後の研究のためにそして本ソリューションの範囲外です。
A shortcoming of the current SDP bandwidth modifiers is that they also include the bandwidth needed for lower layers. It is in many cases difficult to determine which lower layers and their versions were included in the calculation, especially in the presence of translation or proxying between different domains. This prevents a receiver from determining if given bandwidth needs to be converted based on the actual lower layers being used.
現在のSDP帯域幅剤の欠点は、それらが、下部層に必要な帯域幅を含むことがあります。特に、異なるドメイン間の変換またはプロキシの存在下で、下層とそのバージョンが計算に含まれていたかを決定するために多くの場合に困難です。これは、与えられた帯域幅が使用されている実際の下層に基づいて変換する必要があるかどうかを決定するから受信することを防止します。
Secondly, an attribute to give the receiver an explicit determination of the maximum packet rate that will be used does not exist. This value is necessary for accurate conversion of any bandwidth values if the difference in overhead is known.
第二に、受信機に使用される最大パケットレートを明示的に決定を与えるために属性が存在しません。オーバーヘッドの差が既知である場合、この値は、任意の帯域幅の値の正確な変換のために必要です。
The problems described in section 3 are common and effect application level signaling using SDP, other signaling protocols, and also resource reservation protocols. However, this document targets the specific problem of signaling the bit-rate in SDP. The problems need to be considered in other affected protocols and in new protocols being designed. In the MMUSIC WG there is work on a replacement of SDP called SDP-NG. It is recommended that the problems outlined in this document be considered when designing solutions for specifying bandwidth in the SDP-NG [17].
セクション3に記載された問題は、SDP、他のシグナリングプロトコルを使用して一般的かつ効果アプリケーション・レベルのシグナリングであり、また、予約プロトコルリソース。しかし、この文書は、SDPにおけるビットレートシグナリングの特定の問題を対象とします。問題は、他の影響を受けるのプロトコルにと設計されている新しいプロトコルに検討する必要があります。 MMUSIC WGではSDP-NGと呼ばれるSDPの交換の作業があります。 SDP-NG [17]で帯域幅を指定するためのソリューションを設計する際に、この文書で概説した問題を検討することをお勧めします。
As this specification only targets carrying the bit-rate information within SDP, it will have a limited applicability. As SDP information is normally transported end-to-end by an application protocol, nodes between the end-points will not have access to the bit-rate information. It will normally only be the end points that are able to take this information into account. An interior node will need to receive the information through a means other than SDP, and that is outside the scope of this specification.
この仕様は唯一のSDP内のビットレート情報を運ぶターゲットとして、それは限られた適用性を持つことになります。 SDP情報は、通常、エンドツーエンド・アプリケーション・プロトコルによって搬送されるように、エンドポイントとの間のノードは、ビットレート情報にアクセスできません。これは、通常のみこの情報を考慮することができますエンドポイントとなります。内部ノードは、SDP以外の手段を介して情報を受信する必要があります、そしてそれは、本明細書の範囲外です。
Nevertheless, the bit-rate information provided in this specification is sufficient for cases such as first-hop resource reservation and admission control. It also provide information about the maximum codec rate, which is independent of lower-level protocols.
それにもかかわらず、本明細書で提供されるビットレート情報は、最初のホップのリソース予約および入場制御などの場合には十分です。それはまた、より低いレベルのプロトコルから独立している最大コーデック・レートに関する情報を提供します。
This specification does NOT try to solve the problem of detecting NATs or other middleboxes.
この仕様は、NATのか、他のミドルボックスを検出する問題を解決しようとしません。
The problems outlined in the preceding sections and with the above applicability, should meet the following requirements:
問題は、前のセクションで概説し、上記の適用で、次の要件を満たしている必要があります。
- The bandwidth value SHALL be given in a way such that it can be calculated for all possible combinations of transport overhead.
- 帯域幅の値は、トランスポートオーバーヘッドのすべての可能な組み合わせのために計算することができるように与えられなければなりません。
This chapter describes a solution for the problems outlined in this document for the Application Specific (AS) bandwidth modifier, thus enabling the derivation of the required bit-rate for an application, or RTP session's data and RTCP traffic. The solution is based upon the definition of a new Transport Independent Application Specific (TIAS) bandwidth modifier and a new SDP attribute for the maximum packet rate (maxprate).
この章では、このように、アプリケーション、またはRTPセッションのデータとRTCPトラフィックのために必要なビットレートの導出を可能にする、アプリケーション固有の（AS）帯域改質のために本書で概説した問題に対する解決策を記載しています。溶液は、新たな交通独立したアプリケーションの特定（TIAS）帯域幅修飾子と最大パケットレート（maxprate）のための新しいSDP属性の定義に基づいています。
The CT is a session level modifier and cannot easily be dealt with. To address the problems with different overhead, it is RECOMMENDED that the CT value be calculated using reasonable worst case overhead. An example of how to calculate a reasonable worst case overhead is: Take the overhead of the largest transport protocol (using average size if variable), add that to the largest IP overhead that is expected for use, plus the data traffic rate. Do this for every individual media stream used in the conference and add them together.
CTは、セッションレベルの修飾子であり、容易に対処することはできません。別のオーバーヘッドの問題に対処するためには、CT値が妥当な最悪の場合のオーバーヘッドを使用して計算することが推奨されます。合理的な最悪の場合のオーバーヘッドを計算する方法の例は次のとおりです。使用が期待されている最大のIPのオーバーヘッドに加え、データトラフィックレートにそれを追加し、（可変の場合は平均サイズを使用して）最大転送プロトコルのオーバーヘッドを取ります。会議で使用されるすべての個々のメディアストリームのためにこれを行うと、それらを一緒に追加します。
The RR and RS modifiers [9] will be used as defined and include transport overhead. The small unfairness between hosts is deemed acceptable.
RRおよびRS改質剤は、[9]に定義として使用され、トランスポートオーバーヘッドを含むであろう。ホストとの間の小さな不公平が許容されるとみなされます。
A new bandwidth modifier is defined to be used for the following purposes:
新しい帯域幅修飾子は、次の目的で使用されるように定義されています。
- Resource reservation. A single bit-rate can be enough for use as a resource reservation. Some characteristics can be derived from the stream, codec type, etc. In cases where more information is needed, another SDP parameter will be required.
- リソース予約。単一のビットレートは、リソース予約として使用するのに十分なことができます。いくつかの特徴は、より多くの情報が必要な場合には、別のSDPパラメータが必要となる等、ストリーム、コーデックタイプに由来することができます。
- Maximum media codec rate. With the definition below of "TIAS", the given bit-rate will mostly be from the media codec. Therefore, it gives a good indication of the maximum codec bit-rate required to be supported by the decoder.
- 最大メディアコーデック率。 「TIAS」の下に定義して、与えられたビットレートは、主にメディアコーデックからとなります。したがって、デコーダによってサポートする必要が最大コーデックビットレートの良好な指標を与えます。
- Communication bit-rate required for the stream. The "TIAS" value together with "maxprate" can be used to determine the maximum communication bit-rate the stream will require. Using session level values or by adding all maximum bit-rates from the streams in a session together, a receiver can determine if its communication resources are sufficient to handle the stream. For example, a modem user can determine if the session fits his modem's capabilities and the established connection.
- ストリームのために必要な通信ビットレート。 「maxprate」とともに「TIAS」値は、ストリームが必要とする最大通信ビットレートを決定するために使用することができます。セッション・レベルの値を使用して、または一緒にセッション内のストリームからすべての最大ビットレートを加えることにより、その通信リソースがストリームを処理するのに十分である場合、受信機は、決定することができます。セッションは、彼のモデムの能力と確立された接続に合っている場合たとえば、モデムの利用者が決定することができます。
- Determine the RTP session bandwidth and derive the RTCP bandwidth. The derived transport dependent attribute will be the RTP session bandwidth in case of RTP based transport. The TIAS value can also be used to determine the RTCP bandwidth to use when using implicit allocation. RTP [4] specifies that if not explicitly stated, additional bandwidth, equal to 5% of the RTP session bandwidth, shall be used by RTCP. The RTCP bandwidth can be explicitly allocated by using the RR and RS modifiers defined in [9].
- RTPセッション帯域幅を決定し、RTCP帯域幅を導き出します。派生輸送に依存する属性は、RTPベースのトランスポートの場合はRTPセッション帯域幅になります。 TIAS値も暗黙的な割り当てを使用するときに使用するRTCP帯域幅を決定するために用いることができます。 RTP [4]は、明示的に述べられていない場合、RTPセッション帯域幅の5％に等しい追加の帯域幅が、RTCPで使用されなければならないことを指定します。 RTCP帯域幅を明示的に[9]で定義されたRRとRS修飾子を使用して割り当てることができます。
A new session and media level bandwidth modifier is defined:
新しいセッションとメディアレベルの帯域幅修飾子が定義されています。
b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.
B = TIAS：<帯域幅値>。 ABNF定義のためのセクション6.6を参照してください。
The Transport Independent Application Specific Maximum (TIAS) bandwidth modifier has an integer bit-rate value in bits per second. A fractional bandwidth value SHALL always be rounded up to the next integer. The bandwidth value is the maximum needed by the application (SDP session level) or media stream (SDP media level) without counting IP or other transport layers like TCP or UDP.
トランスポート独立したアプリケーション固有の最大（TIAS）帯域幅修飾子は、毎秒のビットの整数ビットレート値を有します。比帯域幅の値は、常に次の整数に切り上げられるものとします。帯域幅の値は、IPまたはTCPやUDPのような他のトランスポート層をカウントすることなく、アプリケーション（SDPセッションレベル）またはメディアストリーム（SDPメディアレベル）によって必要とされる最大値です。
At the SDP session level, the TIAS value is the maximal amount of bandwidth needed when all declared media streams are used. This MAY be less than the sum of all the individual media streams values. This is due to the possibility that not all streams have their maximum at the same point in time. This can normally only be verified for stored media streams.
SDPセッションレベルでは、TIAS値は宣言されたすべてのメディアストリームが使用されるときに必要な帯域幅の最大量です。これは、すべての個々のメディアストリームの合計値未満であってもよいです。これは、すべてのストリームが同一時点でその最大値を持っている可能性によるものです。これは、通常のみ保存されたメディアストリームのために確認することができます。
For RTP transported media streams, TIAS at the SDP media level can be used to derive the RTP "session bandwidth", defined in section 6.2 of [4]. In the context of RTP transport, the TIAS value is defined as:
RTPは、メディアストリームを搬送するために、SDPメディアレベルでTIAS [4]のセクション6.2で定義されたRTP「セッション帯域幅」を導出するために使用することができます。 RTP輸送の文脈では、TIAS値は次のように定義されます。
Only the RTP payload as defined in [4] SHALL be used in the calculation of the bit-rate, i.e., excluding the lower layers (IP/UDP) and RTP headers including RTP header, RTP header extensions, CSRC list, and other RTP profile specific fields. Note that the RTP payload includes both the payload format header and the data. This may allow one to use the same value for RTP-based media transport, non-RTP transport, and stored media.
[4] RTPヘッダ、RTPヘッダ拡張、CSRCリスト、および他のRTPを含む下位層（IP / UDP）とRTPヘッダを除いた、すなわち、ビットレートの計算に使用されるもので定義されるようにのみRTPペイロード特定のフィールドをプロファイリング。 RTPペイロードは、ペイロードフォーマットヘッダとデータの両方を含むことに留意されたいです。これは、1つのRTPベースのメディア輸送、非RTPトランスポート、および記憶されたメディアに同じ値を使用することを可能にし得ます。
Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This change has no implications on the parser, only the interpreter of the value must be aware. The change is done to allow for better resolution, and has also been used for the RR and RS bandwidth modifiers, see [9].
注1：BPSの使用は、RFC 2327に従っていない[1]。この変更は、パーサーには何の意味を持っていない、価値の唯一のインタプリタが認識する必要があります。変更がよりよい解決を可能にするために行われ、また、RRとRS帯域幅の修飾に使用されている、[9]参照。
Note 2: RTCP bandwidth is not included in the bandwidth value. In applications using RTCP, the bandwidth used by RTCP is either 5% of the RTP session bandwidth including lower layers or as specified by the RR and RS modifiers [9]. A specification of how to derive the RTCP bit-rate when using TIAS is presented in chapter 6.5.
注2：RTCP帯域幅は、帯域幅の値に含まれていません。 RTCPを使用するアプリケーションでは、RTCPにより使用される帯域幅が低い層を含むRTPセッション帯域幅のいずれかの5％又はRRとRS修飾子で指定された[9]。 TIASを使用するときにRTCPビットレートを導出する方法の仕様は、第6.5章に示されています。
"TIAS" is primarily intended to be used at the SDP media level. The "TIAS" bandwidth attribute MAY be present at the session level in SDP, if all media streams use the same transport. In cases where the sum of the media level values for all media streams is larger than the actual maximum bandwidth need for all streams, it SHOULD be included at session level. However, if present at the session level it SHOULD be present also at the media level. "TIAS" SHALL NOT be present at the session level unless the same transport protocols is used for all media streams. The same transport is used as long as the same combination of protocols is used, like IPv6/UDP/RTP.
「TIAS」は、主にSDPメディアレベルで使用されることが意図されます。すべてのメディアストリームが同じトランスポートを使用する場合、「TIAS」帯域幅属性は、SDPのセッションレベルで存在することができます。すべてのメディアストリームのメディアレベル値の和が全てのストリームに対する実際の最大帯域幅が必要よりも大きい場合には、セッション・レベルで含まれるべきです。しかし、セッション・レベルで存在する場合には、メディアレベルでも存在すべきです。同じトランスポートプロトコルは、すべてのメディアストリームに使用されない限り、「TIASは、」セッション・レベルで存在してはなりません。同じトランスポートは、IPv6 / UDP / RTPのように、限り、プロトコルの同じ組み合わせが使用されているとして使用されています。
To allow for backwards compatibility with applications of SDP that do not implement "TIAS", it is RECOMMENDED to also include the "AS" modifier when using "TIAS". The presence of a value including lower-layer overhead, even with its problems, is better than none. However, an SDP application implementing TIAS SHOULD ignore the "AS" value and use "TIAS" instead when both are present.
「TIAS」を実装していないSDPのアプリケーションとの後方互換性を可能にするためには、「TIAS」を使用しているときも、「AS」修飾子を含めることをお勧めします。下層オーバーヘッドを含む値の存在は、あってもその問題に、どれよりも優れています。しかし、TIASを実装するSDPアプリケーションは、「AS」の値を無視し、両方が存在する代わりに「TIAS」を使用すべきです。
When using TIAS for an RTP-transported stream, the "maxprate" attribute, if possible to calculate, defined next, SHALL be included at the corresponding SDP level.
可能な場合、次の定義、計算するために、RTP-搬送ストリームの「maxprate」属性をTIASを使用する場合、対応するSDPレベルで含めなければなりません。
To be able to calculate the bandwidth value including the lower layers actually used, a packet rate attribute is also defined.
実際に使用される下位層を含む帯域幅の値を計算することができるように、パケットレート属性も定義されています。
The SDP session and media level maximum packet rate attribute is defined as:
SDPセッションとメディアレベルの最大パケットレート属性は次のように定義されます
a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.
= maxprate：<パケットレート>; ABNF定義のためのセクション6.6を参照してください。
The <packet-rate> is a floating-point value for the stream's maximum packet rate in packets per second. If the number of packets is variable, the given value SHALL be the maximum the application can produce in case of a live stream, or for stored on-demand streams, has produced. The packet rate is calculated by adding the number of packets sent within a 1 second window. The maxprate is the largest value produced when the window slides over the entire media stream. In cases that this can't be calculated, i.e., a live stream, a estimated value of the maximum packet rate the codec can produce for the given configuration and content SHALL be used.
<パケットレートは>秒あたりのパケット内のストリームの最大パケットレートのための浮動小数点値です。パケットの数が可変である場合、所定の値は、アプリケーションがライブストリームの場合、または格納されたオンデマンドストリームに生成することができ、最大でなければならない、生産しています。パケットレートは、1秒ウィンドウ内で送信されたパケットの数を加算することによって計算されます。 maxprateは、ウィンドウが全体のメディアストリーム上をスライドするとき生じた最大値です。これはすなわち、計算することができない場合には、コーデックは、特定の構成及び内容のために生成することができるライブストリーム、最大パケット・レートの推定値を使用しなければなりません。
Note: The sliding window calculation will always yield an integer number. However the attributes field is a floating-point value because the estimated or known maximum packet rate per second may be fractional.
注：スライディングウィンドウ演算は常に整数をもたらします。秒あたりの推定または既知の最大パケットレートは分数であってもよいしかし属性フィールドは、浮動小数点値です。
At the SDP session level, the "maxprate" value is the maximum packet rate calculated over all the declared media streams. If this can't be measured (stored media) or estimated (live), the sum of all media level values provides a ceiling value. Note: the value at session level can be less then the sum of the individual media streams due to temporal distribution of media stream's maximums. The "maxprate" attribute MUST NOT be present at the session level if the media streams use different transport. The attribute MAY be present if the media streams use the same transport. If the attribute is present at the session level, it SHOULD also be present at the media level for all media streams.
SDPセッションレベルでは、「maxprate」値は、すべての宣言されたメディアストリーム上に計算された最大パケットレートです。これは、（ライブ）（記憶媒体）を測定または推定することができない場合、すべてのメディアレベル値の和が上限値を提供します。注意：セッション・レベルで値が原因メディアストリームの最大値の時間的分布に個々のメディアストリームの合計、その後以下とすることができます。メディアストリームは、異なるトランスポートを使用する場合、「maxprate」属性は、セッション・レベルであってはなりません。メディアストリームが同じトランスポートを使用する場合、属性が存在してもよいです。属性はセッションレベルで存在する場合、それはまた、すべてのメディアストリームのメディアレベルで存在すべきです。
"maxprate" SHALL be included for all transports where a packet rate can be derived and TIAS is included. For example, if you use TIAS and a transport like IP/UDP/RTP, for which the max packet rate (actual or estimated) can be derived, then "maxprate" SHALL be included. However, if either (a) the packet rate for the transport cannot be derived, or (b) TIAS is not included, then, "maxprate" is not required to be included.
「maxprateは」パケットレートを導出することができ、TIASが含まれているすべてのトランスポートのために含めなければなりません。あなたがTIASと最大パケットレート（実際または推定）を導出することができるためにIP / UDP / RTPなどのトランスポートを使用する場合たとえば、その後、「maxprate」が含まれるものとする（SHALL）。いずれかの（A）輸送のパケットレートを導出することができない、または（b）TIASが含まれていない場合は、次いで、「maxprate」が含まれることが必要とされません。
When converting the transport-independent bandwidth value (bw-value) into a transport-dependent value including the lower layers, the following MUST be done:
下位層を含む輸送に依存値にトランスポートに依存しない帯域幅の値（体重値）を変換すると、次のように行われなければなりません。
1. Determine which lower layers will be used and calculate the sum of the sizes of the headers in bits (h-size). In cases of variable header sizes, the average size SHALL be used. For RTP-transported media, the lower layers SHALL include the RTP header with header extensions, if used, the CSRC list, and any profile-specific extensions.
1.下位層が使用され、ビット（Hサイズ）におけるヘッダのサイズの合計を計算するかを決定。可変ヘッダサイズの場合には、平均サイズが使用されなければなりません。 RTP-搬送媒体のため、下位層は、ヘッダ拡張、使用される場合、CSRCリスト、および任意のプロファイル固有の拡張子を持つRTPヘッダを含むものとします。
3. Calculate the transport overhead by multiplying the header sizes by the packet rate (t-over = h-size * prate).
前記パケットレート（T-オーバー= Hサイズ* PRATE）によりヘッダ・サイズを乗算することにより、トランスポートオーバーヘッドを計算します。
4. Round the transport overhead up to nearest integer in bits (t-over = CEIL(t-over)).
トランスポートラウンド4.オーバーヘッドビットに最も近い整数まで（T-オーバー= CEIL（T-上））。
5. Add the transport overhead to the transport independent bandwidth value (total bit-rate = bw-value + t-over)
5.輸送独立帯域幅の値（合計ビットレート= BW-値+ Tオーバー）に伝送オーバヘッドを追加
When the above calculation is performed using the "maxprate", the bit-rate value will be the absolute maximum the media stream may use over the transport assumed in the calculations.
上記の計算は、「maxprate」を用いて行われた場合、ビットレートの値は、メディア・ストリームが計算で想定トランスポートを介して使用することができる絶対最大あろう。
This chapter does not solve the fairness and possible bit-rate change introduced by IPv4 to IPv6 translation. These differences are considered small enough, and known solutions introduce code changes to the RTP/RTCP implementation. This section provides a consistent way of calculating the bit-rate to assign to RTCP, if not explicitly given.
この章では、公平性とIPv6変換にはIPv4で導入可能なビットレートの変更を解決しません。これらの違いは十分に小さいと考えられ、既知の解決策は、RTP / RTCPの実装にコードの変更をご紹介します。このセクションでは、明示的に与えられていない場合、RTCPに割り当てるビットレートを計算する一貫性のある方法を提供します。
First the transport-dependent RTP session bit-rate is calculated, in accordance with section 6.4, using the actual transport layers used at the end point where the calculation is done. The RTCP bit-rate is then derived as usual based on the RTP session bandwidth, i.e., normally equal to 5% of the calculated value.
第一搬送依存RTPセッションのビットレートは、計算が行われたエンドポイントで使用される実際のトランスポート層を使用して、セクション6.4に従って、計算されます。 RTCPビットレートは、その後、計算された値の5％正常に等しい、すなわち、RTPセッション帯域幅に基づいて、通常のように導出されます。
Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6 hosts will result in the IPv4 host having a higher RTCP sending rate. The sending rate represents the number of RTCP packets sent during a given time interval. The sending of RTCP is limited according to rules defined in the RTP specification [4]. For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has an approximately 20% higher sending rate. This rate falls with larger RTCP packets. For example, 300-byte packets will only give the IPv4 host a 7% higher sending rate.
IPv4とIPv6の両方のホストへまったく同じRTCPビットレート値を与えることは、より高いRTCP送信レートを有するIPv4ホストになります。送信速度は、所与の時間間隔中に送信されたRTCPパケットの数を表します。 RTCPの送信RTP仕様[4]で定義されたルールに従って制限されます。 （UDP / IPv4のを含む）100バイトのRTCPパケットを、IPv4の送信者は、約20％より高い送信速度を有しています。このレートは、より大きなRTCPパケットに落ちます。例えば、300バイトのパケットは、IPv4ホスト7％高い送信速度を与えます。
The above rule for deriving RTCP bandwidth gives the same behavior as fixed assignment when the RTP session has traffic parameters giving a large TIAS/maxprate ratio. The two hosts will be fair when the TIAS/maxprate ratio is approximately 40 bytes/packet, given 100-byte RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6 host will be allowed to send approximately 15-20% more RTCP packets.
RTPセッションが大きいTIAS / maxprate比を与えるトラフィックパラメータを有する場合RTCP帯域幅を導出するための上記規則は、固定割り当てと同じ挙動を与えます。 TIAS / maxprate比が100バイトのRTCPパケットが与えられると、約40バイト/パケットであるときに、2つのホストは公平であろう。 5つのバイト/パケットのTIAS / maxprate比ため、IPv6ホストは、約15〜20％、よりRTCPパケットを送信することを許可されるであろう。
The larger the RTCP packets become, the more it will favor the IPv6 host in its sending rate.
RTCPパケットになるが大きいほど、それはその送信レートでのIPv6ホストを好むだろう。
The conclusions is that, within the normal useful combination of transport-independent bit rates and packet rates, the difference in fairness between hosts on different IP versions with different overhead is acceptable. For the 20-byte difference in overhead between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a unicast connection case will not be larger than approximately 1% of the total session bandwidth.
結論は、トランスポート非依存のビットレート及びパケットレートの通常の有用な組み合わせ内に、異なるオーバーヘッドと異なるIPバージョンのホスト間の公平性の差が許容可能である、ということです。 IPv4とIPv6ヘッダとの間のオーバーヘッドの20バイトの差のために、実際にユニキャスト接続の場合に用いられるRTCP帯域幅は、全セッションの帯域幅の約1％よりも大きくないであろう。
This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier and the packet rate attribute.
この章では、RFC 2234 [2]帯域幅変更子及びパケットレート属性からABNFで定義します。
The bandwidth modifier:
帯域幅修飾子：
TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
TIAS帯域幅-DEF = "B" "=" "TIAS" "：" 帯域幅の値CRLF
bandwidth-value = 1*DIGIT
帯域幅の値= 1 * DIGIT
The maximum packet rate attribute:
最大パケットレート属性：
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
MAX-P-率-DEF = "" "=" "maxprate" "：" パケットレートCRLF
packet-rate = 1*DIGIT ["." 1*DIGIT]
パケットレート= 1 * DIGITの[ "" 1 * DIGIT]
v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of TIAS and maxprate in use
c=IN IP4 0.0.0.0
b=AS:60
b=TIAS:50780
t=0 0
a=control:rtsp://server.example.com/media.3gp
a=range:npt=0-150.0
a=maxprate:28.0
m=audio 0 RTP/AVP 97
b=AS:12
b=TIAS:8480
a=maxprate:10.0
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align;
a=control:rtsp://server.example.com/media.3gp/trackID=1
m=video 0 RTP/AVP 99 b=AS:48
b=TIAS:42300
a=maxprate:18.0
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8;
config=000001B008000001B509000001010000012000884006682C2090A21F
a=control:rtsp://server.example.com/media.3gp/trackID=3
In this SDP example of a streaming session's SDP, there are two media streams, one audio stream encoded with AMR and one video stream encoded with the MPEG-4 Video encoder. AMR is used here to produce a constant rate media stream and uses a packetization resulting in 10 packets per second. This results in a TIAS bandwidth rate of 8480 bits per second, and the claimed 10 packets per second. The video stream is more variable. However, it has a measured maximum payload rate of 42,300 bits per second. The video stream also has a variable packet rate, despite the fact that the video is 15 frames per second, where at least one instance in a second long window contains 18 packets.
ストリーミング・セッションのSDPのこのSDP例では、2つのメディアストリーム、AMRで符号化つのオーディオストリームとMPEG-4ビデオ符号器で符号化された一つのビデオストリームがあります。 AMRは、一定のレートメディアストリームを生成するためにここで使用され、毎秒10個のパケットで得パケットを使用しています。これは、毎秒8480ビット、及び毎秒主張10のパケットのTIAS帯域幅レートをもたらします。ビデオストリームは、より多くの変数です。しかし、それは毎秒42300ビットの測定された最大ペイロードレートを有します。ビデオストリームは、ビデオが第二長窓内に少なくとも1つのインスタンスが18個のパケットを含む毎秒15のフレームであるという事実にもかかわらず、可変パケットレートを有しています。
The "TIAS" and "maxprate" parameters can be used with RTSP as currently specified. To be able to calculate the transport dependent bandwidth, some of the transport header parameters will be required. There should be no problem for a client to calculate the required bandwidth(s) prior to an RTSP SETUP. The reason is that a client supports a limited number of transport setups. The one actually offered to a server in a SETUP request will be dependent on the contents of the SDP description. The "m=" line(s) will signal the desired transport profile(s) to the client.
「TIAS」と「maxprate」パラメータは、現在指定されているRTSPで使用することができます。輸送依存帯域幅を計算することができるように、トランスポート・ヘッダ・パラメータの一部が必要とされるであろう。 RTSPのSETUPに先立って必要な帯域幅（複数可）を計算するためのクライアントのためには問題があってはなりません。その理由は、クライアントがトランスポートセットアップの限られた数をサポートしていることです。実際にSETUP要求でサーバーに提供1は、SDP記述の内容に依存することになります。 「M =」行（複数可）は、クライアントに、所望のトランスポート・プロファイル（複数可）信号を送ります。
The usage of "TIAS" together with "maxprate" should not be different from the handling of the "AS" modifier currently in use. The needed transport parameters will be available in the transport field in the "m=" line. The address class can be determined from the "c=" field and the client's connectivity.
一緒に「maxprate」と「TIAS」の使用は、現在使用中の修飾語の「AS」の取り扱いとは異なることはないはずです。必要なトランスポートパラメータは、「M =」行の輸送分野で利用可能であろう。アドレスクラスは、「C =」フィールドと、クライアントの接続性から判断することができます。
In the case of SAP, all available information to calculate the transport dependent bit-rate should be present in the SDP. The "c=" information gives the address family used for the multicast. The transport layer, e.g., RTP/UDP, for each media is evident in the media line ("m=") and its transport field.
SAPの場合には、トランスポートに依存するビット・レートを計算するために利用可能なすべての情報は、SDPで存在すべきです。 「C =」の情報は、マルチキャストのために使用されるアドレスファミリを提供します。トランスポート層は、例えば、RTP / UDPは、各メディアのメディア行（「M =」）およびその輸送分野で明らかです。
The bandwidth value that is supplied by the parameters defined here can be altered, if not integrity protected. By altering the bandwidth value, one can fool a receiver into reserving either more or less bandwidth than actually needed. Reserving too much may result in unwanted expenses on behalf of the user, while also blocking resources that other parties could have used. If too little bandwidth is reserved, the receiving user's quality may be effected. Trusting a too-large TIAS value may also result in the receiver rejecting the session due to insufficient communication and decoding resources.
ない整合性が保護された場合は、ここで定義されたパラメータによって供給されている帯域幅の値は、変更することができます。帯域幅の値を変更することにより、一つは実際に必要以上の以下のいずれかの帯域幅を確保するに受信機をだますことができます。また、他の当事者が使用している可能性がリソースをブロックしながら、あまりにも多くの予約は、ユーザーに代わって、不要な経費をもたらすことができます。あまりにも少ない帯域幅が予約されている場合、受信者の質が行われてもよいです。大きすぎるTIAS値を信頼することも不足通信および復号リソースにセッションを拒否する受信機をもたらすことができます。
Due to these security risks, it is strongly RECOMMENDED that the SDP be integrity protected and source authenticated so tampering can not be performed, and the source can be trusted. It is also RECOMMENDED that any receiver of the SDP perform an analysis of the received bandwidth values to verify that they are reasonable expected values for the application. For example, a single channel AMR-encoded voice stream claiming to use 1000 kbps is not reasonable.
これらのセキュリティリスクのために、それを強くSDPは、完全性を保護し、ソースはそうは実行できません改ざん、認証することが推奨され、ソースが信頼することができます。また、SDPのいずれかの受信機は、それらがアプリケーションのための合理的な期待値であることを確認するために、受信された帯域幅の値の分析を実行することをお勧めします。例えば、1000年kbpsのを使用することを主張し、単一チャネルAMR-符号化された音声ストリームは合理的ではありません。
Please note that some of the above security requirements are in conflict with that required to make signaling protocols using SDP work through a middlebox, as discussed in the security considerations of RFC 3303 [18].
[18] RFC 3303のセキュリティ上の考慮事項で説明したように、上記セキュリティ要件のいくつかは、ミドルボックスを介してSDPワークを使用して、プロトコルシグナリングするために必要なものと矛盾していることに注意してください。
This document registers one new SDP session and media level attribute "maxprate", see section 6.3.
この文書は、1新しいSDPセッションとメディアレベル属性「maxprate」を登録し、6.3節を参照してください。
A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered in accordance with the rules requiring a standards-track RFC. The modifier is defined in section 6.2.
新しいSDP [1]帯域幅変更子（bwtype）「TIAS」はまた、標準トラックRFCを必要とする規則に従って登録されています。修飾子はセクション6.2で定義されています。
The author would like to thank Gonzalo Camarillo and Hesham Soliman for their work reviewing this document. A very big thanks goes to Stephen Casner for reviewing and helping fix the language, and identifying some errors in the previous versions. Further thanks for suggestion to improvements go to Colin Perkins, Geetha Srikantan, and Emre Aksu.
著者はこの文書を見直し、自分の仕事のためにゴンサロ・カマリロとHeshamソリマンに感謝したいと思います。非常に大きな感謝を見直し、言語を修正助け、および以前のバージョンではいくつかのエラーを識別するためのスティーブンCasnerに行きます。改善への提案のためのさらなるおかげでコリンパーキンス、ジーサSrikantan、およびエムレアクスに行きます。
The author would also like to thank all persons on the MMUSIC working group's mailing list that have commented on this specification.
著者はまた、この仕様にコメントしているメーリングリストMUSICワーキンググループ上のすべての人に感謝したいと思います。
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[5]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[6] 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.
[6]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[9] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[9] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月に。
[10] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[10] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[11] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[12]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[13]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[14]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[15]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J. Wroclawski, "Integrated Services in the Presence of Compressible Flows", RFC 3006, November 2000.
[16]デイビー、B.、Iturralde、C.、オラン、D.、Casner、S.、およびJ. Wroclawski、 "圧縮性流れの存在下での統合サービス"、RFC 3006、2000年11月。
[17] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation," Work in Progress, March 2003.
[17] Kutscher、オット、ボルマン、進歩、2003年3月に「セッション記述と能力交渉、」ワーク。
[18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[18] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[19]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[20]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[21]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN
マグヌスウェスターエリクソン研究エリクソンAB Torshamnsgatan 23 SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
電話：+46 8 7190000 Eメール：Magnus.Westerlund@ericsson.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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/S HE 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されています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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。