RFC3890 日本語訳
3890 A Transport Independent Bandwidth Modifier for the SessionDescription Protocol (SDP). M. Westerlund. September 2004. (Format: TXT=49894 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Westerlund Request for Comments: 3890 Ericsson Category: Standards Track September 2004
Westerlundがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3890年のエリクソンカテゴリ: 標準化過程2004年9月
A Transport Independent Bandwidth Modifier
for the Session Description Protocol (SDP)
セッション記述プロトコルのための輸送の独立している帯域幅修飾語(SDP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントは輸送オーバーヘッドを含んでいないSession記述プロトコル(SDP)輸送無党派Application Specific Maximum(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層に必要である帯域幅を含んでいます。 Session Announcementプロトコル(SAP)、Session Initiationプロトコル(SIP)、およびレアル-時間Streamingプロトコル(RTSP)のようなプロトコルがあるSDPを使用するとき、かかわったホストに異なった輸送オーバーヘッドがあるとき、例えば、異なったIPバージョンのために、どんな下層帯域幅が含まれているかに関する解釈は明確ではありません。
Westerlund Standards Track [Page 1] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 帯域幅属性。 . . . . . . . . . . . . . . . . 3 1.1.1. コンファレンス合計. . . . . . . . . . . . . . . . 3 1.1.2。 アプリケーションの特定の最大. . . . . . . . . . 3 1.1.3。 RTCPは帯域幅を報告します。 . . . . . . . . . . . . . 4 1.2. IPv6とIPv4。 . . . . . . . . . . . . . . . . . . . . . 4 1.3. 一層のMechanismsそのChange Bandwidth Utilization。 . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. IPsec。 . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. ヘッダー圧縮. . . . . . . . . . . . . . . 5 2。 定義。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. 用語集. . . . . . . . . . . . . . . . . . . . . . . . 6 2.2。 用語。 . . . . . . . . . . . . . . . . . . . . . . 6 3. 帯域幅シグナリング問題. . . . . . . . . . . . . . . 6 3.1。 どんなIPバージョンがUsedですか? . . . . . . . . . . . . . . . . 6 3.2. 他のメカニズムをアカウント. . . . . . . . . . 7 3.3に連れていきます。 帯域幅値を変換します。 . . . . . . . . . . . . . . 8 3.4. RTCP問題… 8 3.5。 今後の開発. . . . . . . . . . . . . . . . . . . 9 3.6。 問題結論. . . . . . . . . . . . . . . . . . . 9 4。 問題範囲。 . . . . . . . . . . . . . . . . . . . . . . . . 10 5. 要件. . . . . . . . . . . . . . . . . . . . . . . . . 10 6。 ソリューション. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1。 序論. . . . . . . . . . . . . . . . . . . . . . 11 6.2。 TIAS帯域幅修飾語。 . . . . . . . . . . . . . . 11 6.2.1. 用法。 . . . . . . . . . . . . . . . . . . . . . 11 6.2.2. 定義. . . . . . . . . . . . . . . . . . . 12 6.2.3。 用法は統治されます。 . . . . . . . . . . . . . . . . . . 13 6.3. パケットレートパラメタ。 . . . . . . . . . . . . . . . . . 13 6.4. 輸送依存する値. . . . . . . . 14 6.5に変えます。 RTCP帯域幅を引き出します。 . . . . . . . . . . . . . . . . 15 6.5.1. このソリューションに関する動機。 . . . . . . . . . . 15 6.6. ABNF定義. . . . . . . . . . . . . . . . . . . . 16 6.7。 例。 . . . . . . . . . . . . . . . . . . . . . . . . 16 7. 相互作用. . . . . . . . . . . . . . . . . . . . . 17 7.1について議定書の中で述べてください。 RTSP. . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2。 ちびちび飲んでください。 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. 徐々に破壊します。 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 18 9. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 18 10. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 19 11. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1。 引用規格. . . . . . . . . . . . . . . . . . 19 11.2。 有益な参照. . . . . . . . . . . . . . . . . 19 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 21 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 22
Westerlund Standards Track [Page 2] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[2ページ]。
1. Introduction
1. 序論
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.
今日、Session記述プロトコル(SDP)[1]はいくつかのタイプのアプリケーションで使用されます。 原出願は、Session Announcementプロトコル(SAP)[5]で発表されたマルチキャストセッションのためのセッション情報と構成です。 また、SDPは申し出答えモデル[7]を使用するのによるSession Initiationプロトコル(SIP)[6]のためのメディア交渉で重大なコンポーネントです。 また、Streamingプロトコル(RTSP)[8]がSDPのクライアントへのどんなメディアであるかと宣言する使用をして、コーデックがマルチメディアプレゼンテーションを包括するレアル-時。
1.1. The Bandwidth Attribute
1.1. 帯域幅属性
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つの定義された修飾語があります。
1.1.1. Conference Total
1.1.1. コンファレンス合計
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].
コンファレンスTotalは、修飾語「ct」を与えることによって、示されます。 コンファレンス合計は会議の話し合いが使用する最大の帯域幅を与えます。 目的はこのセッションがRFC2327[1]で定義された他のセッションと共存できるかどうか決めることです。
1.1.2. Application Specific Maximum
1.1.2. アプリケーションの特定の最大
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
Application Specificの最大の帯域幅は修飾語“AS"によって示されます。 この属性の解釈はアプリケーションの最大の帯域幅の概念に依存しています。 RTPアプリケーションのために、この属性は定義されるようにRTPセッション帯域幅です。
Westerlund Standards Track [Page 3] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[3ページ]。
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].
RFC3550[4]で。 セッション帯域幅はRTPデータ通信量が消費する帯域幅を含んでいます、下層を含んでいて、IP層まで。 したがって、多くの場合、帯域幅がRTPペイロードの上計算されている、RTPヘッダー(UDP、およびIP)はRFCで2327[1]を定義しました。
1.1.3. RTCP Report Bandwidth
1.1.3. RTCPレポート帯域幅
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.
RFC3556[9]では、2つの帯域幅修飾語が定義されます。 これらの修飾語「RS」と"RR"は、他の関係者(受信機)でそれぞれRTCPレポートのために活発なデータ送付者とRTCPレポートによって割り当てられる帯域幅の量を定義します。
1.2. IPv6 and IPv4
1.2. IPv6とIPv4
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バージョンを共有しなければなりません。 通常、デュアルスタックノードを配布することによって、これをします。 例えばホストだけがIPv6だけと伝えることができないIPv4、ホスト。
- 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.
- プロトコルバージョンを共有しないノードのコミュニケーションが必要であるなら、翻訳かproxyingメカニズムの使用が必要でしょう。 仕事は、このためにそのようなメカニズムを指定するために進行中です。
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ------------- | |
| ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- |
------------------ ----------------------
------------------ ---------------------- | IPv4ドメイン| | IPv6ドメイン| | | ------------- | | | ---------- |-|翻訳者|-| ---------- | | |サーバA| | | または、プロキシ| | |クライアントB| | | ---------- | ------------- | ---------- | ------------------ ----------------------
Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
図1。 翻訳かIPv6とIPv4アドレスの間でproxyingすること。
- 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は見ます。 基本的に、ペイロードとしてIPv4パケットでそれぞれのIPv6ドメインの縁のトンネリングエンドポイントの間にIPv6パケットを送ります。 IPv4ドメインに関して必要である帯域幅はIPv6ドメインと異なるでしょう。 しかしながら、トンネリングがアプリケーションエンドポイントによって通常実行されないとき、通常、このシナリオを考慮に入れることができません。
Westerlund Standards Track [Page 4] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[4ページ]。
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
--------------- --------------- --------------- | IPv6ドメイン| | IPv4ドメイン| | IPv6ドメイン| | | |-------------| | | | ---------- |--||トンネル||--| ---------- | | |サーバA| | |-------------| | |クライアント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バージョンに必要であるビット伝送速度が異なっていることを意味します。 違いの意味はそれぞれのパケットのパケットレートとペイロードサイズに依存します。
1.3. Further Mechanisms that Change the Bandwidth Utilization
1.3. 一層のMechanismsそのChange Bandwidth Utilization
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.
また、層でメディア輸送の下でオーバーヘッドを変えるかもしれない他の多くのメカニズムが存在しています。 私たちは簡潔にこれらのいくつかをここにカバーするつもりです。
1.3.1. IPsec
1.3.1. IPsec
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.
メディアストリームのIP Authentication Header(AH)[20]を使用しながらIP Encapsulating Security有効搭載量(超能力)[21]か保全保護の応用で秘密性を提供するのにエンドポイントの間でIPsec[19]を使用できます。 超能力と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と超能力ヘッダーはパケットサイズをかなり増強するでしょう。
1.3.2. Header Compression
1.3.2. ヘッダー圧縮
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.
リンクの上に製造間接費を変更する別のメカニズムはヘッダー圧縮です。 ヘッダー圧縮はほとんどのネットワーク・プロトコルヘッダーがパケットストリームの中にそれらの分野に静的であるか予測できる値を持っているという事実を使用します。 通常、すなわち、ホップ基礎あたりのa、単一のリンクの上に圧縮するだけです。 ヘッダーに圧縮する正常な理由はリンクが帯域幅を公正に制限して、スループットの重要な利得が獲得されるということです。
Westerlund Standards Track [Page 5] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[5ページ]。
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ヘッダーだけを圧縮するために、RFC2507[10]があります。 IP/UDP/RTPヘッダーと共にパケットを圧縮するのにおいて、CRTP[11]は同時に、作成されました。 より最近、Robust Header Compression(ROHC)ワーキンググループはプロトコルのある組み合わせを圧縮するためのフレームワークとプロフィール[12]を開発しています、IP/UDP、およびIP/UDP/RTPのように。
2. Definitions
2. 定義
2.1. Glossary
2.1. 用語集
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--アプリケーションLevelゲートウェイビーピーエス--bps。 RTSP--全くStreamingプロトコルを調節してください、そして、[8]を見てください。 SDP--セッション記述プロトコル、[1]を見てください。 SAP--セッションAnnouncementプロトコル、[5]を見てください。 SIP--セッションInitiationプロトコル、[6]を見てください。 TIAS--無党派Application Specific最大、帯域幅修飾語を輸送してください。
2.2. Terminology
2.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
3. The Bandwidth Signaling Problems
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を使用したがっているとき、いくつかの問題が帯域幅値での下層の包含のために明白になります。
3.1. What IP Version is Used
3.1. UsedはどんなIPバージョンですか?
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=」を使用することで1つが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
RTSPによって輸送されたSDPの場合では、これはそれほど明確になりさえしません。 ユニキャストオンデマンドストリーミングセッションのための正常な用法は接続データ・アドレスを空アドレスに設定することです。 この空アドレスはそうします。
Westerlund Standards Track [Page 6] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[6ページ]。
have an address type, which could be used as an indication. However, this is also not clarified anywhere.
アドレスタイプをあってください。(指示としてタイプを使用できます)。 しかしながら、また、これは何処にもはっきりさせられません。
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がAからSDPをRTSPの上に受けるとき、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は変わりがありません、そして、タイプIPv4には「c=」空アドレスがあります。 帯域幅値は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はApplication Levelゲートウェイ(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では、すべてが正しく働いています。 しかしながら、本件は非常にまれになるでしょう。 ものがパケットレートに関する詳細なしで帯域幅値を変換しようとするなら、重要な誤りは値に取り入れられるかもしれません。
3.2. Taking Other Mechanisms into Account
3.2. 他のメカニズムを考慮に入れます。
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はヘッダー圧縮とトンネルのような下層ヘッダーサイズを変える多くの理由をリストアップします。 これらのメカニズムのために、それらを考慮に入れる異なった可能性は存在しています。
Westerlund Standards Track [Page 7] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[7ページ]。
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]のために、拡大、データ送付者がデータフローの圧縮性に関するネットワーク・ノードを知らせることができるRFC3006[16]は存在しています。 どんな精度か圧縮要素とパケットレートかサイズでもこれができるのが必要です、RFC3006が提供するとき。
3.3. Converting Bandwidth Values
3.3. 帯域幅値を変換します。
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のための新しい帯域幅値は20バイト「IPv4帯域幅」+「パケットレート」*です、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]はそれが推薦にすぎないということです。(送付者はそれを無視するかもしれません)。 より良いパラメタが必要です。
3.4. RTCP Problems
3.4. RTCP問題
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パケットのためにあるために望んでいる中で最も大きいもの
Westerlund Standards Track [Page 8] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[8ページ]。
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帯域幅が5%のRTP帯域幅であるときにだけ、それは総セッション帯域幅の最大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帯域幅を引き出すための簡単なアルゴリズムだけがこの仕様に基づき定義されます。
3.5. Future Development
3.5. 今後の開発
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にあります。 このプロトコルはデータグラムCongestion Controlプロトコル(DCCP)と呼ばれます。 それには、今日リアルタイムのメディアにたいてい使用されているプロトコルであるUDPと異なったヘッダーサイズが最もたぶんあるでしょう。 これはさらに可能な輸送組み合わせをもたらします。 1つに異なったプロトコルを使用する可能性があるなら、これは問題になるかもしれません。プロトコルは実際のプロトコルSETUPの前で決定しないでしょう。 その結果、この値が可能にならないとあらかじめ見込みます(輸送の独立している帯域幅修飾語が必要であるさらなる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帯域幅修飾語を指定するさらなる仕事を必要とするかもしれません。 例えば、分とアプリケーションがすべて、またはできるメディアコーデックだけのために生産できる可能なレートを列挙して、あるビット伝送速度を生産する最大メディア帯域幅。 しかしながら、今後の研究と現在のソリューションの範囲の外にこれはあります。
3.6. Problem Conclusion
3.6. 問題結論
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帯域幅修飾語の短所はまた、下層に必要である帯域幅を含んでいるということです。 どの下層を決定するかが難しい多くの場合にはそれがありました、そして、それらのバージョンは計算に含まれていました、特に翻訳か異なったドメインの間でproxyingすることの面前で。 これは、受信機が、与えられた帯域幅が、使用される実際の下層に基づいて変換される必要であるかどうか決定するのを防ぎます。
Westerlund Standards Track [Page 9] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[9ページ]。
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.
第二に、使用される最大のパケットレートの明白な決断を受信機に与える属性は存在していません。 オーバーヘッドの違いが知られているなら、この値がどんな帯域幅値の正確な変換にも必要です。
4. Problem Scope
4. 問題範囲
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.
この仕様はNATsか他のmiddleboxesを検出するという問題を解決しようとしません。
5. Requirements
5. 要件
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.
- 帯域幅は方法による当然のことが輸送オーバーヘッドのすべての可能な組み合わせのためにそれについて計算できるようにものであったならSHALLを評価します。
Westerlund Standards Track [Page 10] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[10ページ]。
6. Solution
6. ソリューション
6.1. Introduction
6.1. 序論
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).
本章は本書ではApplication Specific(AS)帯域幅修飾語のために概説された問題によってソリューションについて説明します、その結果、アプリケーションか、RTPセッションのデータとRTCPトラフィックのために必要なビット伝送速度の派生を可能にします。 ソリューションは新しいTransport無党派Application Specific(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.
コネチカットを、セッションレベル修飾語であり、容易に対処できません。 異なったオーバーヘッドで問題と取り組むために、コネチカット値が手頃な最悪の場合オーバーヘッドを使用することで計算されるのは、RECOMMENDEDです。 どう手頃な最悪の場合オーバーヘッドについて計算するかに関する例は以下の通りです。 最も大きいトランスポート・プロトコルのオーバーヘッドを取ってください、そして、(可変であるなら平均のサイズを使用して)使用のために予想される中で最も大きい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]は、定義されるように使用されて、輸送オーバーヘッドを含むでしょう。 ホストの間の小さい不公平は許容できると考えられます。
6.2. The TIAS Bandwidth Modifier
6.2. TIAS帯域幅修飾語
6.2.1. Usage
6.2.1. 用法
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
- コミュニケーションビット伝送速度がストリームに必要です。 ストリームが必要とする最大のコミュニケーションビット伝送速度を測定するのに"maxprate"に伴う「TIAS」値を使用できます。 セッションを使用して、値を平らにしてください。さもないと、セッションのときにストリームからすべての最大のビット伝送速度を一緒に加えることによって、受信機は、コミュニケーションリソースがストリームを扱うために十分であるかどうか決定できます。 for
Westerlund Standards Track [Page 11] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[11ページ]。
example, a modem user can determine if the session fits his
modem's capabilities and the established connection.
例、モデムユーザは、セッションが彼のモデムの能力と確立した接続に合うかどうかと決心できます。
- 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セッション帯域幅になるでしょう。 また、暗黙の配分を使用するとき、使用へのRTCP帯域幅を決定するのにTIAS値を使用できます。 RTP[4]は、まして明らかに述べられて、追加しているRTPセッション帯域幅の5%と等しい帯域幅がRTCPによって使用されるだろうと指定します。 修飾語が[9]で定義したRRとRSを使用することによって、明らかにRTCP帯域幅を割り当てることができます。
6.2.2. Definition
6.2.2. 定義
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.
Transport無党派Application Specific Maximum(TIAS)帯域幅修飾語には、bpsにおける整数ビット伝送速度価値があります。 断片的な帯域幅はいつもSHALLを評価します。次の整数まで一周してください。 帯域幅値はTCPやUDPのようなIPか他のトランスポート層を数えないでアプリケーション(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に関しては、輸送されたメディアストリームであり、RTP「セッション帯域幅」を引き出すのにSDPメディアレベルにおけるTIASを使用できます、[4]のセクション6.2で定義されて。 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.
RTPヘッダー拡張子、すなわち、[4] SHALLで定義されるRTPペイロードだけが下層(IP/UDP)とRTPヘッダーを含むRTPヘッダーを除きながらビット伝送速度の計算に使用されて、CSRCは記載します、そして、他のRTPは特定の分野の輪郭を描きます。 RTPペイロードがペイロード形式ヘッダーとデータの両方を含んでいることに注意してください。 これは、RTPのベースのメディア輸送、非RTP輸送、および保存されたメディアに同じ値を使用するために1つを許容するかもしれません。
Westerlund Standards Track [Page 12] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[12ページ]。
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: RFC2327[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セッション帯域幅かRRとRS修飾語[9]によって指定されるように5%どちらかです。 TIASを使用するとき、どうRTCPビット伝送速度を引き出すかに関する仕様は第6.5章に提示されます。
6.2.3. Usage Rules
6.2.3. 用法規則
"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.
主として、SDPメディアレベルに「TIAS」が使用されることを意図します。 「TIAS」帯域幅属性はSDPのセッションレベルで存在しているかもしれません、すべてのメディアストリームが同じ輸送を使用するなら。 レベルがすべてのメディアストリームのために評価するメディアの合計がすべてのストリームの実際の最大の帯域幅の必要性より大きく、それがSHOULDである場合では、セッションレベルで含められてください。 しかしながら、セッションのときに存在しているならそれを平らにしてください、SHOULD、メディアレベルではも、存在してください。 同じくらいがプロトコルを輸送しないなら、すべてのメディアストリームにおいて、セッションレベルにおけるプレゼントは使用されています。「TIAS」SHALL NOTはプロトコルの同じ組み合わせが使用されている限り、同じ輸送が使用されているということであり、好きです。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」を使用するとき、後方に「TIAS」を実装しないSDPのアプリケーションとの互換性を考慮するために、また、“AS"修飾語を含んでいるのはお勧めです。 下層オーバーヘッドを含む価値と、その問題があっても存在はなにもより良いです。 しかしながら、両方が存在しているとき、TIAS SHOULDを実装する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を使用するときには、できれば、SHALLについて次に定義されて、計算するために、対応するSDPレベルで含められてください。
6.3. Packet Rate Parameter
6.3. パケットレートパラメタ
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: <パケットレート>。 ABNF定義に関してセクション6.6を見てください。
Westerlund Standards Track [Page 13] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[13ページ]。
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秒あたりのパケットのストリームの最大のパケットレートのための浮動小数点の値です。 パケットの数が可変であるなら、与えられた値のSHALLはアプリケーションがライブストリームの場合の保存された要求次第のストリームのために生産できる最大であり、生産しました。 パケットの数が1の中で2番目の窓を送ったと言い足すことによって、パケットレートは計算されます。 窓が全体のメディアストリームの上を滑るとき、maxprateは最も大きい生産物価値です。 すなわち、計算されていて、これがそうすることができないケース、ライブストリーム、コーデックが与えられた構成と内容SHALLのために生産できる最大のパケットレートの見積価格では、使用されてください。
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"属性はセッションレベルで存在しているはずがありません。 メディアストリームが同じ輸送を使用するなら、属性は存在しているかもしれません。 属性はセッションレベルで存在しています、また、それがSHOULDです。メディアレベルでは、すべてのメディアストリームには、存在してください。
"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.
含まれていて、パケットレートを引き出すことができて、TIASが含まれているところでSHALLはすべての輸送のために"maxprateする"です。 例えば、あなたが最大パケットレート(実際の、または、およその)を引き出すことができるIP/UDP/RTPのようなTIASと輸送を使用して、その時が"maxprate"であるというSHALLであるなら、含められてください。 しかしながら、(a) 輸送のパケット速度を引き出すことができないか、または次に、(b) TIASが含まれていないなら、"maxprate"は、含まれるのに必要ではありません。
6.4. Converting to Transport-Dependent Values
6.4. 輸送依存する値に変えます。
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-サイズ)のヘッダーのサイズについて計算するか決定してください。 コネはサイズ、平均のサイズSHALLを可変ヘッダーにケースに入れます。使用されます。 RTPによって輸送されたメディアのために、SHALLの低級層はヘッダー拡大、使用されていて、CSRCが記載するか、そして、およびどんなプロフィール特有の拡大でもRTPヘッダーを含んでいます。
Westerlund Standards Track [Page 14] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[14ページ]。
2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
2. SDPから最大のパケットレートを検索してください(=maxprateをベラベラしゃべってください)。
3. Calculate the transport overhead by multiplying the header sizes
by the packet rate (t-over = h-size * prate).
3. パケットレート(オーバーtはh-サイズ*無駄口と等しい)にヘッダーサイズを掛けることによって、輸送オーバーヘッドについて計算してください。
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"を使用することで実行されるとき、ビット伝送速度値はメディアストリームが計算で想定された輸送の上で使用するかもしれない絶対最大値になるでしょう。
6.5. Deriving RTCP Bandwidth
6.5. RTCP帯域幅を引き出します。
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.
まず最初に、輸送依存するRTPセッションビット伝送速度は計算されます、セクション6.4によると、計算が完了しているところでエンドポイントに使用される実際のトランスポート層を使用して。 RTCPビット伝送速度は、次に、RTPセッション帯域幅に基づいていつものように派生していて、すなわち、通常、計算された価値の5%と等しいです。
6.5.1. Motivation for this Solution
6.5.1. このソリューションに関する動機
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.
全く同じRTCPビット伝送速度価値をIPv4とIPv6ホストの両方に与えると、より高いRTCP送付レートを持っているIPv4ホストはもたらされるでしょう。 送付レートは与えられた時間間隔の間に送られたRTCPパケットの数を表します。 RTP仕様[4]に基づき定義された規則に従って、RTCPの発信は制限されます。 100バイトのRTCPパケット(UDP/IPv4を含んでいる)に関しては、IPv4送付者には、およそ20%より高い送付レートがあります。 このレートは、より大きいRTCPパケットと共に下がります。 例えば、300バイトのパケットは7%より高い送付レートをIPv4ホストに与えるだけでしょう。
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比を与えるトラフィックパラメタがあると課題が固定されているのと同じ振舞いを与えます。 TIAS/maxprate比がおよそ40のバイト/パケットであるときに、100バイトのRTCPパケットを考えて、2人のホストが公正になるでしょう。 5つのバイト/パケットのTIAS/maxprate比において、IPv6ホストはおよそ15-20%より多くのRTCPパケットを送ることができるでしょう。
Westerlund Standards Track [Page 15] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[15ページ]。
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%ほど大きくならないでしょう。
6.6. ABNF Definitions
6.6. ABNF定義
This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier and the packet rate attribute.
本章はRFC2234からABNFで[2] 帯域幅修飾語とパケットレート属性を定義します。
The bandwidth modifier:
帯域幅修飾語:
TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
「TIAS帯域幅クールである、= 「b」は「」 「TIAS」と等し」」。 帯域幅価値のCRLF
bandwidth-value = 1*DIGIT
帯域幅値は1*DIGITと等しいです。
The maximum packet rate attribute:
最大のパケットレート属性:
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
「pがクールであると評定する最大=“a"は「」 "maxprate"と等しいです」」 パケットレートCRLF
packet-rate = 1*DIGIT ["." 1*DIGIT]
パケットレート=1*DIGIT[「. 」 1*ケタ、]
6.7. Example
6.7. 例
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
IN IP4 0.0.0.0使用cでのTIASとmaxprateに関する例_SERVER3413526809 0IN IP4 server.example.com s=v=0o=例=b=AS: 60b=TIAS: 50780 =コントロールあたりt=0 0: rtsp://server.example.com/media.3gp=範囲: npt=0-150.0 a=maxprate: 28.0m=オーディオの0RTP/AVP97b=AS: 12b=TIAS: 8480a=maxprate: 10.0 a=rtpmap: 97 AMR/8000a=fmtp: 97 八重奏で並んでください。 =コントロール: rtsp://server.example.com/media.3gp/trackID=1mはビデオ0RTP/AVP99と等しいです。
Westerlund Standards Track [Page 16] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[16ページ]。
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
b=AS: 48b=TIAS: 42300 a=maxprate: 18.0 a=rtpmap: 99 MP4V-ES/90000a=fmtp: 99 プロフィール平らなイドの=8。 コンフィグ=000001B008000001B509000001010000012000884006682C2090A21F a=コントロール: 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-4Videoエンコーダでコード化されている状態でコード化された1つのオーディオストリーム)があります。 AMRは一定のレートメディアストリームを生産するのにここで使用されて、1秒あたり10のパケットをもたらすpacketizationを使用します。 これは8480のbpsのTIAS帯域幅率、および1秒あたり10の要求されたパケットをもたらします。 ビデオストリームは、より可変です。 しかしながら、それには、4万2300のbpsの測定最大積載量レートがあります。 また、ビデオストリームには、可変パケットレートがあります、ビデオが1秒あたり15個のフレームであるという事実にもかかわらず。(そこでは、2番目の長い窓の少なくとも1つのインスタンスが18のパケットを含みます)。
7. Protocol Interaction
7. プロトコル相互作用
7.1. RTSP
7.1. RTSP
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 SETUPの前で必要な帯域幅について計算する問題が全くあるべきではありません。 理由はクライアントが限られた数の輸送セットアップをサポートするということです。 実際にSETUP要求におけるサーバに提供されたのはSDP記述のコンテンツに依存するようになるでしょう。 「m=」系列は必要な輸送プロフィールをクライアントに示すでしょう。
7.2. SIP
7.2. 一口
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=」分野とクライアントの接続性から決定できます。
Westerlund Standards Track [Page 17] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[17ページ]。
7.3. SAP
7.3. SAP
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=」)とその輸送分野で明白です。
8. Security Consideration
8. 警備上の配慮
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.
それがこれらのセキュリティリスクのために強くであるRECOMMENDED、SDPが保全であることは保護されて、したがって、いじりながら認証されたソースは実行できないで、ソースは信じることができます。 また、SDPのどんな受信機もそれらがアプリケーションのための妥当な期待値であることを確かめるために容認された帯域幅値の分析を実行するのは、RECOMMENDEDです。 例えば、1000年のキロビット毎秒を使用すると主張するただ一つのチャンネル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].
上記のセキュリティ要件のいくつかがmiddleboxを通してSDP仕事を使用することでシグナリングをプロトコルにするのに必要であるそれとの闘争中であることに注意してください、RFC3303[18]のセキュリティ問題で議論するように。
9. IANA Considerations
9. IANA問題
This document registers one new SDP session and media level attribute "maxprate", see section 6.3.
セクション6.3は、このドキュメントが1つの新しいSDPセッションとメディアレベル属性"maxprate"を登録するのを見ます。
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.
また、標準化過程RFCを必要とする規則に従って、新しいSDP[1]帯域幅修飾語(bwtype)「TIAS」は登録されます。 修飾語はセクション6.2で定義されます。
Westerlund Standards Track [Page 18] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[18ページ]。
10. Acknowledgments
10. 承認
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が旧バージョンにおけるいくつかの誤りを言語、および特定に固定すると言われています。 改良への提案のさらなる感謝はコリン・パーキンス、Geetha Srikantan、およびエムレ・アクスに行きます。
The author would also like to thank all persons on the MMUSIC working group's mailing list that have commented on this specification.
また、作者はMMUSICワーキンググループのメーリングリストのこの仕様を批評したすべての人々に感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[1] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
11.2. Informative References
11.2. 有益な参照
[5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[5] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[8]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[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)帯域幅修飾語」、RFC3556、2003年7月。
Westerlund Standards Track [Page 19] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[19ページ]。
[10] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[10] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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.、およびRFC2508、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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 フレームワークと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[13] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[14] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、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の機能的な仕様」、RFC2205、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.とイトゥラルデとC.とオランとD.とCasner、S.とJ.Wroclawski、「圧縮性の流れがあるとき統合サービス」RFC3006(2000年11月)。
[17] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation," Work in Progress, March 2003.
[17] クッチャーと、オットと、ボルマンと、「セッション記述と能力交渉」は進歩、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と、「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(2002年8月)
[19] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[19] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[20] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[21] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
Westerlund Standards Track [Page 20] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[20ページ]。
12. Author's Address
12. 作者のアドレス
Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN
マグヌスWesterlundエリクソン研究エリクソンAB Torshamnsgatan23SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: Magnus.Westerlund@ericsson.com
Westerlund Standards Track [Page 21] RFC 3890 Bandwidth Modifier for SDP September 2004
Westerlund規格は2004年9月にSDPのためにRFC3890帯域幅修飾語を追跡します[21ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Westerlund Standards Track [Page 22]
Westerlund標準化過程[22ページ]
一覧
スポンサーリンク
