[要約] RFC 3890は、SDPのためのトランスポート非依存の帯域幅修正子に関する要約です。このRFCの目的は、SDPセッションの帯域幅を調整するための一貫性のある方法を提供することです。
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)
セッション説明プロトコル（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）The Internet Society（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）、セッション開始プロトコル（SIP）、リアルタイムストリーミングプロトコル（RTSP）などのプロトコルを使用してSDPを使用する場合、および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のプロトコル相互作用について説明します。セキュリティ上の考慮事項については、セクション8で説明します。残りのセクションは、必要なIANAの考慮事項、謝辞、参照リスト、著者の住所、著作権およびIPR通知です。
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]は、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>
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 [4]で定義されているRTPセッション帯域幅です。セッション帯域幅には、RTPデータトラフィックがIPレイヤーまで下にあるRTPデータトラフィックが消費する帯域幅が含まれています。したがって、帯域幅は、ほとんどの場合、RFC 2327で定義されているRTPペイロード、RTPヘッダー、UDP、およびIPで計算されます[1]。
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]では、2つの帯域幅修飾子が定義されています。これらの修飾子「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.
図1. IPv6とIPv4アドレスの間の翻訳またはプロキシ。
- 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
図2. IPv4ドメインを通るトンネリング
IPv4 has a minimum header size of 20 bytes, while the fixed part of the IPv6 header is 40 bytes.
IPv4の最小ヘッダーサイズは20バイトですが、IPv6ヘッダーの固定部分は40バイトです。
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認証ヘッダー（AH）[20]を使用したIPカプセル化セキュリティペイロード（ESP）[21]を使用して、IPカプセル化セキュリティペイロード（ESP）[21]を適用することにより機密性を提供できます。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.
リンク上の実際のオーバーヘッドを変更する別のメカニズムは、ヘッダー圧縮です。ヘッダー圧縮では、ほとんどのネットワークプロトコルヘッダーがパケットストリーム内のフィールドに静的または予測可能な値を持っているという事実を使用します。圧縮は通常、1ホップごとに、つまり単一のリンクでのみ行われます。ヘッダー圧縮を行う通常の理由は、リンクが帯域幅がかなり限られており、スループットの大幅な増加が達成されることです。
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.
アルグ - アプリケーションレベルゲートウェイ。BPS- 1秒あたりのビット。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
たとえば、「b = as」を使用してSDPの帯域幅を信号する場合、RTPベースのアプリケーションとして、IPv4またはIPv6についてオーバーヘッドが計算されるかどうかはわかりません。帯域幅の値を計算する際にどのプロトコルが使用されているかを示すことは、「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の場合、これはさらに明確ではありません。ユニキャストオンデマンドストリーミングセッションの通常の使用法は、接続データアドレスをnullアドレスに設定することです。このnullアドレスにはアドレスタイプがあり、これを適応として使用できます。ただし、これはどこでも明確にされていません。
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 =」nullアドレスはタイプ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では、すべてが正しく機能します。ただし、このケースは非常にまれです。パケットレートに関する詳細情報なしに帯域幅の値を変換しようとすると、値に大幅なエラーが導入される場合があります。
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.
IPv4オーバーヘッドを使用して計算された帯域幅値をIPv6オーバーヘッドに変換したい場合は、パケットレートが必要です。IPv6の新しい帯域幅値は、通常「IPv4帯域幅」「パケットレート」 * 20バイトで、20バイトがIPv6ヘッダーとIPv4ヘッダーの通常の違いです。オーバーヘッドの違いは、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のいくつかの追加情報が必要になります。「a = ptime：」パラメーターは、可能な候補である可能性があります。ただし、このパラメーターは通常、オーディオコーデックにのみ使用されます。その定義[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 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を使用すると、同様の問題が存在します。IPv4ドメインからのRTCPトラフィックは、ヘッダーが大きいため、IPv6ドメインで意図されているよりも高いRTCPビットレートになります。これにより、RTCPトラフィックに必要な帯域幅が最大25％増加する可能性があります。最大の増加は、IPv4ホストの数がIPv6ホストの数よりもはるかに大きい場合、小さなRTCPパケットの場合です。幸いなことに、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には、リアルタイムメディアに適した新しいデータグラムトランスポートプロトコルを設計する作業があります。このプロトコルは、Datagram輻輳制御プロトコル（DCCP）と呼ばれます。おそらく、UDPとは異なるヘッダーサイズを持っているでしょう。これは、今日のリアルタイムメディアに最もよく使用されるプロトコルです。これにより、さらに可能な輸送の組み合わせが生じます。これは、実際のプロトコルのセットアップの前に決定されない異なるプロトコルを使用する可能性がある場合に問題になる可能性があります。したがって、この値を事前に計算することは不可能です。これは、輸送に独立した帯域幅修飾子が必要である理由のさらに1つの動機です。
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帯域幅修飾子を指定することでさらなる作業が必要になる場合があります。たとえば、MINおよびMAXメディアの帯域幅アプリケーションはまったく生産できます。また、特定のビットレートを生産できるメディアコーデックの場合、可能なレートを列挙します。ただし、これは将来の研究と現在のソリューションの範囲外です。
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).
この章では、アプリケーション固有の（AS）帯域幅修飾子についてこのドキュメントで概説されている問題の解決策について説明します。これにより、アプリケーションに必要なビットレート、またはRTPセッションのデータとRTCPトラフィックの導出が可能になります。このソリューションは、新しいトランスポート独立アプリケーション固有（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：<bandwidth-value>;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）帯域幅修飾子は、1秒あたりビットで整数ビットレート値を持っています。分数帯域幅の値は、常に次の整数にまとめられなければなりません。帯域幅値は、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メディアレベルのTIAを使用して、[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ヘッダー、RTPヘッダー拡張機能、CSRCリスト、その他のRTPを含む下層（IP/UDP）およびRTPヘッダーを除外します。プロファイル固有のフィールド。RTPペイロードには、ペイロードフォーマットヘッダーとデータの両方が含まれていることに注意してください。これにより、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]。TIAを使用する場合の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.
「TIA」を実装していないSDPのアプリケーションとの後方互換性を可能にするには、「TIA」を使用するときに「AS」修飾子を含めることをお勧めします。低層のオーバーヘッドを含む値の存在は、その問題があっても、誰よりも優れています。ただし、TIAを実装するSDPアプリケーションでは、両方が存在する場合は「as "value and" 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輸送されたストリームにTIAを使用する場合、「MaxPrate」属性は、次に定義された計算に可能であれば、対応する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.
a = maxprate：<packet-rate>;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.
注：スライドウィンドウの計算は、常に整数数を生成します。ただし、属性フィールドは、1秒あたりの推定または既知の最大パケットレートが分数である可能性があるため、浮動小数点値です。
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.
パケットレートを導出してTIAが含まれるすべての輸送に「MaxPrate」を含めるものとします。たとえば、最大パケットレート（実際または推定）を導出できるTIAとIP/UDP/RTPのようなトランスポートを使用する場合、「MaxPrate」を含めるものとします。ただし、（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:
輸送に依存しない帯域幅値（BW値）を下層を含む輸送依存の値に変換する場合、次のことを行う必要があります。
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ヘッダーを含めるものとします。
2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
2. SDP（Prate = MaxPrate）から最大パケットレートを取得します。
3. Calculate the transport overhead by multiplying the header sizes by the packet rate (t-over = h-size * prate).
3. ヘッダーサイズにパケットレート（t-over = h-size * prate）を掛けて、輸送オーバーヘッドを計算します。
4. Round the transport overhead up to nearest integer in bits (t-over = CEIL(t-over)).
4. 輸送のオーバーヘッドをビットの最も近い整数まで丸くします（t-over = ceil（t-over））。
5. Add the transport overhead to the transport independent bandwidth value (total bit-rate = bw-value + t-over)
5. トランスポートオーバーヘッドを輸送に独立した帯域幅値に追加します（合計ビットレート= bw-value t-over）
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.
この章では、IPv4がIPv6翻訳に導入した公平性と可能なビットレートの変更を解決しません。これらの違いは十分に小さいと見なされ、既知のソリューションは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.
最初に、計算が行われるエンドポイントで使用される実際の輸送層を使用して、セクション6.4に従って、輸送依存のRTPセッションビットレートが計算されます。RTCPビットレートは、RTPセッション帯域幅、つまり計算値の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ビットレート値を与えると、IPv4ホストがRTCPの送信率が高くなります。送信率は、特定の時間間隔中に送信されるRTCPパケットの数を表します。RTCPの送信は、RTP仕様[4]で定義されているルールに従って制限されています。100バイトのRTCPパケット（UDP/IPv4を含む）の場合、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.
RTCP帯域幅を導出するための上記のルールは、RTPセッションにトラフィックパラメーターがある場合、固定割り当てと同じ動作を与えます。TIAS/MAXPRATE比が約40バイト/パケットの場合、100バイトのRTCPパケットが与えられた場合、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
bandwidth-value = 1*DIGIT
The maximum packet rate attribute:
最大パケットレート属性：
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
packet-rate = 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でエンコードされた1つのオーディオストリームと、MPEG-4ビデオエンコーダーでエンコードされた1つのビデオストリームがあります。ここでは、一定のレートメディアストリームを生成するためにAMRが使用され、パケット化を使用して10秒あたり10パケットを使用します。これにより、1秒あたり8480ビットのTIAS帯域幅率が発生し、請求された10パケットが1秒になります。ビデオストリームはより変動します。ただし、測定された最大ペイロードレートは1秒あたり42,300ビットです。ビデオストリームには、ビデオが1秒あたり15フレームであるという事実にもかかわらず、ビデオストリームには変動するパケットレートもあります。2番目の長いウィンドウの少なくとも1つのインスタンスには18のパケットが含まれています。
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.
現在指定されているように、RTSPで「Tias」および「Maxprate」パラメーターを使用できます。輸送依存帯域幅を計算できるようにするには、輸送ヘッダーパラメーターの一部が必要になります。クライアントがRTSPセットアップの前に必要な帯域幅を計算するのに問題はないはずです。その理由は、クライアントが限られた数の輸送セットアップをサポートしているためです。セットアップリクエストで実際にサーバーに提供されるものは、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].
上記のセキュリティ要件の一部は、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.
著者は、ゴンザロ・カマリロとヘシャム・ソリマンがこの文書をレビューしてくれたことに感謝したいと思います。言語の修正と修正、および以前のバージョンのいくつかのエラーを特定してくれたStephen Casnerに非常に感謝しています。さらに、改善の提案をありがとう、コリンパーキンス、ゲーサスリカンタン、およびエムレアクシュにお寄せください。
The author would also like to thank all persons on the MMUSIC working group's mailing list that have commented on this specification.
著者はまた、この仕様についてコメントしたMMUSICワーキンググループのメーリングリストのすべての人に感謝したいと思います。
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[5] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne、H.、Rao、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。、「RTPコントロールプロトコル（RTCP）帯域幅のセッション説明プロトコル（SDP）帯域幅修飾子」、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. Pink、「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. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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] 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.、およびH. Zheng、 "Robust Header圧縮（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] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[14] Postel、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Davie、B.、Iturralde、C.、Oran、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、Ott、Bormann、「セッションの説明と能力交渉」、Work in Progress、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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
[19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[19] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[20] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[21] Kent、S。およびR. Atkinson、「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 Stockholm、Sweden
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。