Network Working Group S. Casner
Request for Comments: 3556 Packet Design
Category: Standards Track July 2003
Session Description Protocol (SDP) Bandwidth Modifiers
for RTP Control Protocol (RTCP) Bandwidth
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session.
この文書では、帯域幅属性のための2つの追加の修飾子を指定するためのセッション記述プロトコル（SDP）への拡張を定義します。これらの修飾子は、リアルタイムトランスポートプロトコル（RTP）セッションでのRTP制御プロトコル（RTCP）パケットに許可される帯域幅を指定するために使用することができます。
The Real-time Transport Protocol (RTP), RFC 3550 [1], includes a control protocol RTCP which provides synchronization information from data senders and feedback information from data receivers.
リアルタイムトランスポートプロトコル（RTP）は、RFC 3550 [1]は、データ送信者とデータ受信機からのフィードバック情報から同期情報を提供する制御プロトコルRTCPを含みます。
Normally, the amount of bandwidth allocated to RTCP in an RTP session is 5% of the session bandwidth. For some applications, it may be appropriate to specify the RTCP bandwidth independently of the session bandwidth. Using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter. That allows the RTCP bandwidth to be kept under 5% of the data bandwidth when the rate has been adapted downward.
通常、RTPセッションでRTCPに割り当てられる帯域幅の量は、セッション帯域幅の5％です。一部のアプリケーションでは、独立したセッション帯域幅のRTCP帯域幅を指定することが適切であろう。別のパラメータを使用すると、セッション帯域幅パラメータで指定された最大帯域幅よりも低い「典型的な」データの帯域幅と一致するRTCP帯域幅を設定するためのレート適応型アプリケーションを可能にします。つまり、レートが下方に適応されたときにRTCP帯域幅は、データ帯域幅の5％下に維持されることを可能にします。
On the other hand, there may be applications that send data at very low rates but need to communicate extra RTCP information, such as APP packets. These applications may need to specify RTCP bandwidth that is higher than 5% of the data bandwidth.
一方、非常に低いレートでデータを送信するが、このようなAPPパケットなどの余分なRTCP情報を、通信する必要があるアプリケーションがあるかもしれません。これらのアプリケーションは、データ帯域幅の5％以上であるRTCP帯域幅を指定する必要があります。
The RTP specification allows a profile to specify that the RTCP bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is not recommended because they are needed for the functions listed in the RTP specification, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that do not require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion.
RTP仕様はプロフィールはRTCP帯域幅は、アクティブなデータ送信者とされていないものであり、これらの参加者のための2つの別々のセッションパラメータに分割することができることを指定することを可能にします。 2つのパラメータを使用すると、RTCP受信レポートが送信者レポートは、まだ相互のために送信することができるように、データの送信者の非ゼロのためのRTCP帯域幅を維持しながら、ゼロに非データ送信者のためのRTCP帯域幅を設定することにより、特定のセッションのために完全にオフにすることを可能にします-media同期。それらはRTP仕様に記載されている機能のために必要とされるため、RTCP受信レポートをオフにすると、特に受信品質のフィードバックや輻輳制御をお勧めしません。しかし、そうすることは、単方向リンク上でのオペレーティングシステム用または受信や受信機の生存性の品質に関するフィードバックを必要としているが、混雑を避けるために他の手段を持っていないセッションのために適切かもしれません。
This memo defines an extension to the Session Description Protocol (SDP) [3] to specify RTCP bandwidth for senders and non-senders (receivers).
このメモは、セッション記述プロトコル（SDP）[3]送信者と非送信者（受信機）のためのRTCP帯域幅を指定するための拡張を定義します。
The Session Description Protocol includes an optional bandwidth attribute with the following syntax:
セッション記述プロトコルは、次の構文を使用して、オプションの帯域幅の属性が含まれています。
b=<modifier>:<bandwidth-value>
B = <修飾子>：<帯域幅値>
where <modifier> is a single alphanumeric word giving the meaning of the bandwidth figure, and where the default units for <bandwidth-value> are kilobits per second. This attribute specifies the proposed bandwidth to be used by the session or media.
ここで、<修飾子>は、帯域幅の数値の意味を与え、単一の英数字の単語であり、ここで、<帯域幅値>のデフォルトの単位は秒あたりのキロビットです。この属性は、セッションまたはメディアが使用する提案の帯域幅を指定します。
A typical use is with the modifier "AS" (for Application Specific Maximum) which may be used to specify the total bandwidth for a single media stream from one site (source).
典型的な使用は、一つのサイト（ソース）から単一のメディアストリームの総帯域幅を指定するために使用されてもよい（特定用途最大の場合）、「AS」という修飾語です。
This memo defines two additional bandwidth modifiers:
このメモは、2つの追加の帯域幅修飾子を定義しています。
b=RS:<bandwidth-value>
B = RS：<帯域幅値>
b=RR:<bandwidth-value>
B = RR：<帯域幅値>
where "RS" indicates the RTCP bandwidth allocated to active data senders (as defined by the RTP spec) and "RR" indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e., receivers). The exact behavior induced by specifying these bandwidth modifiers depends upon the algorithm used to calculate the RTCP reporting interval. Different algorithms may be specified by different RTP profiles.
ここで、「RS」は、アクティブなデータ送信者（RTP仕様によって定義される）及び「RR」に割り当てられたRTCP帯域幅がRTPセッションの他の参加者（すなわち、受信機）に割り当てられたRTCP帯域幅を示して示しています。これらの帯域幅修飾子を指定することにより誘発される正確な動作はRTCPのレポート間隔を計算するのに使用されるアルゴリズムに依存します。異なるアルゴリズムは異なるRTPプロファイルで指定することができます。
For the RTP A/V Profile [2], which specifies that the default RTCP interval algorithm defined in the RTP spec [1] is to be used, at least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data senders. If the proportion of senders to total participants is less than or equal to RS/(RS+RR), each sender gets RS divided by the number of senders. When the proportion of senders is greater than RS/(RS+RR), the senders get their proportion of the sum of these parameters, which means that a sender and a non-sender each get the same allocation. Therefore, it is not possible to constrain the data senders to use less RTCP bandwidth than is allowed for non-senders. A few special cases are worth noting:
[1] RTP仕様で定義されたデフォルトRTCP間隔アルゴリズムは、少なくともRTCP帯域幅のRS /（RS + RR）は、アクティブ・データに特化され、使用されることを指定RTP A / Vプロファイル[2]用送信者。総参加者に送信者の割合がより少ない又はRS /（RS + RR）に等しい場合、各送信者は送信者の数で割ったRSを得ます。送信者の割合は、RS /（RS + RR）よりも大きい場合、送信者は、送信者と非送信者それぞれが同じ割当を得ることを意味し、これらのパラメータの和、のそれらの割合を得ます。したがって、非送信者に許可されているよりも少ないRTCP帯域幅を使用するために、データの送信者を制約することはできません。いくつかの特殊なケースは注目に値します。
o If RR is zero, then the proportion of participants that are senders can never be greater than RS/(RS+RR), and therefore non-senders never get any RTCP bandwidth independent of the number of senders.
RRがゼロの場合、O、その後、送信者です参加者の割合は、RS /（RS + RR）より大きくなることはありませんので、非送信者は送信者の数の任意のRTCP帯域幅の独立を取得することはありません。
o Setting RS to zero does not mean that data senders are not allowed to send RTCP packets, it only means that they are treated the same as non-senders. The proportion of senders (if there are any) would always be greater than RS/(RS+RR) if RR is non-zero.
ゼロにRSを設定すると、そのデータの送信者がRTCPパケットを送信することが許可されていないという意味ではありませんO、それだけでは、非送信者と同じように扱われることを意味します。 RRが非ゼロである場合に送信者の割合（いずれかがある場合）は常にRS /（RS + RR）よりも大きくなるであろう。
o If RS and RR are both zero, it would be unwise to attempt calculation of the fraction RS/(RS+RR).
RS及びRRの両方がゼロである場合、Oは、フラクションRS /（RS + RR）の計算を試みるために賢明であろう。
The bandwidth allocation specified by the RS and RR modifiers applies to the total bandwidth consumed by all RTCP packet types, including SR, RR, SDES, BYE, APP and any new types defined in the future. The <bandwidth-value> for these modifiers is in units of bits per second with an integer value.
RSとRR修飾子で指定された帯域幅の割り当ては、SR、RR、SDES、BYE、APPおよび将来的に定義された任意の新しいタイプを含むすべてのRTCPパケットタイプ、によって消費される帯域幅の合計に適用されます。 <帯域幅値>これらの改質のための整数値を持つビット毎秒単位です。
NOTE: This specification was in conflict with the initial SDP spec in RFC 2327 which prescribes that the <bandwidth-value> for all bandwidth modifiers should be an integer number of kilobits per second. This discrepancy was forced by the fact that the desired RTCP bandwidth setting may be less than 1 kb/s.
注：この仕様は、すべての帯域幅の改質のための<帯域幅 - 値>は毎秒キロビットの整数でなければならないことを規定するRFC 2327で初期SDP仕様と矛盾しました。この不一致は、所望のRTCP帯域幅の設定が1未満KB /秒とすることができるという事実によって余儀なくされました。
At the 44th IETF meeting in Minneapolis, two solutions were considered: allow fractional values, or specify that the units for these particular modifiers would be in bits per second. The second choice was preferred so that the syntax would not be changed. The SDP spec is being modified [4] to advance to Draft Standard, and will allow this change in semantics.
ミネアポリスの第44回IETFミーティングで、二つの溶液を考慮した：小数値を許可する、またはこれらの特定の修飾子の単位は秒当たりのビットであろうことを指定します。構文は変更されないように、第2の選択肢が好まれました。 SDP仕様[4]標準案に進むように改変され、およびセマンティクスの変化を可能にします。
If either or both of the RS and RR bandwidth specifiers are omitted, the default values for these parameters are as specified in the RTP profile in use for the session in question. For the Audio/Video Profile, RFC 3551 [2], the defaults follow the recommendations of the RTP spec:
RSとRR帯域幅指定子のいずれかまたは両方が省略されている場合、これらのパラメータのデフォルト値は、問題のセッションで使用されているRTPプロファイルに指定されているよう。オーディオ/ビデオのプロファイルについては、RFC 3551 [2]、デフォルトはRTP仕様の勧告に従ってください。
o The total RTCP bandwidth is 5% of the session bandwidth. If one of these RTCP bandwidth specifiers is omitted, its value is 5% minus the value of the other one, but not less than zero. If both are omitted, the sender and receiver RTCP bandwidths are 1.25% and 3.75% of the session bandwidth, respectively.
Oの合計RTCP帯域幅は、セッション帯域幅の5％です。これらのRTCP帯域幅指定子のいずれかが省略された場合、その値は5％のマイナス、他のいずれかの値ではなく、ゼロ未満です。両方が省略された場合、送信側と受信側RTCP帯域幅は、それぞれ1.25％及びセッション帯域幅3.75％です。
o At least RS/(RS+RR) of of the RTCP bandwidth is dedicated to active data senders. When the proportion of senders is greater than RS/(RS+RR) of the participants, the senders get their proportion of the sum of these parameters.
O RTCP帯域幅のうちの少なくともRS /（RS + RR）は、アクティブなデータ送信者専用です。送信者の割合は、参加者のRS /（RS + RR）よりも大きい場合、送信者は、これらのパラメータの和の彼らの割合を取得します。
This memo does not impose limits on the values that may be specified with the RR and RS modifiers, other than that they must be non-negative. However, the RTP specification and the appropriate RTP profile may specify limits.
このメモは、彼らが非負でなければならないこと以外に、RRおよびRS修飾子を指定することができる値に制限を課すことはありません。しかし、RTP仕様と適切なRTPプロファイルが制限を指定することができます。
An SDP description consists of a session-level description (details that apply to the whole session and all media streams) and zero or more media-level descriptions (details that apply only to a single media stream). Bandwidth specifiers may be present either at the session level to specify the total bandwidth shared by all media, or in the media sections to specify the bandwidth allocated to each medium, or both. This is true for the two RTCP bandwidth modifiers defined here as well.
SDP記述は、セッションレベル記述（セッション全体に適用される詳細およびすべてのメディアストリーム）と、ゼロ以上のメディアレベル記述（単一のメディアストリームにのみ適用の詳細）から成ります。帯域幅指定子は、すべてのメディアで共有総帯域幅を指定するセッション・レベルで、または各メディア、またはその両方に割り当てられる帯域幅を指定するメディア・セクションのいずれかで存在してもよいです。これは、ここにも定義された2つのRTCP帯域幅修飾子についても同様です。
Since the bandwidth allocated to RTCP is a fraction of the session bandwidth when not specified explicitly using the modifiers defined here, there is an interaction between the session bandwidth and RTCP bandwidth specifiers at the session and media levels of the SDP description. The precedence of these specifiers is as follows, with (1) being the highest precedence:
RTCPに割り当てられる帯域幅は、ここで明示的に定義された修飾子を使用して指定されていないセッションの帯域幅の一部であるので、SDP記述のセッションとメディアレベルでのセッション帯域幅及びRTCP帯域幅の指定子との間の相互作用があります。これらの指定子の優先順位は、（1）最も高い優先順位であると、以下の通りであります：
1) Explicit RR or RS specifier at media level
メディアレベル1）明示的なRRまたはRS指定子
2) Explicit RR or RS specifier at session level
セッションレベルでの2）明示的なRRまたはRS指定子
3) Default based on session bandwidth specifier at media level
3）デフォルトのメディアレベルでのセッション帯域幅指定子に基づいて
4) Default based on session bandwidth specifier at session level
4）デフォルトセッション・レベルでセッション帯域幅指定子に基づいて
In particular, the relationship of (2) and (3) means that if the RR bandwidth is specified as zero at the session level, that turns off RTCP transmission for non-data-senders in all media.
具体的には、の関係は、（2）及び（3）RR帯域幅はセッション・レベルでゼロとして指定されている場合、それはすべてのメディアに非データ送信者のためのRTCP送信をオフにすることを意味します。
An example SDP description is:
例えばSDP記述があります。
v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 b=AS:64 b=RS:800 b=RR:2400 m=video 51372 RTP/AVP 31 b=AS:256 b=RS:800 b=RR:2400
V = 0 0 = IP4 126.16.64.4 S = SDPセミナーでmhandley 2890844526 2890842807私はIP4 224.2.17.12/127 T = 2873397496 2873404696メートル=オーディオ49170 RTP / AVP 0 B = INセッション記述プロトコルCにセミナー= = ：64 B = RS：800 B = RR：2400メートル=ビデオ51372 RTP / AVP 31 B = AS：256 B = RS：800 B = RR：2400
In this example, the explicit RTCP bandwidths for the audio medium are equal to the defaults and so could be omitted. However, for the video medium, the RTCP bandwidths have been set according to a data bandwidth of 64 kb/s even though the maximum data bandwidth is specified as 256 kb/s. This is based on the assumption that the video data bandwidth will automatically adapt to a lower value based on network conditions.
この例では、オーディオ媒体のための明示的なRTCP帯域幅は、デフォルト値に等しいので、省略することができています。しかしながら、ビデオ媒体に対して、RTCP帯域幅が64キロバイトのデータ帯域幅に応じて設定されている/最大データ帯域幅が256 KB /秒として指定されていてもよ。これは、ビデオデータ帯域幅が自動的にネットワークの状態に基づいて、より低い値に適応するという仮定に基づいています。
RFC 2327 [3] requires that new bandwidth modifiers be registered with IANA by reference to a standards-track RFC specifying the semantics of the bandwidth modifier precisely, indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice.
RFC 2327 [3]は、それが使用されなければならない、そしてなぜ既存の登録帯域幅指定子が十分でないときを示す、新しい帯域幅修飾子を正確に帯域幅修飾子のセマンティクスを指定する標準トラックRFCを参照することにより、IANAに登録されている必要があります。
This document is intended to satisfy those requirements.
この文書は、これらの要件を満たすことを目的としています。
In the "bwtype" table of the Session Description Protocol (SDP) Parameters registry, the following two new bandwidth modifier names have been registered:
セッション記述プロトコル（SDP）パラメータレジストリの「bwtype」テーブルでは、次の2人の新しい帯域幅修飾名が登録されています：
RS RR
RS RR
This memo defines bandwidth modifier keywords as an extension to SDP, so the security considerations listed in the SDP specification apply to session descriptions containing these modifiers as with any other.
このメモはSDPへの拡張として、帯域幅修飾子のキーワードを定義し、そのSDP仕様に記載されているセキュリティ上の考慮事項は、他と同じようにこれらの修飾子を含むセッション記述に適用されます。
The bandwidth value supplied with one of these modifiers could be unreasonably large and cause the application to send RTCP packets at an excessive rate, resulting in a denial of service. This is similar to the risk that an unreasonable bandwidth could be specified for the media data, though encoders generally have a limited bandwidth range. Applications should apply validity checks to all parameters received in an SDP description, particularly one which is not authenticated. This memo cannot specify limits because they are dependent on the RTP profile and application.
これらの改質剤のいずれかで供給される帯域幅の値が不当に大きくなると、サービスの拒否をもたらす、過剰な速度でRTCPパケットを送信するアプリケーションを引き起こす可能性があります。エンコーダは、一般的に限られた帯域幅の範囲を持っているが、これは、不合理な帯域幅は、メディアデータに指定することができ、リスクに似ています。アプリケーションは、SDP記述に受信したすべてのパラメータに認証されていない、特にいずれかの妥当性チェックを適用すべきです。彼らはRTPプロファイルやアプリケーションに依存しているため、このメモは制限を指定することはできません。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル、" RFC 3550、2003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[2] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 3551、2003年7月。
[3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[3]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", Work in Progress.
[4]ハンドレー、M.、ヤコブソン、V.およびC.パーキンス、 "SDP：セッション記述プロトコル"、ProgressのWork。
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL. Casnerパケットデザイン3400ヒルビュー・アベニュー、3パロアルト、CA 94304米国の構築
Phone: +1 650 739-1843 EMail: casner@acm.org
電話：+1 650 739-1843 Eメール：casner@acm.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。