RFC4585 日本語訳
4585 Extended RTP Profile for Real-time Transport Control Protocol(RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. Wenger, N. Sato, C.Burmeister, J. Rey. July 2006. (Format: TXT=117762 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Ott
Request for Comments: 4585 Helsinki University of Technology
Category: Standards Track S. Wenger
Nokia
N. Sato
Oki
C. Burmeister
J. Rey
Matsushita
July 2006
コメントを求めるワーキンググループJ.オットの要求をネットワークでつないでください: 4585年の技術カテゴリのヘルシンキ大学: 標準化過程S.ウェンガーノキアN.佐藤Oki C.バーマイスターJ.レイMatsushita2006年7月
Extended RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
拡張RTPはリアルタイムの輸送制御プロトコルのために(RTCP)ベースのフィードバックの輪郭を描きます。(RTP/AVPF)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.
RTPを使用するリアルタイムのメディアの流れはパケット損失に対してある程度立ち直りが早いです。 受信機は、パケットレセプション統計を報告するレアル-時間Transport Controlプロトコル(RTCP)のベースメカニズムを使用して、その結果、送付者が中間試験でトランスミッションの振舞いを適合させるのを許容するかもしれません。 これはフィードバックとフィードバックベースの誤り修理(いくつかのコーデックの特定のメカニズム以外に)のための唯一の手段です。 このドキュメントは短期的な適合と効率的なフィードバックベースの修理メカニズムが実行されるのを受信機が統計的により即座のフィードバックを送付者に提供するのを可能にして、その結果許容するAudio視覚のProfile(AVP)と拡大を定義します。 この前のフィードバックプロフィール(AVPF)は、RTCPのAVP帯域幅規制を維持して、大きいグループとしてスケーラビリティを保存します。
Ott, et al. Standards Track [Page 1] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Terminology ................................................5
2. RTP and RTCP Packet Formats and Protocol Behavior ...............6
2.1. RTP ........................................................6
2.2. Underlying Transport Protocols .............................6
3. Rules for RTCP Feedback .........................................7
3.1. Compound RTCP Feedback Packets .............................7
3.2. Algorithm Outline ..........................................8
3.3. Modes of Operation .........................................9
3.4. Definitions and Algorithm Overview ........................11
3.5. AVPF RTCP Scheduling Algorithm ............................14
3.5.1. Initialization .....................................15
3.5.2. Early Feedback Transmission ........................15
3.5.3. Regular RTCP Transmission ..........................18
3.5.4. Other Considerations ...............................19
3.6. Considerations on the Group Size ..........................20
3.6.1. ACK Mode ...........................................20
3.6.2. NACK Mode ..........................................20
3.7. Summary of Decision Steps .................................22
3.7.1. General Hints ......................................22
3.7.2. Media Session Attributes ...........................22
4. SDP Definitions ................................................23
4.1. Profile Identification ....................................23
4.2. RTCP Feedback Capability Attribute ........................23
4.3. RTCP Bandwidth Modifiers ..................................27
4.4. Examples ..................................................27
5. Interworking and Coexistence of AVP and AVPF Entities ..........29
6. Format of RTCP Feedback Messages ...............................31
6.1. Common Packet Format for Feedback Messages ................32
6.2. Transport Layer Feedback Messages .........................34
6.2.1. Generic NACK .......................................34
6.3. Payload-Specific Feedback Messages ........................35
6.3.1. Picture Loss Indication (PLI) ......................36
6.3.2. Slice Loss Indication (SLI) ........................37
6.3.3. Reference Picture Selection Indication (RPSI) ......39
6.4. Application Layer Feedback Messages .......................41
7. Early Feedback and Congestion Control ..........................41
8. Security Considerations ........................................42
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................47
11. References ....................................................48
11.1. Normative References .....................................48
11.2. Informative References ...................................48
1. 序論…3 1.1. 定義…3 1.2. 用語…5 2. RTP、RTCPパケット・フォーマット、およびプロトコルの振舞い…6 2.1. RTP…6 2.2. 基本的なトランスポート・プロトコル…6 3. RTCPフィードバックのための規則…7 3.1. RTCPフィードバックパケットを合成してください…7 3.2. アルゴリズムアウトライン…8 3.3. 操作のモード…9 3.4. 定義とアルゴリズム概観…11 3.5. AVPF RTCPスケジューリングアルゴリズム…14 3.5.1. 初期設定…15 3.5.2. 早めのフィードバック送信…15 3.5.3. 定期的なRTCPトランスミッション…18 3.5.4. 他の問題…19 3.6. グループサイズに関する問題…20 3.6.1. ACKモード…20 3.6.2. ナックMode…20 3.7. 決定の概要は踏まれます…22 3.7.1. 一般は暗示します…22 3.7.2. メディアセッション属性…22 4. SDP定義…23 4.1. 識別の輪郭を描いてください…23 4.2. RTCPフィードバック能力属性…23 4.3. RTCP帯域幅修飾語…27 4.4. 例…27 5. AVPとAVPF実体の織り込むのと共存…29 6. RTCPフィードバックメッセージの形式…31 6.1. フィードバックメッセージのための一般的なパケット・フォーマット…32 6.2. 層のフィードバックメッセージを輸送してください…34 6.2.1. 一般的なナック…34 6.3. 有効搭載量特有のフィードバックメッセージ…35 6.3.1. 損失指示(PLI)について描写してください…36 6.3.2. 損失指示(SLI)を切ってください…37 6.3.3. 参照絵の選択指示(RPSI)…39 6.4. 応用層フィードバックメッセージ…41 7. 早めのフィードバックと混雑は制御されます…41 8. セキュリティ問題…42 9. IANA問題…43 10. 承認…47 11. 参照…48 11.1. 標準の参照…48 11.2. 有益な参照…48
Ott, et al. Standards Track [Page 2] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[2ページ]。
1. Introduction
1. 序論
Real-time media streams that use RTP are, to some degree, resilient against packet losses. RTP [1] provides all the necessary mechanisms to restore ordering and timing present at the sender to properly reproduce a media stream at a recipient. RTP also provides continuous feedback about the overall reception quality from all receivers -- thereby allowing the sender(s) in the mid-term (in the order of several seconds to minutes) to adapt their coding scheme and transmission behavior to the observed network quality of service (QoS). However, except for a few payload-specific mechanisms [6], RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retroactive Forward Error Correction (FEC) control, or media-specific mechanisms for some video codecs, such as reference picture selection.
RTPを使用するリアルタイムのメディアの流れはパケット損失に対してある程度立ち直りが早いです。 RTP[1]は、受取人におけるメディアの流れを適切に再生させるために送付者の現在の注文とタイミングを回復するためにすべての必要なメカニズムを提供します。 また、RTPはすべての受信機から総合的なレセプション品質に関する連続したフィードバックを提供して、その結果、観測されたネットワークサービスの質(QoS)へのそれらのコード構成を適合させることにおける中期(数秒から数分の注文における)とトランスミッション振舞いで送付者を許容します。 しかしながら、いくつかのペイロード特有のメカニズム[6]以外に、RTPは送付者がすぐにメディアの流れを修理できるタイムリーなフィードバックに備えません: 「再-トランスミッション」を通して、遡及効果があるForward Error Correction(FEC)が制御するか、または参照などのいくつかのビデオコーデックのためのメディア特有のメカニズムは選択について描写します。
Current mechanisms available with RTP to improve error resilience include audio redundancy coding [13], video redundancy coding [14], RTP-level FEC [11], and general considerations on more robust media streams transmission [12]. These mechanisms may be applied proactively (thereby increasing the bandwidth of a given media stream). Alternatively, in sufficiently small groups with small round-trip times (RTTs), the senders may perform repair on-demand, using the above mechanisms and/or media-encoding-specific approaches. Note that "small group" and "sufficiently small RTT" are both highly application dependent.
誤り弾力を改良するRTPと共に利用可能な現在のメカニズムはオーディオ冗長コード化[13]を含んで、より強健なメディアで[14]、RTP-レベルFEC[11]、および一般的な問題をコード化するビデオ冗長がトランスミッション[12]を流します。 これらのメカニズムは予測して適用されるかもしれません(その結果、与えられたメディアの流れの帯域幅を増加させます)。 あるいはまた、小さい往復の回(RTTs)がある十分小さいグループでは、送付者は要求次第で修理を実行するかもしれません、上のメカニズム、そして/または、詳細をコード化するメディアアプローチを使用して。 その「小さいグループ」と「十分小さいRTT」がともにアプリケーションに非常に依存していることに注意してください。
This document specifies a modified RTP profile for audio and video conferences with minimal control based upon [1] and [2] by means of two modifications/additions: Firstly, to achieve timely feedback, the concept of Early RTCP messages as well as algorithms allowing for low-delay feedback in small multicast groups (and preventing feedback implosion in large ones) are introduced. Special consideration is given to point-to-point scenarios. Secondly, a small number of general-purpose feedback messages as well as a format for codec- and application-specific feedback information are defined for transmission in the RTCP payloads.
このドキュメントは最小量のコントロールが2つの変更/追加によって[1]と[2]に基づいていてオーディオとテレビ会議システムのための変更されたRTPプロフィールを指定します: まず第一に、タイムリーなフィードバック、Early RTCPの概念を達成するために、小さいマルチキャストグループ(大きいものにおけるフィードバック内部破裂を防いで)で低い遅れフィードバックを考慮するアルゴリズムと同様にメッセージは紹介されます。 二地点間シナリオに特別の配慮を与えます。 第二に、形式と同様にコーデックへの少ない数の汎用フィードバックメッセージとアプリケーション特有のフィードバック情報はRTCPペイロードにおけるトランスミッションのために定義されます。
1.1. Definitions
1.1. 定義
The definitions from RTP/RTCP [1] and the "RTP Profile for Audio and Video Conferences with Minimal Control" [2] apply. In addition, the following definitions are used in this document:
RTP/RTCP[1]と「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」[2]からの定義は適用されます。 さらに、以下の定義は本書では使用されます:
Ott, et al. Standards Track [Page 3] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[3ページ]。
Early RTCP mode:
The mode of operation in that a receiver of a media stream is
often (but not always) capable of reporting events of interest
back to the sender close to their occurrence. In Early RTCP mode,
RTCP packets are transmitted according to the timing rules defined
in this document.
早めのRTCPモード: (いつもでない)しばしば運転モードはメディアの受信機が流れるからです。彼らの発生の近くで興味があるイベントの送付者に報告を持ちかえることができます。 Early RTCPモードで、本書では定義されたタイミング規則に従って、RTCPパケットは伝えられます。
Early RTCP packet:
An Early RTCP packet is a packet which is transmitted earlier than
would be allowed if following the scheduling algorithm of [1], the
reason being an "event" observed by a receiver. Early RTCP
packets may be sent in Immediate Feedback and in Early RTCP mode.
Sending an Early RTCP packet is also referred to as sending Early
Feedback in this document.
早いRTCPパケット: Early RTCPパケットは伝えられた早いRTCPパケットがImmediate FeedbackとEarly RTCPで送られるかもしれない[1](受信機によって観測された「出来事」である理由)のスケジューリングアルゴリズムに従うなら許容されるだろうより初期のモードであるパケットです。 また、Early RTCPパケットを送るのは本書では送付Early Feedbackと呼ばれます。
Event:
An observation made by the receiver of a media stream that is
(potentially) of interest to the sender -- such as a packet loss
or packet reception, frame loss, etc. -- and thus useful to be
reported back to the sender by means of a feedback message.
出来事: パケット損失やパケットレセプション、フレームの損失などの送付者には、(潜在的に)興味深いメディアの流れの受信機によってされた観測 -- そして、その結果、報告された後部になるように、フィードバックメッセージによる送付者の役に立ちます。
Feedback (FB) message:
An RTCP message as defined in this document is used to convey
information about events observed at a receiver -- in addition to
long-term receiver status information that is carried in RTCP
receiver reports (RRs) -- back to the sender of the media stream.
For the sake of clarity, feedback message is referred to as FB
message throughout this document.
フィードバック(FB)メッセージ: 本書では定義されるRTCPメッセージは、受信機でRTCP受信機レポート(RRs)でメディアの流れの送付者まで運んで戻される長期の受信機状態情報に加えて観測された出来事に関して情報を伝達するのに使用されます。 明快のために、フィードバックメッセージはこのドキュメント中にFBメッセージと呼ばれます。
Feedback (FB) threshold:
The FB threshold indicates the transition between Immediate
Feedback and Early RTCP mode. For a multiparty scenario, the FB
threshold indicates the maximum group size at which, on average,
each receiver is able to report each event back to the sender(s)
immediately, i.e., by means of an Early RTCP packet without having
to wait for its regularly scheduled RTCP interval. This threshold
is highly dependent on the type of feedback to be provided,
network QoS (e.g., packet loss probability and distribution),
codec and packetization scheme in use, the session bandwidth, and
application requirements. Note that the algorithms do not depend
on all senders and receivers agreeing on the same value for this
threshold. It is merely intended to provide conceptual guidance
to application designers and is not used in any calculations. For
the sake of clarity, the term feedback threshold is referred to as
FB threshold throughout this document.
フィードバック(FB)敷居: FB敷居はImmediate FeedbackとEarly RTCPモードの間の変遷を示します。 「マルチ-パーティー」シナリオのために、FB敷居は平均的に、それぞれの受信機がすぐに各出来事の送付者に報告を持ちかえることができる最大のグループサイズを示します、すなわち、Early RTCPパケット定期的に予定されているRTCP間隔の間、待つ必要はなくてによる。 この敷居は、提供されるフィードバックのタイプに非常に依存していてネットワークQoS(例えば、パケット紛失率と分配)、コーデックと使用中であるpacketization計画、セッション帯域幅であり、アプリケーションは要件です。 アルゴリズムをこの敷居のために同じ値に同意するすべての送付者と受信機に頼らないことに注意してください。 それは、概念的な指導をアプリケーション設計者に提供することを単に意図して、どんな計算にも使用されません。 明快のために、用語フィードバック敷居はこのドキュメント中にFB敷居と呼ばれます。
Ott, et al. Standards Track [Page 4] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[4ページ]。
Immediate Feedback mode:
A mode of operation in which each receiver of a media stream is,
statistically, capable of reporting each event of interest
immediately back to the media stream sender. In Immediate
Feedback mode, RTCP FB messages are transmitted according to the
timing rules defined in this document.
即座のFeedbackモード: メディアの流れのそれぞれの受信機がすぐに統計的に興味があるそれぞれのイベントのメディアに報告を持ちかえることができる運転モードは送付者を流します。 Immediate Feedbackモードで、本書では定義されたタイミング規則に従って、RTCP FBメッセージは送られます。
Media packet:
A media packet is an RTP packet.
メディア向けの資料セット: メディア向けの資料セットはRTPパケットです。
Regular RTCP mode:
Mode of operation in which no preferred transmission of FB
messages is allowed. Instead, RTCP messages are sent following
the rules of [1]. Nevertheless, such RTCP messages may contain
feedback information as defined in this document.
通常のRTCPモード: FBメッセージのどんな都合のよい伝達も許されていない運転モード。 代わりに、[1]について約束を守るのをRTCPメッセージに送ります。 それにもかかわらず、そのようなRTCPメッセージは本書では定義されるようにフィードバック情報を含むかもしれません。
Regular RTCP packet:
An RTCP packet that is not sent as an Early RTCP packet.
レギュラーのRTCPパケット: Early RTCPパケットとして送られないRTCPパケット。
RTP sender:
An RTP sender is an RTP entity that transmits media packets as
well as RTCP packets and receives Regular as well as Early RTCP
(i.e., feedback) packets. Note that the RTP sender is a logical
role and that the same RTP entity may at the same time act as an
RTP receiver.
RTP送付者: RTP送付者はRTCPパケットと同様にメディア向けの資料セットを送信して、Early RTCP(すなわち、フィードバック)パケットと同様にRegularを受けるRTP実体です。 RTP送付者が論理的な役割であり、同じRTP実体がRTP受信機と同じ時間条例に基づきそうするかもしれないことに注意してください。
RTP receiver:
An RTP receiver is an RTP entity that receives media packets as
well as RTCP packets and transmits Regular as well as Early RTCP
(i.e., feedback) packets. Note that the RTP receiver is a logical
role and that the same RTP entity may at the same time act as an
RTP sender.
RTP受信機: RTP受信機はRTCPパケットと同様にメディア向けの資料セットを受けて、Early RTCP(すなわち、フィードバック)パケットと同様にRegularを伝えるRTP実体です。 RTP受信機が論理的な役割であり、同じRTP実体がRTP送付者と同じ時間条例に基づきそうするかもしれないことに注意してください。
1.2. Terminology
1.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 RFC 2119 [5].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
Ott, et al. Standards Track [Page 5] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[5ページ]。
2. RTP and RTCP Packet Formats and Protocol Behavior
2. RTP、RTCPパケット・フォーマット、およびプロトコルの振舞い
2.1. RTP
2.1. RTP
The rules defined in [2] also apply to this profile except for those rules mentioned in the following:
また、[2]で定義された規則は以下で言及されたそれらの規則以外のこのプロフィールに適用されます:
RTCP packet types:
Two additional RTCP packet types are registered and the
corresponding FB messages to convey feedback information are
defined in Section 6 of this memo.
RTCPパケットはタイプされます: 2つの追加RTCPパケットタイプが登録されています、そして、フィードバック情報を伝える対応するFBメッセージはこのメモのセクション6で定義されます。
RTCP report intervals:
This document describes three modes of operation that influence
the RTCP report intervals (see Section 3.2 of this memo). In
Regular RTCP mode, all rules from [1] apply except for the
recommended minimal interval of five seconds between two RTCP
reports from the same RTP entity. In both Immediate Feedback and
Early RTCP modes, the minimal interval of five seconds between two
RTCP reports is dropped and, additionally, the rules specified in
Section 3 of this memo apply if RTCP packets containing FB
messages (defined in Section 4 of this memo) are to be
transmitted.
RTCPは間隔を報告します: このドキュメントはRTCPレポート間隔に影響を及ぼす3つの運転モードを説明します(このメモのセクション3.2を見てください)。 Regular RTCPモードで、同じRTP実体からの2つのRTCPレポートの間の5秒のお勧めの最小量の間隔を除いて、[1]からのすべての規則が適用されます。 Immediate FeedbackとEarly RTCPモードの両方では、2つのRTCPレポートの間の5秒の最小量の間隔は落とされます、そして、FBメッセージ(このメモのセクション4では、定義される)を含むRTCPパケットが伝えられるつもりであるなら、さらに、このメモのセクション3で指定された規則は適用されます。
The rules set forth in [1] may be overridden by session
descriptions specifying different parameters (e.g., for the
bandwidth share assigned to RTCP for senders and receivers,
respectively). For sessions defined using the Session Description
Protocol (SDP) [3], the rules of [4] apply.
[1]に詳しく説明された規則は異なったパラメタ(例えば送付者と受信機のためにRTCPに割り当てられた帯域幅シェアのためにそれぞれ)を指定するセッション記述でくつがえされるかもしれません。 Session記述プロトコル(SDP)[3]を使用することで定義されたセッションのために、[4]の規則は申し込まれます。
Congestion control:
The same basic rules as detailed in [2] apply. Beyond this, in
Section 7, further consideration is given to the impact of
feedback and a sender's reaction to FB messages.
輻輳制御: [2]で詳しく述べられるのと同じ基本的なルールは適用されます。 これを超えて、セクション7では、FBメッセージへのフィードバックと送付者の反応の影響に対してさらなる考慮を払います。
2.2. Underlying Transport Protocols
2.2. 基本的なトランスポート・プロトコル
RTP is intended to be used on top of unreliable transport protocols, including UDP and the Datagram Congestion Control Protocol (DCCP). This section briefly describes the specifics beyond plain RTP operation introduced by RTCP feedback as specified in this memo.
頼り無いトランスポート・プロトコルの上でRTPが使用されることを意図します、UDPとデータグラムCongestion Controlプロトコル(DCCP)を含んでいて。 このセクションは簡潔にこのメモでの指定されるとしてのRTCPフィードバックで導入された明瞭なRTP操作を超えて詳細について説明します。
UDP: UDP provides best-effort delivery of datagrams for point-to-
point as well as for multicast communications. UDP does not
support congestion control or error repair. The RTCP-based
feedback defined in this memo is able to provide minimal support
for limited error repair. As RTCP feedback is not guaranteed to
operate on sufficiently small timescales (in the order of RTT),
UDP: UDPはポイントからポイントまでマルチキャストコミュニケーションにデータグラムのベストエフォート型配送を提供します。 UDPは輻輳制御か誤り修理を支持しません。 このメモで定義されたRTCPベースのフィードバックは限られた誤り修理の最小量のサポートを提供できます。 RTCPとして、フィードバックは、十分小さいスケール(RTTの注文における)を作動させるために保証されません。
Ott, et al. Standards Track [Page 6] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[6ページ]。
RTCP feedback is not suitable to support congestion control. This
memo addresses both unicast and multicast operation.
RTCPフィードバックは輻輳制御を支えるのにおいて適当ではありません。 このメモはユニキャストとマルチキャスト操作の両方を記述します。
DCCP: DCCP [19] provides for congestion-controlled but unreliable
datagram flows for unicast communications. With TCP Friendly Rate
Control (TFRC)-based [20] congestion control (CCID 3), DCCP is
particularly suitable for audio and video communications. DCCP's
acknowledgement messages may provide detailed feedback reporting
about received and missed datagrams (and thus about congestion).
DCCP: DCCP[19]はユニキャストコミュニケーションのために混雑で制御されましたが、頼り無いデータグラム流れに備えます。 TCP Friendly Rate Controlの(TFRC)ベースの[20]輻輳制御(CCID3)があるので、DCCPは特にオーディオとビデオコミュニケーションに適しています。 DCCPの確認メッセージが受け取られていていて逃されたデータグラムに関して報告する詳細なフィードバックを提供するかもしれない、(その結果、混雑、)
When running RTP over DCCP, congestion control is performed at the
DCCP layer and no additional mechanisms are required at the RTP
layer. Furthermore, an RTCP-feedback-capable sender may leverage
the more frequent DCCP-based feedback and thus a receiver may
refrain from using (additional) Generic Feedback messages where
appropriate.
DCCPの上でRTPを走らせるとき、輻輳制御はDCCP層で実行されます、そして、どんな追加メカニズムもRTP層で必要ではありません。 その上、できるRTCPフィードバック送付者は、より頻繁なDCCPベースのフィードバックに投機するかもしれません、そして、その結果、受信機は適切であるところで(追加する)の一般的なFeedbackメッセージを使用するのを控えるかもしれません。
3. Rules for RTCP Feedback
3. RTCPフィードバックのための規則
3.1. Compound RTCP Feedback Packets
3.1. 合成RTCPフィードバックパケット
Two components constitute RTCP-based feedback as described in this document:
2つのコンポーネントが本書では説明されるようにRTCPベースのフィードバックを構成します:
o Status reports are contained in sender report (SR)/received report
(RR) packets and are transmitted at regular intervals as part of
compound RTCP packets (which also include source description
(SDES) and possibly other messages); these status reports provide
an overall indication for the recent reception quality of a media
stream.
o 現状報告は、送付者レポート(SR)/受け取られていているレポート(RR)パケットに含まれていて、一定の間隔を置いて合成RTCPパケット(また、ソース記述(SDES)とことによると他のメッセージを含んでいる)の一部として伝えられます。 これらの現状報告はメディアの流れの最近のレセプション品質のための総合的な指示を提供します。
o FB messages as defined in this document that indicate loss or
reception of particular pieces of a media stream (or provide some
other form of rather immediate feedback on the data received).
Rules for the transmission of FB messages are newly introduced in
this document.
o メディアの流れ(ある他のフォームの受け取られたデータに関するかなり即座のフィードバックを提供する)の特定の片の損失かレセプションを示す本書では定義されるFBメッセージ。 新たに本書ではFBメッセージの伝達のための規則を導入します。
RTCP FB messages are just another RTCP packet type (see Section 4). Therefore, multiple FB messages MAY be combined in a single compound RTCP packet and they MAY also be sent combined with other RTCP packets.
RTCP FBメッセージはただのRTCPパケットタイプ(セクション4を見る)です。 したがって、単一の合成RTCPパケットで複数のFBメッセージを結合するかもしれません、そして、また、他のRTCPパケットに結合されていた状態でそれらを送るかもしれません。
Compound RTCP packets containing FB messages as defined in this document MUST contain RTCP packets in the order defined in [1]:
定義されるようにFBメッセージを含む合成RTCPパケットは[1]で定義されたオーダーに本書ではRTCPパケットを含まなければなりません:
o OPTIONAL encryption prefix that MUST be present if the RTCP
packet(s) is to be encrypted according to Section 9.1 of [1].
o MANDATORY SR or RR.
o [1] oのMANDATORY SRかRRのセクション9.1によると、RTCPパケットがコード化されるつもりであるなら存在しなければならないOPTIONAL暗号化接頭語。
Ott, et al. Standards Track [Page 7] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[7ページ]。
o MANDATORY SDES, which MUST contain the CNAME item; all other SDES
items are OPTIONAL.
o One or more FB messages.
o MANDATORY SDES、どれがCNAMEの品目を含まなければならないか。 他のすべてのSDESの品目が、OPTIONAL o Oneか、より多くのFBメッセージです。
The FB message(s) MUST be placed in the compound packet after RR and SDES RTCP packets defined in [1]. The ordering with respect to other RTCP extensions is not defined.
次々と[1]で定義されたRRと合成SDES RTCPパケットにFBメッセージを置かなければなりません。 他のRTCP拡張子に関する注文は定義されません。
Two types of compound RTCP packets carrying feedback packets are used in this document:
フィードバックパケットを運ぶ2つのタイプの合成RTCPパケットが本書では使用されます:
a) Minimal compound RTCP feedback packet
a) 最小量の合成RTCPフィードバックパケット
A minimal compound RTCP feedback packet MUST contain only the
mandatory information as listed above: encryption prefix if
necessary, exactly one RR or SR, exactly one SDES with only the
CNAME item present, and the FB message(s). This is to minimize
the size of the RTCP packet transmitted to convey feedback and
thus to maximize the frequency at which feedback can be provided
while still adhering to the RTCP bandwidth limitations.
最小量の合成RTCPフィードバックパケットは以下の上に記載されているように表示義務のある情報だけを含まなければなりません。 暗号化は必要なら、そして、まさに1RRかSRと、ちょうどCNAMEの品目だけが存在している1SDESと、FBメッセージを前に置きます。 これは、フィードバックを伝えて、その結果、まだRTCP帯域幅制限を固く守っている間にフィードバックを提供できる頻度を最大にするために伝えられたRTCPパケットのサイズを最小にするためのものです。
This packet format SHOULD be used whenever an RTCP FB message is
sent as part of an Early RTCP packet. This packet type is
referred to as minimal compound RTCP packet in this document.
このパケットはSHOULDをフォーマットします。Early RTCPパケットの一部としてRTCP FBメッセージを送るときはいつも、使用されます。 このパケットタイプは本書では最小量の合成RTCPパケットと呼ばれます。
b) (Full) compound RTCP feedback packet
b) (いっぱいに) 合成RTCPフィードバックパケット
A (full) compound RTCP feedback packet MAY contain any additional
number of RTCP packets (additional RRs, further SDES items, etc.).
The above ordering rules MUST be adhered to.
(完全)の合成RTCPフィードバックパケットはどんな追加数のRTCPパケット(追加RRs、さらなるSDESの品目など)も含むかもしれません。 上の注文規則を固く守らなければなりません。
This packet format MUST be used whenever an RTCP FB message is
sent as part of a Regular RTCP packet or in Regular RTCP mode. It
MAY also be used to send RTCP FB messages in Immediate Feedback or
Early RTCP mode. This packet type is referred to as full compound
RTCP packet in this document.
Regular RTCPパケットの一部かRegular RTCPモードでRTCP FBメッセージを送るときはいつも、このパケット・フォーマットを使用しなければなりません。 また、それは、Immediate FeedbackかEarly RTCPのRTCP FBメッセージにモードを送るのに使用されるかもしれません。 このパケットタイプは本書では完全な合成RTCPパケットと呼ばれます。
RTCP packets that do not contain FB messages are referred to as non- FB RTCP packets. Such packets MUST follow the format rules in [1].
FBメッセージを含まないRTCPパケットが非FB RTCPのパケットと呼ばれます。 そのようなパケットは[1]で形式規則に従わなければなりません。
3.2. Algorithm Outline
3.2. アルゴリズムアウトライン
FB messages are part of the RTCP control streams and thus subject to the RTCP bandwidth constraints. This means, in particular, that it may not be possible to report an event observed at a receiver immediately back to the sender. However, the value of feedback
FBメッセージは制御ストリームとその結果、RTCP帯域幅規制を条件としたRTCPの一部です。 これは、出来事が受信機ですぐ送付者にとって見たと報告するのが可能でないかもしれないことを特に意味します。 しかしながら、フィードバックの値
Ott, et al. Standards Track [Page 8] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[8ページ]。
given to a sender typically decreases over time -- in terms of the media quality as perceived by the user at the receiving end and/or the cost required to achieve media stream repair.
通常時間がたつにつれての減少--送付者に考えて、犠牲者のユーザによって知覚される品質、そして/または、費用がメディアを達成するのを必要としたメディアで、修理を流してください。
RTP [1] and the commonly used RTP profile [2] specify rules when compound RTCP packets should be sent. This document modifies those rules in order to allow applications to timely report events (e.g., loss or reception of RTP packets) and to accommodate algorithms that use FB messages.
合成RTCPパケットを送るべきであるとき、RTP[1]と一般的に使用されたRTPプロフィール[2]は規則を指定します。 このドキュメントは、タイムリーなレポートイベント(RTPパケットの例えば、損失かレセプション)にアプリケーションを許容して、FBメッセージを使用するアルゴリズムに対応するようにそれらの規則を変更します。
The modified RTCP transmission algorithm can be outlined as follows: As long as no FB messages have to be conveyed, compound RTCP packets are sent following the rules of RTP [1] -- except that the five- second minimum interval between RTCP reports is not enforced. Hence, the interval between RTCP reports is only derived from the average RTCP packet size and the RTCP bandwidth share available to the RTP/RTCP entity. Optionally, a minimum interval between Regular RTCP packets may be enforced.
以下の通り変更されたRTCPトランスミッションアルゴリズムを概説できます: FBメッセージを全く伝えてはいけない限り、RTCPレポートの5時2分第前最小間隔が実施されないのを除いて、RTP[1]について約束を守るのを合成RTCPパケットに送ります。 したがって、平均したRTCPパケットサイズとRTP/RTCP実体に利用可能なRTCP帯域幅シェアからRTCPレポートの間隔を得るだけです。 任意に、Regular RTCPパケットの最小間隔は実施されるかもしれません。
If a receiver detects the need to send an FB message, it may do so earlier than the next regular RTCP reporting interval (for which it would be scheduled following the above regular RTCP algorithm). Feedback suppression is used to avoid feedback implosion in multiparty sessions: The receiver waits for a (short) random dithering interval to check whether it sees a corresponding FB message from any other receiver reporting the same event. Note that for point-to-point sessions there is no such delay. If a corresponding FB message from another member is received, this receiver refrains from sending the FB message and continues to follow the Regular RTCP transmission schedule. In case the receiver has not yet seen a corresponding FB message from any other member, it checks whether it is allowed to send Early feedback. If sending Early feedback is permissible, the receiver sends the FB message as part of a minimal compound RTCP packet. The permission to send Early feedback depends on the type of the previous RTCP packet sent by this receiver and the time the previous Early feedback message was sent.
受信機がFBメッセージを送る必要性を見つけるなら、それは前に次の一定のRTCP報告間隔(上の通常のRTCPアルゴリズムに従って、それが予定されているだろう)と同じくらいするかもしれません。 フィードバック抑圧は「マルチ-パーティー」セッションにおけるフィードバック内部破裂を避けるのに使用されます: 受信機は、(短い)の無作為のディザリング間隔の間、それが同じ出来事を報告する受信機からいかなる他のも対応するFBメッセージを見るかどうかチェックするのを待っています。 そこでの二地点間セッションのためのそれがそのような遅れでないことに注意してください。 別のメンバーからの対応するFBメッセージが受信されているなら、この受信機は、FBメッセージを送るのを控えて、ずっとRegular RTCPトランスミッションスケジュールに従います。 受信機がまだ見ていない場合では、いかなる他のメンバーからの対応するFBメッセージでありも、それは、フィードバックをEarlyに送ることができるかどうかチェックします。 送付Earlyフィードバックが許されるなら、受信機は最小量の合成RTCPパケットの一部としてFBメッセージを送ります。 フィードバックをEarlyに送る許可はこの受信機によって送られた前のRTCPパケットのタイプと前のEarlyフィードバックメッセージが送られた時代によります。
FB messages may also be sent as part of full compound RTCP packets, which are transmitted as per [1] (except for the five-second lower bound) in regular intervals.
また、完全な合成RTCPパケットの一部としてFBメッセージを送るかもしれません。(パケットは一定の間隔の[1](5秒の下界を除いた)に従って伝えられます)。
3.3. Modes of Operation
3.3. 運転モード
RTCP-based feedback may operate in one of three modes (Figure 1) as described below. The mode of operation is just an indication of whether or not the receiver will, on average, be able to report all events to the sender in a timely fashion; the mode does not influence the algorithm used for scheduling the transmission of FB messages.
RTCPベースのフィードバックは以下で説明されるように3つのモード(図1)の1つで作動するかもしれません。 運転モードはただ受信機が直ちにすべての出来事を送付者に平均的に報告できるかどうかしるしです。 モードはFBメッセージの伝達の計画をするのに使用されるアルゴリズムに影響を及ぼしません。
Ott, et al. Standards Track [Page 9] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[9ページ]。
And, depending on the reception quality and the locally monitored state of the RTP session, individual receivers may not (and do not have to) agree on a common perception on the current mode of operation.
そして、レセプション品質とRTPセッションの局所的にモニターされた状態によって、個々の受信機は操作の現在のモードで一般的な知覚に同意しないかもしれません(そして、そうする必要はありません)。
a) Immediate Feedback mode: In this mode, the group size is below the
FB threshold, which gives each receiving party sufficient
bandwidth to transmit the RTCP feedback packets for the intended
purpose. This means that, for each receiver, there is enough
bandwidth to report each event by means of a virtually "immediate"
RTCP feedback packet.
a) 即座のFeedbackモード: このモードには、グループサイズがFB敷居の下にあります。敷居は本来の目的のためにRTCPフィードバックパケットを伝えることができるくらいのそれぞれの受領者帯域幅を与えます。 これは、実際には「即座」のRTCPフィードバックパケットによって各出来事を報告するために帯域幅が各受信機のために十分あることを意味します。
The group size threshold is a function of a number of parameters
including (but not necessarily limited to): the type of feedback
used (e.g., ACK vs. NACK), bandwidth, packet rate, packet loss
probability and distribution, media type, codec, and the (worst
case or observed) frequency of events to report (e.g., frame
received, packet lost).
グループサイズ敷居、多くのパラメタの関数が含んでいるのと(必ず有限であるというわけではない)である、: 報告する(例えばフレームは受信されて、パケットは損をしました)出来事の使用されるフィードバック(例えば、ACK対ナック)、帯域幅、パケットレート、パケット紛失率、および分配のタイプ、メディアタイプ、コーデック、および(最悪の場合か観測される)の頻度。
As a rough estimate, let N be the average number of events to be
reported per interval T by a receiver, B the RTCP bandwidth
fraction for this particular receiver, and R the average RTCP
packet size, then the receiver operates in Immediate Feedback mode
as long as N<=B*T/R.
概算として、Bの受信機によって間隔T単位で報告されるべき出来事の平均した数、この特定の受信機のためのRTCP帯域幅断片、およびR平均したRTCPがパケットサイズであったならNをさせてください、そして、次に、受信機はN<=B*T/Rと同じくらい長い間、Immediate Feedbackモードで動作します。
b) Early RTCP mode: In this mode, the group size and other parameters
no longer allow each receiver to react to each event that would be
worth reporting (or that needed reporting). But feedback can
still be given sufficiently often so that it allows the sender to
adapt the media stream transmission accordingly and thereby
increase the overall media playback quality.
b) 早めのRTCPモード: このモードで、各受信機はもうグループサイズと他のパラメタでそれぞれの報告する価値がある出来事に反応できません(それは、報告する必要がありました)。 しかし、まだフィードバックを十分しばしば与えることができるので、送付者は、それで、それに従って、メディア流れ転送を適合させて、その結果、総合的なメディア再生品質を増加させます。
Using the above notation, Early RTCP mode can be roughly
characterized by N > B*T/R as "lower bound". An estimate for an
upper bound is more difficult. Setting N=1, we obtain for a given
R and B the interval T = R/B as average interval between events to
be reported. This information can be used as a hint to determine
whether or not early transmission of RTCP packets is useful.
上の記法を使用して、N>B*T/Rは「下界」としておよそEarly RTCPモードを特徴付けることができます。 上限のための見積りは、より難しいです。 N=1を設定して、私たちは、報告されるために出来事の平均した間隔として間隔T=R/Bを当然のことRとBに得ます。 RTCPパケットの早めのトランスミッションが役に立つかどうか決定するのにヒントとしてこの情報を使用できます。
c) Regular RTCP Mode: From some group size upwards, it is no longer
useful to provide feedback for individual events from receivers at
all -- because of the time scale in which the feedback could be
provided and/or because in large groups the sender(s) have no
chance to react to individual feedback anymore.
c) 通常のRTCPモード: 何らかのグループサイズから、大きいグループでは、送付者がフィードバックを提供できたタイムスケールそれ以上独特のフィードバックに反応する機会を全く持っていないので上向きに、フィードバックを全く受信機から個人種目に提供するのはもう役に立ちません。
No precise group size threshold can be specified at which this
mode starts but, obviously, this boundary matches the upper bound
of the Early RTCP mode as specified in item b) above.
このモードが始まるどんな正確なグループサイズ敷居も指定できませんが、明らかに、この境界は項目b)の指定されるとしての上のEarly RTCPモードの上限に合っています。
Ott, et al. Standards Track [Page 10] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[10ページ]。
As the feedback algorithm described in this document scales smoothly, there is no need for an agreement among the participants on the precise values of the respective FB thresholds within the group. Hence, the borders between all these modes are soft.
フィードバックアルゴリズムがスムーズに本書ではスケールについて説明したので、グループの中にそれぞれのFB敷居の正確な値の関係者の中に協定の必要は全くありません。 したがって、これらのすべてのモードの間の境界は柔らかいです。
ACK
feedback
V
:<- - - - NACK feedback - - - ->//
:
: Immediate ||
: Feedback mode ||Early RTCP mode Regular RTCP mode
:<=============>||<=============>//<=================>
: ||
-+---------------||---------------//------------------> group size
2 ||
Application-specific FB Threshold
= f(data rate, packet loss, codec, ...)
ACKフィードバックV: <------ナックフィードバック--、--、--、->//: : 即座|| : フィードバックモード||早めのRTCPモードRegular RTCPモード:<。=============>|、|<=======>//<。=================>: || -+---------------||---------------//------------------>グループサイズ2|| アプリケーション特有のFB敷居=f(データ信号速度、パケット損失、コーデック)
Figure 1: Modes of operation
図1: 運転モード
As stated before, the respective FB thresholds depend on a number of technical parameters (of the codec, the transport, the type of feedback used, etc.) but also on the respective application scenarios. Section 3.6 provides some useful hints (but no precise calculations) on estimating these thresholds.
以前述べられるように、それぞれのFB敷居はパラメタ(コーデック、輸送使用されるフィードバックなどのタイプ)ですが、それぞれのアプリケーションシナリオで技術的の数に依存します。 セクション3.6はこれらの敷居を見積もっているときのいくつかの役に立つヒント(しかし、厳密な計算がない)を提供します。
3.4. Definitions and Algorithm Overview
3.4. 定義とアルゴリズム概観
The following pieces of state information need to be maintained per receiver (largely taken from [1]). Note that all variables (except in item h) below) are calculated independently at each receiver. Therefore, their local values may differ at any given point in time.
以下の州の情報は、受信機単位で維持される必要があります。([1])から主に取ります。 すべての変数(以下の項目h)を除いた)が各受信機で独自に計算されることに注意してください。したがって、時間内にのポイントを考えて、地元の値はいずれでも異なってもよいです。
a) Let "senders" be the number of active senders in the RTP session.
a) 「送付者」がRTPセッションで、活発な送付者の数であることをさせてください。
b) Let "members" be the current estimate of the number of receivers
in the RTP session.
b) 「メンバー」がRTPセッションにおける、受信機の数の現在の見積りであることをさせてください。
c) Let tn and tp be the time for the next (last) scheduled RTCP RR
transmission calculated prior to timer reconsideration.
c) tnとtpがタイマ再考の前に計算された次の(最後に)予定されているRTCP RRトランスミッションのための時間であることをさせてください。
d) Let Tmin be the minimal interval between RTCP packets as per [1].
Unlike in [1], the initial Tmin is set to 1 second to allow for
some group size sampling before sending the first RTCP packet.
After the first RTCP packet is sent, Tmin is set to 0.
d) [1]に従ってTminがRTCPパケットの最小量の間隔であることをさせてください。 [1]などと異なって、初期のTminは最初のRTCPパケットを送る前にいくつかのグループサイズ標本抽出を考慮するように1秒に用意ができています。 最初のRTCPパケットを送った後に、Tminは0に用意ができています。
Ott, et al. Standards Track [Page 11] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[11ページ]。
e) Let T_rr be the interval after which, having just sent a regularly
scheduled RTCP packet, a receiver would schedule the transmission
of its next Regular RTCP packet. This value is obtained following
the rules of [1] but with Tmin as defined in this document: T_rr =
T (the "calculated interval" as defined in [1]) with tn = tp + T.
T_rr always refers to the last value of T that has been computed
(because of reconsideration or to determine tn). T_rr is also
referred to as Regular RTCP interval in this document.
e) T_rrがちょうど定期的に予定されているRTCPパケットを送ったところであるのによる受信機が次のRegular RTCPパケットのトランスミッションの計画をする間隔であることをさせてください。 この値は[1]の規則に従って、得ますが、Tminと共に本書では定義されるようにあります: T_rrがTと等しい、(tn=tp+T.T_rrで[1])で定義される「計算された間隔」がいつも計算されたTの最終値を示す、(再考、tnを決定する、) また、T_rrは本書ではRegular RTCP間隔と呼ばれます。
f) Let t0 be the time at which an event that is to be reported is
detected by a receiver.
f) t0が報告されることになっている出来事が受信機によって検出される時であることをさせてください。
g) Let T_dither_max be the maximum interval for which an RTCP
feedback packet MAY be additionally delayed to prevent implosions
in multiparty sessions; the value for T_dither_max is dynamically
calculated based upon T_rr (or may be derived by means of another
mechanism common across all RTP receivers to be specified in the
future). For point-to-point sessions (i.e., sessions with exactly
two members with no change in the group size expected, e.g.,
unicast streaming sessions), T_dither_max is set to 0.
g) T_震え_最大がRTCPフィードバックパケットが「マルチ-パーティー」セッションにおける内部破裂を防ぐためにさらに、遅れるかもしれない最大の間隔であることをさせてください。 T_震え_最大がダイナミックに計算されるので、値は_rr(または、すべてのRTP受信機の向こう側に一般的な別のメカニズムによって将来指定されるために引き出されるかもしれない)をTに基礎づけました。 二地点間セッション(すなわち、ちょうどグループサイズにおける変化なしで予想される2人のメンバーとのセッション、例えば、ユニキャストのストリーミングのセッション)のために、T_震え_最大は0に設定されます。
h) Let T_max_fb_delay be the upper bound within which feedback to an
event needs to be reported back to the sender to be useful at all.
This value is application specific, and no values are defined in
this document.
h) T_最大_fb_遅れが出来事へのフィードバックが全く役に立つと送付者に報告して戻られる必要がある上限であることをさせてください。 この値はアプリケーション特有です、そして、値は全く本書では定義されません。
i) Let te be the time for which a feedback packet is scheduled.
i) Teがフィードバックパケットが予定されている時間であることをさせてください。
j) Let T_fd be the actual (randomized) delay for the transmission of
FB message in response to an event at time t0.
j) FBメッセージの伝達のために時間t0の出来事に対応してT_fdが実際(ランダマイズされる)の遅れであることをさせてください。
k) Let allow_early be a Boolean variable that indicates whether the
receiver currently may transmit FB messages prior to its next
regularly scheduled RTCP interval tn. This variable is used to
throttle the feedback sent by a single receiver. allow_early is
set to FALSE after Early feedback transmission and is set to TRUE
as soon as the next Regular RTCP transmission takes place.
k) 受信機が次の定期的に予定されているRTCP間隔の前に現在FBメッセージを送るかもしれないかどうかを示したブール変数がtnであったなら早く_を許容させます。 この変数は、単一の受信機によって送られたフィードバックを阻止するのに使用されます。早く_を許容してください。Earlyフィードバック送信の後にFALSEに設定されて、次のRegular RTCPトランスミッションが行われるとすぐに、TRUEに用意ができています。
l) Let avg_rtcp_size be the moving average on the RTCP packet size as
defined in [1].
l) [1]で定義されるようにRTCPパケットサイズでavg_rtcp_サイズが移動平均線であることをさせてください。
m) Let T_rr_interval be an OPTIONAL minimal interval to be used
between Regular RTCP packets. If T_rr_interval == 0, then this
variable does not have any impact on the overall operation of the
RTCP feedback algorithm. If T_rr_interval != 0, then the next
Regular RTCP packet will not be scheduled T_rr after the last
Regular RTCP transmission (i.e., at tp+T_rr). Instead, the next
Regular RTCP packet will be delayed until at least T_rr_interval
m) T_rr_間隔がOPTIONALの最小量の間隔であることをさせて、Regular RTCPパケットの間で使用されてください。 T_rr_間隔=0であるなら、この変数はRTCPフィードバックアルゴリズムの総合的な操作にどんな影響力も持っていません。 T_rr_間隔!=0であるなら、次のRegular RTCPパケットは最後のRegular RTCPトランスミッション(_すなわち、tp+T rrの)の後の予定されているT_rrでないでしょう。 代わりに、次のRegular RTCPパケットは少なくともT_rr_間隔まで遅れるでしょう。
Ott, et al. Standards Track [Page 12] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[12ページ]。
after the last Regular RTCP transmission, i.e., it will be
scheduled at or later than tp+T_rr_interval. Note that
T_rr_interval does not affect the calculation of T_rr and tp;
instead, Regular RTCP packets scheduled for transmission before
tp+T_rr_interval will be suppressed if, for example, they do not
contain any FB messages. The T_rr_interval does not affect
transmission scheduling of Early RTCP packets.
最後のRegular RTCPトランスミッションの後に、すなわち、tp+T_rr_間隔より予定されているか、または、より遅くなるでしょう。 T_rr_間隔が_Tのrrとtpの計算に影響しないことに注意してください。 代わりに、例えば、どんなFBメッセージも含んでいないと、tp+T_rr_間隔の前のトランスミッションのために予定されていたRegular RTCPパケットは抑圧されるでしょう。 T_rr_間隔はEarly RTCPパケットのトランスミッションスケジューリングに影響しません。
Note: Providing T_rr_interval as an independent variable is meant
to minimize Regular RTCP feedback (and thus bandwidth consumption)
as needed by the application while additionally allowing the use
of more frequent Early RTCP packets to provide timely feedback.
This goal could not be achieved by reducing the overall RTCP
bandwidth as RTCP bandwidth reduction would also impact the
frequency of Early feedback.
以下に注意してください。 自変数としてT_rr_間隔を提供すると、より頻繁なEarly RTCPパケットの使用がタイムリーなフィードバックを提供するのをさらに、許容している間、Regular RTCPフィードバック(そして、その結果、帯域幅消費)は必要に応じてアプリケーションで最小にされることになっています。 また、RTCP帯域幅削減がEarlyフィードバックの頻度に影響を与えるだろうというのに従って総合的なRTCP帯域幅を減少させることによって、この目標を達成できないでしょう。
n) Let t_rr_last be the point in time at which the last Regular RTCP
packet has been scheduled and sent, i.e., has not been suppressed
due to T_rr_interval.
n) t_rr_最終が時間内にのすなわち、最後のRegular RTCPパケットが予定されて、送られたポイントがT_rr_間隔のため抑圧されていないということであることをさせてください。
o) Let T_retention be the time window for which past FB messages are
stored by an AVPF entity. This is to ensure that feedback
suppression also works for entities that have received FB messages
from other entities prior to noticing the feedback event itself.
T_retention MUST be set to at least 2 seconds.
o) どれがAVPF実体によってFBメッセージを超えて格納されるかためにT_保有がタイムウィンドウであることをさせてください。 これは、また、フィードバック抑圧もフィードバックイベント自体に気付く前に他の実体からFBメッセージを受け取った実体に効き目があるのを保証するためのものです。 少なくとも2秒にT_保有を設定しなければなりません。
p) Let M*Td be the timeout value for a receiver to be considered
inactive (as defined in [1]).
p) M*Tdがタイムアウト値であることをさせます。(受信機は不活発であると考えられてください、そして、[1])で定義されるように。
The feedback situation for an event to report at a receiver is depicted in Figure 2 below. At time t0, such an event (e.g., a packet loss) is detected at the receiver. The receiver decides -- based upon current bandwidth, group size, and other application- specific parameters -- that an FB message needs to be sent back to the sender.
出来事が受信機で報告するフィードバック状況は以下の図2に叙述されます。 時間t0のときに、そのような出来事(例えば、パケット損失)は受信機に検出されます。受信機は決めます--現在の帯域幅に基づいて、サイズ、および他のアプリケーションの特定のパラメタを分類してください--FBメッセージは、送付者に送り返される必要があります。
To avoid an implosion of feedback packets in multiparty sessions, the receiver MUST delay the transmission of the RTCP feedback packet by a random amount of time T_fd (with the random number evenly distributed in the interval [0, T_dither_max]). Transmission of the compound RTCP packet MUST then be scheduled for te = t0 + T_fd.
「マルチ-パーティー」セッションにおける、フィードバックパケットの内部破裂を避けるために、受信機は無作為の時間T_fd(乱数が間隔[0、T_震え_最大]で均等に分配されている)によるRTCPフィードバックパケットのトランスミッションを遅らせなければなりません。 そして、_Te=t0+T fdのために合成RTCPパケットのトランスミッションを予定しなければなりません。
The T_dither_max parameter is derived from the Regular RTCP interval, T_rr, which, in turn, is based upon the group size. A future document may also specify other calculations for T_dither_max (e.g., based upon RTT) if it can be assured that all RTP receivers will use the same mechanism for calculating T_dither_max.
Regular RTCP間隔、順番にグループサイズに基づいているT_rrからT_震え_最大パラメタを得ます。 また、すべてのRTP受信機が計算のT_震え_最大に同じメカニズムを使用することを保証できるなら、将来のドキュメントはT_震え_最大(例えば、RTTに基づいている)のための他の計算を指定するかもしれません。
Ott, et al. Standards Track [Page 13] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[13ページ]。
For a certain application scenario, a receiver may determine an upper bound for the acceptable local delay of FB messages: T_max_fb_delay. If an a priori estimation or the actual calculation of T_dither_max indicates that this upper bound MAY be violated (e.g., because T_dither_max > T_max_fb_delay), the receiver MAY decide not to send any feedback at all because the achievable gain is considered insufficient.
あるアプリケーションシナリオのために、受信機はFBメッセージの許容できる地方の遅れのための上限を決定するかもしれません: T_は_fb_遅れに最大限にします。 T_震え_最大の先験的な見積りか実際の計算が、この上限が違反されるかもしれないのを示すなら(_例えば、T_がうろたえるので、>T_最大_fb_遅れに最大限にしてください)、受信機は、達成可能な利得が不十分であると考えられるので全く少しのフィードバックも送らないと決めるかもしれません。
If an Early RTCP packet is scheduled, the time slot for the next Regular RTCP packet MUST be updated accordingly to have a new tn (tn=tp+2*T_rr) and a new tp (tp=tp+T_rr) afterwards. This is to ensure that the short-term average RTCP bandwidth used with Early feedback does not exceed the bandwidth used without Early feedback.
Early RTCPパケットを予定しているなら、その後新しいtn(tn=tp+2*T_rr)と新しいtp(_tp=tp+T rr)を持つためにそれに従って、次のRegular RTCPパケットのための時間帯をアップデートしなければなりません。 これは、Earlyフィードバックで使用される短期的な平均したRTCP帯域幅がEarlyフィードバックなしで使用される帯域幅を超えていないのを保証するためのものです。
event to
report
detected
|
| RTCP feedback range
| (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( |
| t0 te |
tp tn
\_______ ________/
\/
T_dither_max
検出されていると報告する出来事| | RTCPフィードバック範囲| (T_最大_fb_遅れ) vXXXXXXXXXXXXXXXXXXXXXXXXXXX) ) |---+--------+-------------+-----+------------| |--------+--->|、|、|、| ( ( | | t0Te| tp tn\_______ ________/\/T_震え_最大
Figure 2: Event report and parameters for Early RTCP scheduling
図2: イベントレポートとEarly RTCPスケジューリングのためのパラメタ
3.5. AVPF RTCP Scheduling Algorithm
3.5. AVPF RTCPスケジューリングアルゴリズム
Let S0 be an active sender (out of S senders) and let N be the number of receivers with R being one of these receivers.
S0に活発な送付者(S送付者からの)であり、Nが受信機の数であることをこれらの受信機の1つであるRでさせてください。
Assume that R has verified that using feedback mechanisms is reasonable at the current constellation (which is highly application specific and hence not specified in this document).
Rが、フィードバック・メカニズムを使用するのが現在の星座(本書ではアプリケーション非常に特有でしたがって、指定されていない)が妥当であることを確かめたと仮定してください。
Assume further that T_rr_interval is 0, if no minimal interval between Regular RTCP packets is to be enforced, or T_rr_interval is set to some meaningful value, as given by the application. This value then denotes the minimal interval between Regular RTCP packets.
T_rr_間隔が0であるとさらに仮定してください、Regular RTCPパケットでどんな最小量の間隔も実施してはいけないか、またはT_rr_間隔が何らかの重要な値に設定されるなら、アプリケーションで与えるように。 そして、この値はRegular RTCPパケットの最小量の間隔を指示します。
With this, a receiver R MUST use the following rules for transmitting one or more FB messages as minimal or full compound RTCP packet.
これで、受信機Rは、最小量としての1つ以上のFBメッセージか完全な合成RTCPパケットを送るのに以下の規則を使用しなければなりません。
Ott, et al. Standards Track [Page 14] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[14ページ]。
3.5.1. Initialization
3.5.1. 初期設定
Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not-a- Number, i.e., some invalid value that can be distinguished from a valid time).
初めは、Rはセットしなければなりません。__早い=TRUEとt rr_最終=NaNを許容してください(-1数ではありません、それがすなわち何らかの無効の値であることができることが有効な時間を区別しました)。
Furthermore, the initialization of the RTCP variables as per [1] applies except for the initial value for Tmin. For a point-to-point session, the initial Tmin is set to 0. For a multiparty session, Tmin is initialized to 1.0 seconds.
その上、Tminのための初期の値を除いて、[1]に従ってRTCP変数の初期化は適用されます。 二地点間セッションのために、初期のTminは0に用意ができています。 「マルチ-パーティー」セッションのために、Tminは1.0秒まで初期化されます。
3.5.2. Early Feedback Transmission
3.5.2. 早めのフィードバック送信
Assume that R had scheduled the last Regular RTCP RR packet for transmission at tp (and sent or suppressed this packet at tp) and has scheduled the next transmission (including possible reconsideration as per [1]) for tn = tp + T_rr. Assume also that the last Regular RTCP packet transmission has occurred at t_rr_last.
Rがtp(そして、tpでこのパケットを送るか、または抑圧する)のトランスミッションのために最後のRegular RTCP RRパケットの計画をして、次のトランスミッションの計画をしたと仮定してください。(tnのための[1])に従って可能な再考を含んでいるのは_tp+T rrと等しいです。 また、最後のRegular RTCPパケット伝送が_最後にt_rrに起こったと仮定してください。
The Early Feedback algorithm then comprises the following steps:
次に、Early Feedbackアルゴリズムは以下のステップを包括します:
1. At time t0, R detects the need to transmit one or more FB
messages, e.g., because media "units" need to be ACKed or NACKed,
and finds that providing the feedback information is potentially
useful for the sender.
1. 時間t0のときに、Rは、例えば、メディア「ユニット」が、ACKedかNACKedである必要があるので1つ以上のFBメッセージを送る必要性を見つけて、フィードバック情報を提供するのが潜在的に送付者の役に立つのがわかります。
2. R first checks whether there is already a compound RTCP packet
containing one or more FB messages scheduled for transmission
(either as Early or as Regular RTCP packet).
2. Rは、最初に、トランスミッション(Earlyとした、または、Regular RTCPパケットとした)のために予定されていた1つ以上のFBメッセージを含む合成RTCPパケットが既にあるかどうかチェックします。
2a) If so, the new FB message MUST be included in the scheduled
packet; the scheduling of the waiting compound RTCP packet
MUST remain unchanged. When doing so, the available feedback
information SHOULD be merged to produce as few FB messages as
possible. This completes the course of immediate actions to
be taken.
2a) そうだとすれば、予定されているパケットに新しいFBメッセージを含まなければなりません。 待ち合成RTCPパケットのスケジューリングは変わりがあってはいけません。 そのように、利用可能なフィードバック情報SHOULDをするときには、できるだけわずかなFBメッセージしか出さないように合併されてください。 これは、取るために即座の行動のコースを完成します。
2b) If no compound RTCP packet is already scheduled for
transmission, a new (minimal or full) compound RTCP packet
MUST be created and the minimal interval for T_dither_max MUST
be chosen as follows:
2b) 合成RTCPパケットが全くトランスミッションのために既に予定されないなら、新しい(最小量の、または、完全な)合成RTCPパケットを作成しなければなりません、そして、以下の通りT_震え_最大のための最小量の間隔を選ばなければなりません:
i) If the session is a point-to-point session, then
i) 次に、セッションが二地点間セッションであるなら
T_dither_max = 0.
T_震え_最大=0。
Ott, et al. Standards Track [Page 15] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[15ページ]。
ii) If the session is a multiparty session, then
ii) 次に、セッションが「マルチ-パーティー」セッションであるなら
T_dither_max = l * T_rr
_T_震え_最大=l*T rr
with l=0.5.
l=0.5で。
The value for T_dither_max MAY be calculated differently
(e.g., based upon RTT), which MUST then be specified in a
future document. Such a future specification MUST ensure that
all RTP receivers use the same mechanism to calculate
T_dither_max.
T_震え_最大のための値は異なっ(例えば、RTTに基づいている)て計算されるかもしれません(次に、将来のドキュメントで指定しなければなりません)。 そのような将来の仕様は、すべてのRTP受信機がT_震え_最大について計算するのに同じメカニズムを使用するのを確実にしなければなりません。
The values given above for T_dither_max are minimal values.
Application-specific feedback considerations may make it
worthwhile to increase T_dither_max beyond this value. This
is up to the discretion of the implementer.
T_震え_最大のために上に与えられた値は最小量の値です。 アプリケーション特有のフィードバック問題で、T_震え_最大をこの値を超えたところまで増加させるのは価値があるようになるかもしれません。 これはimplementerの思慮深さまで達しています。
3. Then, R MUST check whether its next Regular RTCP packet would be
within the time bounds for the Early RTCP packet triggered at t0,
i.e., if t0 + T_dither_max > tn.
3. 次に、Rは、t0で引き起こされたEarly RTCPパケットがないかどうか時間領域の中に次のRegular RTCPパケットがあるかをチェックしなければなりません、すなわち、t0+T_震え_が>tnに最大限にするなら。
3a) If so, an Early RTCP packet MUST NOT be scheduled; instead,
the FB message(s) MUST be stored to be included in the Regular
RTCP packet scheduled for tn. This completes the course of
immediate actions to be taken.
3a) そうだとすれば、Early RTCPパケットを予定してはいけません。 代わりにFBメッセージ tnのために予定されていたRegular RTCPパケットに含まれるように格納しなければなりません。 これは、取るために即座の行動のコースを完成します。
3b) Otherwise, the following steps are carried out.
3b) さもなければ、以下のステップが行われます。
4. R MUST check whether it is allowed to transmit an Early RTCP
packet, i.e., allow_early == TRUE, or not.
4. Rが、それがEarly RTCPパケットを伝えることができるかどうかチェックしなければならなくて、すなわち、_早い=TRUEを許容してください。
4a) If allow_early == FALSE, then R MUST check the time for the
next scheduled Regular RTCP packet:
4a) _早い=FALSEを許容してください、そして、次に、Rは次の予定されているRegular RTCPパケットのための時間をチェックしなければなりません:
1. If tn - t0 < T_max_fb_delay, then the feedback could still
be useful for the sender, despite the late reporting.
Hence, R MAY create an RTCP FB message to be included in
the Regular RTCP packet for transmission at tn.
1. t0<T_がtnに_fb_遅れに最大限にするなら、報告しますが、遅いフィードバックはまだ送付者の役に立っているかもしれません。 したがって、RはトランスミッションのためにRegular RTCPパケットに含まれるべきRTCP FBメッセージをtnに作成するかもしれません。
2. Otherwise, R MUST discard the RTCP FB message.
2. さもなければ、RはRTCP FBメッセージを捨てなければなりません。
This completes the immediate course of actions to be taken.
これは、取るために即座の行動を終了します。
4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
packet for te = t0 + RND * T_dither_max with RND being a
pseudo random function evenly distributed between 0 and 1.
4b) _早い=TRUEを許容してください、そして、次に、Rはt0+RND*t_震え_Te=最大のために均等に0と1の間に分配された疑似確率関数であるRNDでEarly RTCPパケットの計画をしなければなりません。
Ott, et al. Standards Track [Page 16] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[16ページ]。
5. R MUST detect overlaps in FB messages received from other members
of the RTP session and the FB messages R wants to send.
Therefore, while a member of the RTP session, R MUST continuously
monitor the arrival of (minimal) compound RTCP packets and store
each FB message contained in these RTCP packets for at least
T_retention. When scheduling the transmission of its own FB
message following steps 1 through 4 above, R MUST check each of
the stored and newly received FB messages from the RTCP packets
received during the interval [t0 - T_retention ; te] and act as
follows:
5. RはRTPセッションの他のメンバーから受け取られたFBメッセージとRが送りたがっているFBメッセージでのオーバラップを検出しなければなりません。 したがって、RTPセッションのメンバーである間、Rは、絶え間なく(最小量)の合成RTCPパケットの到着をモニターして、少なくともT_保有のためにこれらのRTCPパケットに含まれたそれぞれのFBメッセージを格納しなければなりません。 上の4を通した方法1に従って、それ自身のFBメッセージの伝達の計画をするとき、Rは以下の間隔[t0--T_保有; Te]と行為の間に受け取られたRTCPパケットからのそれぞれの格納された、新たに受け取られたFBメッセージをチェックしなければなりません:
5a) If R understands the received FB message's semantics and the
message contents is a superset of the feedback R wanted to
send, then R MUST discard its own FB message and MUST re-
schedule the next Regular RTCP packet transmission for tn (as
calculated before).
5a) Rが、受信されたFBメッセージの意味論とメッセージコンテンツがRが送りたがっていたフィードバックのスーパーセットであることを理解しているなら、Rは、それ自身のFBメッセージを捨てなければならなくて、tn(以前計算されるとしての)のために次のRegular RTCPパケット伝送の再計画をしなければなりません。
5b) If R understands the received FB message's semantics and the
message contents is not a superset of the feedback R wanted to
send, then R SHOULD transmit its own FB message as scheduled.
If there is an overlap between the feedback information to
send and the feedback information received, the amount of
feedback transmitted is up to R: R MAY leave its feedback
information to be sent unchanged, R MAY as well eliminate any
redundancy between its own feedback and the feedback received
so far from other session members.
5b) Rが、受信されたFBメッセージの意味論とメッセージコンテンツがRが送りたがっていたフィードバックのスーパーセットでないことを理解しているなら、R SHOULDは予定されているようにそれ自身のFBメッセージを送ります。 送るフィードバック情報と情報が受けたフィードバックの間には、オーバラップがあれば、伝えられたフィードバックの量はR次第です: Rは、フィードバック情報が変わりがない状態で送られるのを残すかもしれなくて、Rは今までのところ他のセッションメンバーから受け取られているそれ自身のフィードバックとフィードバックの間のどんな冗長も排除するほうがよいです。
5c) If R does not understand the received FB message's semantics,
R MAY keep its own FB message scheduled as an Early RTCP
packet, or R MAY re-schedule the next Regular RTCP packet
transmission for tn (as calculated before) and MAY append the
FB message to the now regularly scheduled RTCP message.
5c) Rが、Rが受信されたFBメッセージの意味論を理解しないなら、Early RTCPパケットとしてそれ自身のFBメッセージを予定し続けるかもしれないか、Rは、tn(以前計算されるとしての)のために次のRegular RTCPパケット伝送の時期変更して、現在定期的に予定されているRTCPメッセージにFBメッセージを追加するかもしれません。
Note: With 5c), receiving unknown FB messages may not lead to
feedback suppression at a particular receiver. As a
consequence, a given event may cause M different types of FB
messages (which are all appropriate but not mutually
understood) to be scheduled, so that a "large" receiver group
may effectively be partitioned into at most M groups. Among
members of each of these M groups, feedback suppression will
occur following 5a and 5b but no suppression will happen
across groups. As a result, O(M) RTCP FB messages may be
received by the sender. Hence, there is a chance for a very
limited feedback implosion. However, as sender(s) and all
receivers make up the same application using the same (set of)
codecs in the same RTP session, only little divergence in
semantics for FB messages can safely be assumed and,
therefore, M is assumed to be small in the general case.
以下に注意してください。 特定の受信機でフィードバック抑圧に通じないかもしれません。5c) 結果として、当然のことの出来事で、Mの異なったタイプに関するFBメッセージ(どれがすべて適切ですが、互いに適切であるというわけではないかは分かった)を予定するかもしれないという未知のFBメッセージを受け取るそうで、事実上、そのa「大きい」受信機グループは高々Mグループに仕切られるかもしれません。 それぞれのこれらのメンバーの中では、Mは分類されますが、5aと5bに続いて、フィードバック抑圧は起こるでしょうが、抑圧は全くグループの向こう側に起こらないでしょう。 結果、O(M)として RTCP FBメッセージは送付者によって受け取られるかもしれません。 したがって、非常に限られたフィードバック内部破裂のための見込みがあります。 しかしながら、送付者とすべての受信機が同じRTPセッションのときに同じように(セットされる)コーデックを使用することで同じアプリケーションを作るとき、ほとんど安全にFBメッセージのための意味論における分岐だけを思うことができません、そして、したがって、Mが一般的な場合で小さいと思われます。
Ott, et al. Standards Track [Page 17] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[17ページ]。
Given further that the O(M) FB messages are randomly
distributed over a time interval of T_dither_max, we find that
the resulting limited number of extra compound RTCP packets
(a) is assumed not to overwhelm the sender and (b) should be
conveyed as all contain complementary pieces of information.
O(M) FBメッセージがT_震え_最大の時間間隔の間手当たりしだいに分配されるなら、私たちは、余分な合成RTCPパケット(a)の結果として起こる限られた数が送付者を圧倒しないと思われて、すべてが補足的な情報を含んでいて(b)が運ばれるべきであるのがわかりました。
6. If R's FB message(s) was not suppressed by other receiver FB
messages as per 5, when te is reached, R MUST transmit the
(minimal) compound RTCP packet containing its FB message(s). R
then MUST set allow_early = FALSE, MUST recalculate tn = tp +
2*T_rr, and MUST set tp to the previous tn. As soon as the newly
calculated tn is reached, regardless whether R sends its next
Regular RTCP packet or suppresses it because of T_rr_interval, it
MUST set allow_early = TRUE again.
6. Teに達しているとき、RのFBメッセージが5に従って他の受信機FBメッセージによって削除されなかったなら、RはFBメッセージを含む(最小量)の合成RTCPパケットを伝えなければなりません。 Rはそしてときに設定しなければなりません。設定されて、_前の=FALSEを許容してください、そして、recalculate tnはtp+2*と等しくなければなりません。T_は前のtnへのtpをrrして、設定しなければなりません。 新たに計算されたtnに達していて、Rが次のRegular RTCPパケットを送るか、またはT_rr_間隔のためにそれを抑圧することにかかわらず不注意に、セットしなければならないとすぐに、もう一度_前の=TRUEを許容してください。
3.5.3. Regular RTCP Transmission
3.5.3. 定期的なRTCPトランスミッション
Full compound RTCP packets MUST be sent in regular intervals. These packets MAY also contain one or more FB messages. Transmission of Regular RTCP packets is scheduled as follows:
一定の間隔で完全な合成RTCPパケットを送らなければなりません。 また、これらのパケットは1つ以上のFBメッセージを含むかもしれません。 Regular RTCPパケットのトランスミッションは以下の通り予定されています:
If T_rr_interval == 0, then the transmission MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP packet transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. The Regular RTCP packet is transmitted after timer reconsideration. Whenever a Regular RTCP packet is sent or suppressed, allow_early MUST be set to TRUE and tp, tn MUST be updated as per [1]. After the first transmission of a Regular RTCP packet, Tmin MUST be set to 0.
T_rr_間隔=0であるなら、トランスミッションは、このドキュメントのセクション3.2と3.4の指定されるとしての規則に従わなければならなくて、セクション3.5.2で指定されたtnの調整を固く守らなければなりません(すなわち、Early RTCPパケット伝送が起こったなら、1つの正透過をサボってください)。 tnに[1]に従って達しているとき、タイマ再考は行われます。 Regular RTCPパケットはタイマ再考の後に伝えられます。 tp、_が、Regular RTCPパケットを送るか、または抑圧するのを許容するときはいつも、早いのが、TRUEへのセットであるに違いなく、[1]に従ってtnをアップデートしなければなりません。 Regular RTCPパケットの最初のトランスミッションの後に、Tminは0に用意ができなければなりません。
If T_rr_interval != 0, then the calculation for the transmission times MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. After timer reconsideration, the following actions are taken:
T_rr_間隔!=0であるなら、トランスミッション時間の計算は、このドキュメントのセクション3.2と3.4の指定されるとしての規則に従わなければならなくて、セクション3.5.2で指定されたtnの調整を固く守らなければなりません(すなわち、Early RTCPトランスミッションが起こったなら、1つの正透過をサボってください)。 tnに[1]に従って達しているとき、タイマ再考は行われます。 タイマ再考の後に、以下の行動を取ります:
1. If no Regular RTCP packet has been sent before (i.e., if t_rr_last
== NaN), then a Regular RTCP packet MUST be scheduled. Stored FB
messages MAY be included in the Regular RTCP packet. After the
scheduled packet has been sent, t_rr_last MUST be set to tn. Tmin
MUST be set to 0.
1. 以前Regular RTCPパケットを全く送ったことがないなら(すなわち、t_rr_最終=NaNであるなら)、Regular RTCPパケットを予定しなければなりません。 格納されたFBメッセージはRegular RTCPパケットに含まれるかもしれません。 予定されているパケットを送った後に、t_rr_は最後にtnに用意ができなければなりません。 Tminは0に用意ができなければなりません。
Ott, et al. Standards Track [Page 18] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[18ページ]。
2. Otherwise, a temporary value T_rr_current_interval is calculated
as follows:
2. さもなければ、一時的な値のT_rr_電流_間隔は以下の通り計算されます:
T_rr_current_interval = RND*T_rr_interval
T_rr_電流_間隔=RND*T_rr_間隔
with RND being a pseudo random function evenly distributed between
0.5 and 1.5. This dithered value is used to determine one of the
following alternatives:
RNDと共に、疑似確率関数であることは0.5〜1.5を均等に分配しました。 このうろたえた値は以下の代替手段の1つを決定するのに使用されます:
2a) If t_rr_last + T_rr_current_interval <= tn, then a Regular
RTCP packet MUST be scheduled. Stored RTCP FB messages MAY be
included in the Regular RTCP packet. After the scheduled
packet has been sent, t_rr_last MUST be set to tn.
2a) t_rr_最終+T_rr_電流_間隔<がtnと等しいなら、Regular RTCPパケットを予定しなければなりません。 格納されたRTCP FBメッセージはRegular RTCPパケットに含まれるかもしれません。 予定されているパケットを送った後に、t_rr_は最後にtnに用意ができなければなりません。
2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages
have been stored and are awaiting transmission, an RTCP packet
MUST be scheduled for transmission at tn. This RTCP packet
MAY be a minimal or a Regular RTCP packet (at the discretion
of the implementer), and the compound RTCP packet MUST include
the stored RTCP FB message(s). t_rr_last MUST remain
unchanged.
2b) t_rr_最終+T_rr_電流_間隔>tnとRTCP FBメッセージが格納されて、トランスミッションを待っているなら、tnのトランスミッションのためにRTCPパケットを予定しなければなりません。 このRTCPパケットは最小量かa Regular RTCPパケットであるかもしれません(implementerの裁量における)、そして、合成RTCPパケットは格納されたRTCP FBメッセージを含まなければなりません。t_rr_は最後に変わりがないままで残らなければなりません。
2c) Otherwise (if t_rr_last + T_rr_current_interval > tn but no
stored RTCP FB messages are awaiting transmission), the
compound RTCP packet MUST be suppressed (i.e., it MUST NOT be
scheduled). t_rr_last MUST remain unchanged.
2c) さもなければ(t_rr_最終+T_rr_電流_間隔>tnが待ちますが、何か格納されたRTCP FBメッセージがトランスミッションを待っていないなら)、合成RTCPパケットを抑圧しなければなりません(すなわち、それを予定してはいけません)。t_rr_は最後に変わりがないままで残らなければなりません。
In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST be set to TRUE (possibly after sending the Regular RTCP packet) and tp and tn MUST be updated following the rules of [1] except for the five second minimum.
全部で、5を除いた[1]のアップデートされた約束を守りが2番目の最小限であったに違いないなら上の(1、2a、2b、および2c)が_早く許容する4つのケースをTRUE(ことによるとRegular RTCPパケットを送った後の)、tp、およびtnに設定しなければなりません。
3.5.4. Other Considerations
3.5.4. 他の問題
If T_rr_interval != 0, then the timeout calculation for RTP/AVPF entities (Section 6.3.5 of [1]) MUST be modified to use T_rr_interval instead of Tmin for computing Td and thus M*Td for timing out RTP entities.
[1])で変更していなければなりません。次に、T_のrr_間隔!=0、RTP/AVPF実体のためのタイムアウト計算である、(セクション6.3 .5 Tdを計算するためのTminとその結果、M*の代わりにT_rr_間隔を費やしてください、そして、タイミングアウトRTP実体のためのTd。
Whenever a compound RTCP packet is sent or received -- minimal or full compound, Early or Regular -- the avg_rtcp_size variable MUST be updated accordingly (see [1]) and subsequent computations of tn MUST use the new avg_rtcp_size.
合成RTCPパケットを送るか、または受け取る(最小量の、または、完全な化合物、EarlyまたはRegular)ときはいつも、それに従って、avg_rtcp_サイズ変数をアップデートしなければなりません。(tnの[1])とその後の計算が新しい_avg_rtcpサイズを使用しなければならないのを確実にしてください。
Ott, et al. Standards Track [Page 19] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[19ページ]。
3.6. Considerations on the Group Size
3.6. グループサイズに関する問題
This section provides some guidelines to the group sizes at which the various feedback modes may be used.
このセクションは様々なフィードバックモードが使用されるかもしれないグループサイズにいくつかのガイドラインを提供します。
3.6.1. ACK Mode
3.6.1. ACKモード
The RTP session MUST have exactly two members and this group size MUST NOT grow, i.e., it MUST be point-to-point communications. Unicast addresses SHOULD be used in the session description.
RTPセッションには、ちょうど2人のメンバーがいなければなりません、そして、このグループサイズは成長してはいけません、そして、すなわち、それは二地点間コミュニケーションであるに違いありません。 ユニキャストは中古のコネがセッション記述であったならSHOULDを記述します。
For unidirectional as well as bi-directional communication between two parties, 2.5% of the RTP session bandwidth is available for RTCP traffic from the receivers including feedback. For a 64-kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an average of 96 bytes (=768 bits) per RTCP packet, a receiver can report 2 events per second back to the sender. If acknowledgements for 10 events are collected in each FB message, then 20 events can be acknowledged per second. At 256 kbit/s, 8 events could be reported per second; thus, the ACKs may be sent in a finer granularity (e.g., only combining three ACKs per FB message).
2回のパーティーの双方向のコミュニケーションと同様に単方向、RTPセッション帯域幅の2.5%はフィードバックを含む受信機からのRTCP交通に利用可能です。 これがRTCPのために1,600ビット/sもたらす64-kbit/sの流れのために。 私たちがRTCPパケットあたり平均96バイト(= 768ビット)を仮定するなら、受信機は送付者への2番目の後部あたり2回の出来事を報告できます。 10回の出来事のための承認がそれぞれのFBメッセージに集められるなら、1秒単位で20回の出来事を承認できます。 256kbit/sでは、1秒単位で8回の出来事を報告できるでしょう。 したがって、よりすばらしい粒状(例えば、FBメッセージあたり3ACKsしか結合しない)でACKsを送るかもしれません。
From 1 Mbit/s upwards, a receiver would be able to acknowledge each individual frame (not packet!) in a 30-fps video stream.
1メガビット/sから、上向きに、受信機は30-fpsビデオストリームでそれぞれの個々のフレーム(パケットでない!)を承認できるでしょう。
ACK strategies MUST be defined to work properly with these bandwidth limitations. An indication whether or not ACKs are allowed for a session and, if so, which ACK strategy should be used, MAY be conveyed by out-of-band mechanisms, e.g., media-specific attributes in a session description using SDP.
これらの帯域幅制限で適切に働くためにACK戦略を定義しなければなりません。 ACKsがセッションのために許容されているかどうかと、そうだとすれば、ACK戦略がどれであるべきであるかが使用されて、バンドで出ているメカニズムメディア詳細(例えば、SDPを使用するセッション記述における属性)によって運ばれるかもしれないという指示。
3.6.2. NACK Mode
3.6.2. ナックMode
Negative acknowledgements (and the other types of feedback exhibiting similar reporting characteristics) MUST be used for all sessions with a group size that may grow larger than two. Of course, NACKs MAY be used for point-to-point communications as well.
2より大きくなるかもしれないグループサイズとのすべてのセッションに、否定的承認(そして、同様の報告の特性を示す他のタイプのフィードバック)を使用しなければなりません。 もちろん、NACKsはまた、二地点間コミュニケーションに使用されるかもしれません。
Whether or not the use of Early RTCP packets should be considered depends upon a number of parameters including session bandwidth, codec, special type of feedback, and number of senders and receivers.
Early RTCPパケットの使用が考えられるべきであるかどうかがセッション帯域幅、コーデック、特別なタイプのフィードバック、送付者の数、および受信機を含む多くのパラメタに依存します。
The most important parameters when determining the mode of operation are the allowed minimal interval between two compound RTCP packets (T_rr) and the average number of events that presumably need reporting per time interval (plus their distribution over time, of course). The minimum interval can be derived from the available RTCP bandwidth and the expected average size of an RTCP packet. The
運転モードを決定するとき、最も重要なパラメタは、2つの合成RTCPパケットの許容最小量の間隔(T_rr)とおそらく、時間間隔単位で報告する必要がある出来事の平均した数(時間がたつにつれての彼らの分配、もちろん)です。 利用可能なRTCP帯域幅とRTCPパケットの予想された平均のサイズから最小間隔を得ることができます。 The
Ott, et al. Standards Track [Page 20] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[20ページ]。
number of events to report (e.g., per second) may be derived from the packet loss rate and sender's rate of transmitting packets. From these two values, the allowable group size for the Immediate Feedback mode can be calculated.
パケット損失率と送付者の伝えるパケットのレートから報告する(例えば、1秒単位で)出来事の数を得るかもしれません。 これらの2つの値から、Immediate Feedbackモードのための許容できるグループサイズについて計算できます。
As stated in Section 3.3:
セクション3.3に述べられているように:
Let N be the average number of events to be reported per interval
T by a receiver, B the RTCP bandwidth fraction for this particular
receiver, and R the average RTCP packet size, then the receiver
operates in Immediate Feedback mode as long as N<=B*T/R.
Bの受信機によって間隔T単位で報告されるべき出来事の平均した数、この特定の受信機のためのRTCP帯域幅断片、およびR平均したRTCPがパケットサイズであったならNをさせてください、そして、次に、受信機はN<=B*T/Rと同じくらい長い間、Immediate Feedbackモードで動作します。
The upper bound for the Early RTCP mode then solely depends on the acceptable quality degradation, i.e., how many events per time interval may go unreported.
次に、Early RTCPモードのための上限は唯一合格品質退行によります、すなわち、いくつの時間間隔あたりの出来事が報告されずに終わるかもしれないか。
As stated in Section 3.3:
セクション3.3に述べられているように:
Using the above notation, Early RTCP mode can be roughly
characterized by N > B*T/R as "lower bound". An estimate for an
upper bound is more difficult. Setting N=1, we obtain for a given
R and B the interval T = R/B as average interval between events to
be reported. This information can be used as a hint to determine
whether or not early transmission of RTCP packets is useful.
上の記法を使用して、N>B*T/Rは「下界」としておよそEarly RTCPモードを特徴付けることができます。 上限のための見積りは、より難しいです。 N=1を設定して、私たちは、報告されるために出来事の平均した間隔として間隔T=R/Bを当然のことRとBに得ます。 RTCPパケットの早めのトランスミッションが役に立つかどうか決定するのにヒントとしてこの情報を使用できます。
Example: If a 256-kbit/s video with 30 fps is transmitted through a network with an MTU size of some 1,500 bytes, then, in most cases, each frame would fit in into one packet leading to a packet rate of 30 packets per second. If 5% packet loss occurs in the network (equally distributed, no inter-dependence between receivers), then each receiver will, on average, have to report 3 packets lost each two seconds. Assuming a single sender and more than three receivers, this yields 3.75% of the RTCP bandwidth allocated to the receivers and thus 9.6 kbit/s. Assuming further a size of 120 bytes for the average compound RTCP packet allows 10 RTCP packets to be sent per second or 20 in two seconds. If every receiver needs to report three lost packets per two seconds, this yields a maximum group size of 6-7 receivers if all loss events are reported. The rules for transmission of Early RTCP packets should provide sufficient flexibility for most of this reporting to occur in a timely fashion.
例: 次に、30fpsがある256-kbit/sビデオが多くの場合ネットワークを通しておよそ1,500バイトのMTUサイズで送られるなら、各フレームは1秒あたり30のパケットのパケットレートに通じる1つのパケットに適合するでしょう。 5%のパケット損失がネットワークで起こる、(等しく分配されている、受信機の間の相互の依存がありません)、そして、各受信機は、3つのパケットが各2秒単位で損をしたと平均的に報告しなければならないでしょう。 独身の送付者であり、3台以上の受信機でありこれがもたらされるとRTCP帯域幅の3.75%が受信機とその結果、9.6kbit/sに割り当てた仮定すること。 平均した合成RTCPパケットのためにさらに120バイトのサイズを仮定すると、1秒単位で送られる10のRTCPパケットか2秒で20が許容されます。 あらゆる受信機が、3が2秒単位でパケットを失ったと報告する必要があるなら、すべての損失出来事が報告されるなら、これは6-7 受信機の最大のグループサイズをもたらします。 Early RTCPパケットのトランスミッションのための規則はこの報告の大部分の直ちに起こることができるくらいの柔軟性を提供するべきです。
Extending this example to determine the upper bound for Early RTCP mode could lead to the following considerations: assume that the underlying coding scheme and the application (as well as the tolerant users) allow on the order of one loss without repair per two seconds. Thus, the number of packets to be reported by each receiver decreases to two per two seconds and increases the group size to 10. Assuming further that some number of packet losses are correlated, feedback
Early RTCPモードのために上限を決定するためにこの例を広げるのは以下の問題に通じるかもしれません: 基本的なコード構成とアプリケーション(許容性があるユーザと同様に)が1つの注文のときに2秒あたりの修理なしで損失を許容すると仮定してください。 したがって、各受信機によって報告されるべきパケットの数は、2秒あたり2まで減少して、グループサイズを10まで増加させます。 さらに、それが関連する、何らかの数のパケット損失、フィードバックであると仮定します。
Ott, et al. Standards Track [Page 21] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[21ページ]。
traffic is further reduced and group sizes of some 12 to 16 (maybe even 20) can be reasonably well supported using Early RTCP mode. Note that all these considerations are based upon statistics and will fail to hold in some cases.
さらに交通を抑えます、そして、Early RTCPモードを使用することで合理的に何らかの12〜16(多分20さえ)のグループサイズをよく支持できます。 これらのすべての問題が統計に基づいていて、いくつかの場合、成立しないことに注意してください。
3.7. Summary of Decision Steps
3.7. 決定ステップの概要
3.7.1. General Hints
3.7.1. 一般ヒント
Before even considering whether or not to send RTCP feedback information, an application has to determine whether this mechanism is applicable:
フィードバック情報をRTCPに送るかどうか考える前にさえ、アプリケーションは、このメカニズムが適切であるかどうか決定しなければなりません:
1) An application has to decide whether -- for the current ratio of
packet rate with the associated (application-specific) maximum
feedback delay and the currently observed round-trip time (if
available) -- feedback mechanisms can be applied at all.
1) アプリケーションが決めなければならない、関連している(アプリケーション特有の)最大のフィードバック遅れと現在観測された往復の時間(利用可能であるなら)があるパケットレートの流動比率 -- フィードバック・メカニズムを全く適用できます。
This decision may be based upon (and dynamically revised
following) RTCP reception statistics as well as out-of-band
mechanisms.
この決定はバンドで出ているメカニズムと同様に(そして、ダイナミックに改訂された次の事柄)RTCPレセプション統計に基づくかもしれません。
2) The application has to decide -- for a certain observed error
rate, assigned bandwidth, frame/packet rate, and group size --
whether (and which) feedback mechanisms can be applied.
2) そして、アプリケーションはある観測された誤り率、割り当てられた帯域幅、フレーム/パケットレート、およびグループサイズのために決めなければなりません--、(どれ、)、フィードバック・メカニズムを適用できるか。
Regular RTCP reception statistics provide valuable input to this
step, too.
通常のRTCPレセプション統計は貴重な入力をこのステップにも提供します。
3) If the application decides to send feedback, the application has
to follow the rules for transmitting Early RTCP packets or Regular
RTCP packets containing FB messages.
3) アプリケーションが、フィードバックを送ると決めるなら、アプリケーションは、FBメッセージを含むEarly RTCPパケットかRegular RTCPパケットを伝えるために約束を守らなければなりません。
4) The type of RTCP feedback sent should not duplicate information
available to the sender from a lower layer transport protocol.
That is, if the transport protocol provides negative or positive
acknowledgements about packet reception (such as DCCP), the
receiver should avoid repeating the same information at the RTCP
layer (i.e., abstain from sending Generic NACKs).
4) フィードバックが送ったRTCPのタイプは下層トランスポート・プロトコルから送付者にとって、利用可能な情報をコピーするべきではありません。 すなわち、トランスポート・プロトコルがパケットレセプション(DCCPなどの)に関して否定しているか肯定している承認を提供するなら、受信機は、RTCP層で同じ情報を繰り返すのを避けるはずです(すなわち、送付Generic NACKsを慎んでください)。
3.7.2. Media Session Attributes
3.7.2. メディアセッション属性
Media sessions are typically described using out-of-band mechanisms to convey transport addresses, codec information, etc., between sender(s) and receiver(s). Such a mechanism is two-fold: a format used to describe a media session and another mechanism for transporting this description.
メディアセッションは、輸送アドレス、コーデック情報などを送付者と受信機の間に伝えるのにバンドの外でメカニズムを使用することで通常説明されます。 そのようなメカニズムは二面です: 形式は、この記述を輸送するために以前はよくメディアセッションと別のメカニズムについて説明していました。
Ott, et al. Standards Track [Page 22] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[22ページ]。
In the IETF, the Session Description Protocol (SDP) is currently used to describe media sessions while protocols such as SIP, Session Announcement Protocol (SAP), Real Time Streaming Protocol (RTSP), and HTTP (among others) are used to convey the descriptions.
IETFでは、SIPや、Session Announcementプロトコル(SAP)や、レアルTime Streamingプロトコル(RTSP)や、HTTP(特に)などのプロトコルは記述を伝えるのに使用されますが、Session記述プロトコル(SDP)は、現在、メディアセッションについて説明するのに使用されます。
A media session description format MAY include parameters to indicate that RTCP feedback mechanisms are supported in this session and which of the feedback mechanisms MAY be applied.
メディアセッション記述形式はRTCPフィードバック・メカニズムがこのセッションのときにサポートされるのを示すフィードバック・メカニズムについて応用されるかもしれないパラメタを含むかもしれません。
To do so, the profile "AVPF" MUST be indicated instead of "AVP". Further attributes may be defined to show which type(s) of feedback are supported.
そうするために、"AVP"の代わりにプロフィール"AVPF"を示さなければなりません。 さらなる属性は、どのタイプのフィードバックが支持されるかを示すために定義されるかもしれません。
Section 4 contains the syntax specification to support RTCP feedback with SDP. Similar specifications for other media session description formats are outside the scope of this document.
セクション4はSDPと共にサポートRTCPフィードバックに構文仕様を含みます。 このドキュメントの範囲の外に他のメディアセッション記述形式のための同様の仕様があります。
4. SDP Definitions
4. SDP定義
This section defines a number of additional SDP parameters that are used to describe a session. All of these are defined as media-level attributes.
このセクションはセッションについて説明するのに使用される多くの追加SDPパラメタを定義します。 これらのすべてがメディアレベル属性と定義されます。
4.1. Profile Identification
4.1. プロフィール識別
The AV profile defined in [4] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF".
[4]で定義されたAVプロフィールが文脈に"AVP"と呼ばれる、例えば、セッション記述プロトコル(SDP)[3]。 本書では指定されたプロフィールは"AVPF"と呼ばれます。
Feedback information following the modified timing rules as specified in this document MUST NOT be sent for a particular media session unless the description for this session indicates the use of the "AVPF" profile (exclusively or jointly with other AV profiles).
このセッションのための記述が"AVPF"というプロフィール(排他的か他のAVプロフィールと一緒の)の使用を示さない場合、特定のメディアセッションのために本書では指定されるとして変更されたタイミング規則に従うフィードバック情報を送ってはいけません。
4.2. RTCP Feedback Capability Attribute
4.2. RTCPフィードバック能力属性
A new payload format-specific SDP attribute is defined to indicate the capability of using RTCP feedback as specified in this document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level. The "rtcp-fb" attribute MUST only be used in media sessions for which the "AVPF" is specified.
新しいペイロード形式特有のSDP属性は本書では指定されるとしてRTCPフィードバックを使用する能力を示すために定義されます: "a=rtcp-fb"。 "rtcp-fb"属性をSDPメディア属性として使用するだけでよくて、セッションレベルで提供してはいけません。 "AVPF"が指定されるメディアセッションときに"rtcp-fb"属性を使用するだけでよいです。
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB
messages MAY be used in this media session for the indicated payload
type. A wildcard payload type ("*") MAY be used to indicate that the
RTCP feedback attribute applies to all payload types. If several
types of feedback are supported and/or the same feedback shall be
"rtcp-fb"はSHOULDを結果と考えます。使用されて、どのRTCP FBメッセージがこのメディアセッションのときに示されたペイロードに使用されるかもしれないかがタイプされるのを示してください。 ワイルドカードペイロードタイプ(「*」)は、RTCPフィードバック属性がすべてのペイロードタイプに適用されるのを示すのに使用されるかもしれません。 フィードバックのいくつかのタイプが支持されて、同じフィードバックが支持されるなら
Ott, et al. Standards Track [Page 23] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[23ページ]。
specified for a subset of the payload types, several "a=rtcp-fb" lines MUST be used.
ペイロードタイプの部分集合に指定されていて、いくつかの"a=rtcp-fb"線を使用しなければなりません。
If no "rtcp-fb" attribute is specified, the RTP receivers MAY send feedback using other suitable RTCP feedback packets as defined for the respective media type. The RTP receivers MUST NOT rely on the RTP senders reacting to any of the FB messages. The RTP sender MAY choose to ignore some feedback messages.
"rtcp-fb"属性が全く指定されないなら、それぞれのメディアタイプのために定義されるように他の適当なRTCPフィードバックパケットを使用して、RTP受信機はフィードバックを送るかもしれません。 RTP受信機はFBメッセージのいずれにも反応するRTP送付者に頼ってはいけません。 RTP送付者は、いくつかのフィードバックメッセージを無視するのを選ぶかもしれません。
If one or more "rtcp-fb" attributes are present in a media session description, the RTCP receivers for the media session(s) containing the "rtcp-fb"
1つ以上の"rtcp-fb"属性がメディアセッション記述、メディアセッションのための"rtcp-fb"を含むRTCP受信機に存在しているなら
o MUST ignore all "rtcp-fb" attributes of which they do not fully
understand the semantics (i.e., where they do not understand the
meaning of all values in the "a=rtcp-fb" line);
o 彼らが完全に意味論を理解しているというわけではない(すなわち、どこで、彼らは"a=rtcp-fb"線におけるすべての値の意味を理解していませんか)すべての"rtcp-fb"属性を無視しなければなりません。
o SHOULD provide feedback information as specified in this document
using any of the RTCP feedback packets as specified in one of the
"rtcp-fb" attributes for this media session; and
o SHOULDは指定されるとしてこのメディアセッションに本書では"rtcp-fb"属性の1つにおける指定されるとしてのRTCPフィードバックパケットのどれかを使用することでフィードバック情報を提供します。 そして
o MUST NOT use other FB messages than those listed in one of the
"rtcp-fb" attribute lines.
o "rtcp-fb"属性線の1つで記載されたもの以外のFBメッセージを使用してはいけません。
When used in conjunction with the offer/answer model [8], the offerer MAY present a set of these AVPF attributes to its peer. The answerer MUST remove all attributes it does not understand as well as those it does not support in general or does not wish to use in this particular media session. The answerer MUST NOT add feedback parameters to the media description and MUST NOT alter values of such parameters. The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way. Both offerer and answerer MAY independently decide to send RTCP FB messages of only a subset of the negotiated feedback mechanisms, but they SHOULD react properly to all types of the negotiated FB messages when received.
申し出/答えモデル[8]に関連して使用されると、申出人はこれらのAVPF属性の1セットを同輩に寄贈するかもしれません。 answererはそれが一般に、それが支持しないものと同様に理解しなくしたくはありませんし、この特定のメディアセッションのときに使用したがっていないすべての属性を取り除かなければなりません。 answererはメディア記述にフィードバックパラメタを加えてはいけなくて、そのようなパラメタの値を変更してはいけません。 答えはメディアセッションのために拘束力があります、そして、申出人とanswererの両方がこのように交渉されたフィードバック・メカニズムを使用するだけでよいです。 申出人とanswererの両方が、受け取るとしかし、交渉されたフィードバック・メカニズムの部分集合、それらだけに関するメッセージをRTCP FBに送るために、SHOULDが適切に交渉されたFBメッセージのすべてのタイプに反応すると独自に決めるかもしれません。
RTP senders MUST be prepared to receive any kind of RTCP FB messages and MUST silently discard all those RTCP FB messages that they do not understand.
RTP送付者は、どんな種類のRTCP FBメッセージも受け取るように準備しなければならなくて、静かに、彼らが分からないというそれらのすべてのRTCP FBメッセージを捨てなければなりません。
The syntax of the "rtcp-fb" attribute is as follows (the feedback types and optional parameters are all case sensitive):
"rtcp-fb"属性の構文は以下の通りです(フィードバックタイプと任意のパラメタはすべて大文字と小文字を区別しています):
(In the following ABNF, fmt, SP, and CRLF are used as defined in [3].)
(以下のABNFでは、fmt、SP、およびCRLFは[3]で定義されるように使用されています。)
Ott, et al. Standards Track [Page 24] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[24ページ]。
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-構文=、「a=rtcp-fb:」 rtcp-fb-Pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
rtcp-fb-Ptは「*」と等しいです。 ワイルドカード: すべての形式/fmtに適用します。 SDP仕様では、定義されます。
rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param
rtcp-fb-val="ack"rtcp-fb-ack-param/"nack"rtcp-fb-nack-param/"trr-int"SP1*DIGIT / rtcp-fb-イドrtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-イド=1*(アルファベット数字式/「-」/"_")
rtcp-fb-param = SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-paramはSP「装置」[SPバイトストリング]/SP象徴[SPバイトストリング]/と等しいです。 空になってください。
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
SP rtcp-fb-ack-param=SP"rpsi"/「装置」[SPバイトストリング]/SP象徴[SPバイトストリング]/。 空になってください。
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
SP SP SP rtcp-fb-nack-param=SP"pli"/"sli"/"rpsi"/「装置」[SPバイトストリング]/SP象徴[SPバイトストリング]/。 空になってください。
The literals of the above grammar have the following semantics:
上の文法に関する誤字誤植には、以下の意味論があります:
Feedback type "ack":
フィードバックタイプ"ack":
This feedback type indicates that positive acknowledgements for
feedback are supported.
このフィードバックタイプは、フィードバックのための積極的な承認が支持されるのを示します。
The feedback type "ack" MUST only be used if the media session is
allowed to operate in ACK mode as defined in Section 3.6.1.
メディアセッションがセクション3.6.1で定義されるようにACKモードで作動できるなら、フィードバックタイプ"ack"を使用するだけでよいです。
Parameters MUST be provided to further distinguish different types
of positive acknowledgement feedback.
さらに異なったタイプの積極的な承認フィードバックを区別するためにパラメタを提供しなければなりません。
The parameter "rpsi" indicates the use of Reference Picture
Selection Indication feedback as defined in Section 6.3.3.
パラメタ"rpsi"はセクション6.3.3で定義されるようにReference Picture Selection Indicationフィードバックの使用を示します。
Ott, et al. Standards Track [Page 25] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[25ページ]。
If the parameter "app" is specified, this indicates the use of
application layer feedback. In this case, additional parameters
following "app" MAY be used to further differentiate various types
of application layer feedback. This document does not define any
parameters specific to "app".
「装置」というパラメタが指定されるなら、これは応用層フィードバックの使用を示します。 この場合、「装置」に続く追加パラメタは、さらに様々なタイプの応用層フィードバックを微分するのに使用されるかもしれません。 このドキュメントは「装置」に特定のどんなパラメタも定義しません。
Further parameters for "ack" MAY be defined in other documents.
"ack"のためのさらなるパラメタは他のドキュメントで定義されるかもしれません。
Feedback type "nack":
フィードバックタイプ"nack":
This feedback type indicates that negative acknowledgements for
feedback are supported.
このフィードバックタイプは、フィードバックのための否定的承認が支持されるのを示します。
The feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1.
フィードバックタイプ"nack"はセクション6.2.1で定義されるようにパラメタなしでGenericナックフィードバック形式の使用を示します。
The following three parameters are defined in this document for
use with "nack" in conjunction with the media type "video":
以下の3つのパラメタがメディアタイプに関連した"nack"との使用のための「ビデオ」というこのドキュメントで定義されます:
o "pli" indicates the use of Picture Loss Indication feedback as
defined in Section 6.3.1.
o "pli"はセクション6.3.1で定義されるようにPicture Loss Indicationフィードバックの使用を示します。
o "sli" indicates the use of Slice Loss Indication feedback as
defined in Section 6.3.2.
o "sli"はセクション6.3.2で定義されるようにSlice Loss Indicationフィードバックの使用を示します。
o "rpsi" indicates the use of Reference Picture Selection
Indication feedback as defined in Section 6.3.3.
o "rpsi"はセクション6.3.3で定義されるようにReference Picture Selection Indicationフィードバックの使用を示します。
"app" indicates the use of application layer feedback. Additional
parameters after "app" MAY be provided to differentiate different
types of application layer feedback. No parameters specific to
"app" are defined in this document.
「装置」は応用層フィードバックの使用を示します。 異なったタイプの適用を微分するために「装置」を提供したかもしれない後に追加パラメタはフィードバックを層にします。 「装置」に特定のどんなパラメタも本書では定義されません。
Further parameters for "nack" MAY be defined in other documents.
"nack"のためのさらなるパラメタは他のドキュメントで定義されるかもしれません。
Other feedback types <rtcp-fb-id>:
他のフィードバックは<rtcp-fb-イド>をタイプします:
Other documents MAY define additional types of feedback; to keep
the grammar extensible for those cases, the rtcp-fb-id is
introduced as a placeholder. A new feedback scheme name MUST to
be unique (and thus MUST be registered with IANA). Along with a
new name, its semantics, packet formats (if necessary), and rules
for its operation MUST be specified.
他のドキュメントは追加タイプのフィードバックを定義するかもしれません。 それらのケースにおいて広げることができるように文法を保つために、rtcp-fb-イドはプレースホルダとして紹介されます。 新しいフィードバック計画名はそうしなければなりません。特有に(その結果、IANAに登録しなければなりません)なるように。 新しい名前と共に、意味論、パケット・フォーマット(必要なら)、および操作のための規則を指定しなければなりません。
Ott, et al. Standards Track [Page 26] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[26ページ]。
Regular RTCP minimum interval "trr-int":
通常のRTCP最小間隔"trr-int":
The attribute "trr-int" is used to specify the minimum interval
T_rr_interval between two Regular (full compound) RTCP packets in
milliseconds for this media session. If "trr-int" is not
specified, a default value of 0 is assumed.
属性"trr-int"は、このメディアセッションとしてミリセカンドで2Regular(完全な化合物)RTCPパケットの最小間隔T_rr_間隔を指定するのに使用されます。 "trr-int"が指定されないなら、0のデフォルト値は想定されます。
Note that it is assumed that more specific information about application layer feedback (as defined in Section 6.4) will be conveyed as feedback types and parameters defined elsewhere. Hence, no further provision for any types and parameters is made in this document.
応用層フィードバック(セクション6.4で定義されるように)の、より特定の情報がフィードバックタイプとほかの場所で定義されたパラメタとして伝えられると思われることに注意してください。 したがって、本書ではどんなタイプとパラメタへのさらなる設備も全くしません。
Further types of feedback as well as further parameters may be defined in other documents.
さらなるパラメタと同様にさらなるタイプのフィードバックは他のドキュメントで定義されるかもしれません。
It is up to the recipients whether or not they send feedback information and up to the sender(s) (how) to make use of feedback provided.
彼らがフィードバック情報を送るか否かに関係なく、それは受取人次第でした、そして、利用する送付者(どのように)まで、フィードバックは提供されたか。
4.3. RTCP Bandwidth Modifiers
4.3. RTCP帯域幅修飾語
The standard RTCP bandwidth assignments as defined in [1] and [2] MAY be overridden by bandwidth modifiers that explicitly define the maximum RTCP bandwidth. For use with SDP, such modifiers are specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign a different bandwidth (measured in bits per second) to RTP senders and receivers, respectively. The precedence rules of [4] apply to determine the actual bandwidth to be used by senders and receivers.
[1]と[2]で定義される標準のRTCP帯域幅課題は明らかに最大のRTCP帯域幅を定義する帯域幅修飾語によってくつがえされるかもしれません。 SDPとの使用として、そのような修飾語は[4]で指定されます: 「b=RS: <bw>」と「b=RR: <bw>」は、それぞれ、異なった帯域幅(bpsでは、測定される)をRTP送付者と受信機に割り当てるのに使用されるかもしれません。 [4]の先行規則は、実際の帯域幅が送付者と受信機によって使用されることを決定するのに当てはまります。
Applications operating knowingly over highly asymmetric links (such as satellite links) SHOULD use this mechanism to reduce the feedback rate for high bandwidth streams to prevent deterministic congestion of the feedback path(s).
故意に非常に非対称のリンク(衛星中継などの)の上にSHOULDを操作するアプリケーションは、フィードバック経路の決定論的な混雑を防ぐために高帯域の流れのフィードバック速度を低下させるのにこのメカニズムを使用します。
4.4. Examples
4.4. 例
Example 1: The following session description indicates a session made up from audio and DTMF [18] for point-to-point communication in which the DTMF stream uses Generic NACKs. This session description could be contained in a SIP INVITE, 200 OK, or ACK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits.
例1: 以下のセッション記述は、セッションがDTMFの流れがGeneric NACKsを使用する二地点間コミュニケーションのためにオーディオとDTMF[18]を作ったのを示します。 SIP INVITE、200OK、または送付者が、それが伝えるDTMFの流れにおいてできて反響を調べても構わないと思っているのを示すACKメッセージにこのセッション記述を含むことができました。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
v=0 o=alice3203093520 3203093520IN IP4 host.example.com sはフィードバックt=0 0でメディアと等しいです。
Ott, et al. Standards Track [Page 27] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[27ページ]。
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
IN IP4 host.example.com c=mがオーディオの49170RTP/AVPFと等しい、0、96a=rtpmap、: 0PCMU/8000a=rtpmap: 96電話出来事/8000a=fmtp: 96 0-16a=rtcp-fb: 96nack
This allows sender and receiver to provide reliable transmission of DTMF events in an audio session. Assuming a 64-kbit/s audio stream with one receiver, the receiver has 2.5% RTCP bandwidth available for the negative acknowledgement stream, i.e., 250 bytes per second or some 2 RTCP feedback messages every second. Hence, the receiver can individually communicate up to two missing DTMF audio packets per second.
これで、送付者と受信機はオーディオセッションのときにDTMF出来事の信頼できるトランスミッションを提供できます。 受信機には、1台の受信機による64-kbit/sオーディオストリームを仮定して、否定的承認の流れに利用可能な2.5%のRTCP帯域幅があります、すなわち、毎秒のおよそ2番目か2つのRTCPフィードバックメッセージあたり250バイト。 したがって、受信機は個別に1秒あたり最大2つのなくなったDTMFオーディオパケットを伝えることができます。
Example 2: The following session description indicates a multicast video-only session (using either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. Such a description may have been conveyed using the Session Announcement Protocol (SAP).
例2: ビデオソースがコーデックとReference Picture Selectionの両方のためにGeneric NACKsを受け入れていて、以下のセッション記述はH.263のためにマルチキャストビデオだけセッションを示します(H.261かH.263+のどちらかを使用します)。 そのような記述は、Session Announcementプロトコル(SAP)を使用することで伝えられたかもしれません。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
3203130148 3203137348フィードバックtがあるv=0 o=alice3203093520 3203093520IN IP4 host.example.com s=マルチキャストビデオ=mがオーディオの49170RTP/AVPと等しい、0、c、=IN IP4 224.2.1.183a=rtpmap: 0PCMU/8000mがビデオ51372RTP/AVPFと等しい、98 99、c、=IN IP4 224.2.1.184a=rtpmap: 98H263-1998/90000 a=rtpmap: 99H261/90000 a=rtcp-fb: *nack a=rtcp-fb: 98nack rpsi
The sender may use an incoming Generic NACK as a hint to send a new intra-frame as soon as possible (congestion control permitting). Receipt of a Reference Picture Selection Indication (RPSI) message allows the sender to avoid sending a large intra-frame; instead it may continue to send inter-frames, however, choosing the indicated frame as new encoding reference.
送付者は、できるだけ早さに(輻輳制御の可能にする)新しいイントラフレームを送るのにヒントとして入って来るGenericナックを使用するかもしれません。 Reference Picture Selection Indication(RPSI)メッセージの領収書で、送付者は、大きいイントラフレームを送るのを避けることができます。 それは、参照をコード化しながら新しいとして示されたフレームを選びながら、しかしながら、代わりに、インターフレームを送り続けるかもしれません。
Example 3: The following session description defines the same media session as example 2 but allows for mixed-mode operation of AVP and AVPF RTP entities (see also next section). Note that both media descriptions use the same addresses; however, two m= lines are needed to convey information about both applicable RTP profiles.
例3: 以下のセッション記述は、例2と同じメディアセッションを定義しますが、AVPとAVPF RTP実体のミックスト・モード操作を考慮します(また、次のセクションを見てください)。 両方のメディア記述が同じアドレスを使用することに注意してください。 しかしながら、2m=線が、両方の適切なRTPプロフィールの周りで情報を伝達するのに必要です。
Ott, et al. Standards Track [Page 28] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[28ページ]。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
3203130148 3203137348フィードバックtがあるv=0 o=alice3203093520 3203093520IN IP4 host.example.com s=マルチキャストビデオ=mがオーディオの49170RTP/AVPと等しい、0、c、=IN IP4 224.2.1.183a=rtpmap: 0PCMU/8000mがビデオ51372RTP/AVPと等しい、98 99、c、=IN IP4 224.2.1.184a=rtpmap: 98H263-1998/90000 a=rtpmap: 99H261/90000mがビデオ51372RTP/AVPFと等しい、98 99、c、=IN IP4 224.2.1.184a=rtpmap: 98H263-1998/90000 a=rtpmap: 99H261/90000 a=rtcp-fb: *nack a=rtcp-fb: 98nack rpsi
Note that these two m= lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10].
これらの2mの=線SHOULDが同じコンテンツを伝えながら何らかの適切な手段によって分類されて、両方が実際に代替手段であることを示すことに注意してください。 これを達成できるサンプル枠組みは[10]で定義されます。
In this example, the RTCP feedback-enabled receivers will gain an occasional advantage to report events earlier back to the sender (which may benefit the entire group). On average, however, all RTP receivers will provide the same amount of feedback. The interworking between AVP and AVPF entities is discussed in depth in the next section.
フィードバックでこの例、RTCPで可能にされた受信機は、より早く送付者(全体のグループのためになるかもしれない)に出来事の報告を持ちかえる時々の利点を獲得するでしょう。 しかしながら、平均的に、すべてのRTP受信機が同じ量のフィードバックを提供するでしょう。 次のセクションでAVPとAVPF実体の間の織り込むことについて徹底的に議論します。
5. Interworking and Coexistence of AVP and AVPF Entities
5. AVPとAVPF実体の織り込むのと共存
The AVPF profile defined in this document is an extension of the AVP profile as defined in [2]. Both profiles follow the same basic rules (including the upper bandwidth limit for RTCP and the bandwidth assignments to senders and receivers). Therefore, senders and receivers using either of the two profiles can be mixed in a single session (see Example 3 in Section 4.5).
本書では定義されたAVPFプロフィールは[2]で定義されるようにAVPプロフィールの拡大です。 両方のプロフィールは同じ基本的なルールに従います(RTCPに、最大の帯域幅限界と帯域幅課題を送付者と受信機に含めて)。 したがって、ただ一つのセッションのときに2個のプロフィールのどちらかを使用する送付者と受信機は混ぜることができます(セクション4.5でExample3を見てください)。
AVP and AVPF are defined in a way that, from a robustness point of view, the RTP entities do not need to be aware of entities of the respective other profile: they will not disturb each other's functioning. However, the quality of the media presented may suffer.
AVPとAVPFはRTP実体が丈夫さ観点から他のそれぞれのプロフィールの実体を意識している必要はない方法で定義されます: 彼らは互いの機能を擾乱しないでしょう。 しかしながら、提示されたメディアの品質に苦しむかもしれません。
The following considerations apply to senders and receivers when used in a combined session.
結合したセッションのときに使用されると、以下の問題は送付者と受信機に適用されます。
Ott, et al. Standards Track [Page 29] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[29ページ]。
o AVP entities (senders and receivers)
o AVP実体(送付者と受信機)
AVP senders will receive RTCP feedback packets from AVPF
receivers and ignore these packets. They will see occasional
closer spacing of RTCP messages (e.g., violating the five-second
rule) by AVPF entities. As the overall bandwidth constraints
are adhered to by both types of entities, they will still get
their share of the RTCP bandwidth. However, while AVP entities
are bound by the five-second rule, depending on the group size
and session bandwidth, AVPF entities may provide more frequent
RTCP reports than AVP ones will. Also, the overall reporting
may decrease slightly as AVPF entities may send bigger compound
RTCP packets (due to the extra RTCP packets).
AVP送付者は、AVPF受信機からRTCPフィードバックパケットを受けて、これらのパケットを無視するでしょう。 彼らはAVPF実体でRTCPメッセージ(例えば、5秒の規則に違反する)の時々の、より近いスペースを見るでしょう。 総合的な帯域幅規制が両方のタイプの実体によって固く守られるとき、それでも、それらは自己のRTCP帯域幅のシェアを得るでしょう。 しかしながら、グループサイズとセッション帯域幅によって、AVP実体が5秒の規則で縛られている間、AVPF実体はAVPものがそうするより頻繁なRTCPレポートを提供するかもしれません。 また、わずかにAVPF実体が、より大きい合成RTCPパケット(余分なRTCPパケットによる)を送るかもしれないように総合的な報告は減少するかもしれません。
If T_rr_interval is used as lower bound between Regular RTCP
packets, T_rr_interval is sufficiently large (e.g., T_rr_interval
> M*Td as per Section 6.3.5 of [1]), and no Early RTCP packets
are sent by AVPF entities, AVP entities may accidentally time
out those AVPF group members and hence underestimate the group
size. Therefore, if AVP entities may be involved in a media
session, T_rr_interval SHOULD NOT be larger than five seconds.
_間隔はT_rrであるならRegular RTCPパケットの間の下界として費やされて、T_rr_間隔は十分大きいです。(AVPF実体で[1])にもかかわらず、.5のセクション6.3Early RTCPパケットに従ってどんな例えば、T_rr_間隔>M*Tdも送らない、AVP実体が偶然そうするかもしれない、タイムアウト、それらのAVPFはメンバーを分類して、したがって、グループサイズを過小評価します。 したがって、AVP実体がそうするかもしれないなら、メディアセッション、T_rr_間隔SHOULD NOTにかかわってください。5秒より大きくいてください。
o AVPF entities (senders and receivers)
o AVPF実体(送付者と受信機)
If the dynamically calculated T_rr is sufficiently small (e.g.,
less than one second), AVPF entities may accidentally time out
AVP group members and hence underestimate the group size.
Therefore, if AVP entities may be involved in a media session,
T_rr_interval SHOULD be used and SHOULD be set to five seconds.
ダイナミックに計算されたT_rrが十分小さいなら(例えば、1秒未満)、AVPF実体は小さいです。タイムアウトAVPは偶然、メンバーを分類して、したがって、グループサイズを過小評価します。 したがって、T_rr_間隔AVP実体がメディアセッションにかかわるかもしれないならSHOULD、使用されてください、SHOULD、5秒に設定されてください。
In conclusion, if AVP entities may be involved in a media
session and T_rr_interval is to be used, T_rr_interval SHOULD be
set to five seconds.
AVP実体がメディアセッションにかかわるかもしれなくて、T_rr_間隔がかかわるなら、結論として、中古のT_rr_間隔SHOULDに、なるように5秒に設定されてください。
o AVPF senders
o AVPF送付者
AVPF senders will receive feedback information only from AVPF
receivers. If they rely on feedback to provide the target media
quality, the quality achieved for AVP receivers may be suboptimal.
AVPF送付者は単にAVPF受信機からフィードバック情報を受け取るでしょう。 彼らがメディア品質を目標に供給するためにフィードバックを当てにするなら、AVP受信機のために獲得された品質は準最適であるかもしれません。
o AVPF receivers
o AVPF受信機
AVPF receivers SHOULD send Early RTCP feedback packets only if
all sending entities in the media session support AVPF. AVPF
receivers MAY send feedback information as part of regularly
scheduled compound RTCP packets following the timing rules of
メディアセッションにおけるすべての送付実体がAVPFを支持する場合にだけ、AVPF受信機SHOULDはフィードバックパケットをEarly RTCPに送ります。 AVPF受信機は定期的一部としての情報がタイミング規則に従う合成RTCPパケットの計画をしたフィードバックを送るかもしれません。
Ott, et al. Standards Track [Page 30] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[30ページ]。
[1] and [2] also in media sessions operating in mixed mode.
However, the receiver providing feedback MUST NOT rely on the
sender reacting to the feedback at all.
また、ミックスト・モードで作動するメディアセッションにおける[1]と[2]。 しかしながら、フィードバックを提供する受信機は全くフィードバックに反応する送付者に頼ってはいけません。
6. Format of RTCP Feedback Messages
6. RTCPフィードバックメッセージの形式
This section defines the format of the low-delay RTCP feedback messages. These messages are classified into three categories as follows:
このセクションは低い遅れRTCPフィードバックメッセージの書式を定義します。 これらのメッセージは以下の3つのカテゴリに分類されます:
- Transport layer FB messages - Payload-specific FB messages - Application layer FB messages
- トランスポート層FBメッセージ--有効搭載量特有のFBメッセージ--応用層FBメッセージ
Transport layer FB messages are intended to transmit general purpose feedback information, i.e., information independent of the particular codec or the application in use. The information is expected to be generated and processed at the transport/RTP layer. Currently, only a generic negative acknowledgement (NACK) message is defined.
トランスポート層FBメッセージが汎用のフィードバック情報(すなわち、特定のコーデックか使用中のアプリケーションの如何にかかわらず情報)を伝えることを意図します。 情報は、発生すると予想されて、輸送/RTP層に処理されます。 現在、一般的な否定的承認(ナック)メッセージだけが定義されます。
Payload-specific FB messages transport information that is specific to a certain payload type and will be generated and acted upon at the codec "layer". This document defines a common header to be used in conjunction with all payload-specific FB messages. The definition of specific messages is left either to RTP payload format specifications or to additional feedback format documents.
有効搭載量特有のFBメッセージは、コーデック「層」で、あるペイロードタイプに、特定の情報を輸送して、発生して、実行されるでしょう。 このドキュメントは、すべてのペイロード特有のFBメッセージに関連して使用されるために一般的なヘッダーを定義します。 特定のメッセージの定義はRTPペイロード書式仕様、または、追加フィードバック形式ドキュメントに残されます。
Application layer FB messages provide a means to transparently convey feedback from the receiver's to the sender's application. The information contained in such a message is not expected to be acted upon at the transport/RTP or the codec layer. The data to be exchanged between two application instances is usually defined in the application protocol specification and thus can be identified by the application so that there is no need for additional external information. Hence, this document defines only a common header to be used along with all application layer FB messages. From a protocol point of view, an application layer FB message is treated as a special case of a payload-specific FB message.
応用層FBメッセージは受信機のものから送付者のアプリケーションまで透明にフィードバックを伝える手段を提供します。 輸送/RTPかコーデック層でそのようなメッセージに含まれた情報が作用されないと予想されます。 追加外部の情報の必要は全くないように、2つのアプリケーション例の間で交換されるべきデータを、通常、アプリケーションプロトコル仕様に基づき定義して、その結果、アプリケーションで特定できます。 したがって、このドキュメントは、すべての応用層FBメッセージと共に使用されるために一般的なヘッダーだけを定義します。 プロトコル観点から、応用層FBメッセージは特殊なものとしてペイロード特有のFBメッセージについて扱われます。
Note: Proper processing of some FB messages at the media sender
side may require the sender to know which payload type the FB
message refers to. Most of the time, this knowledge can likely be
derived from a media stream using only a single payload type.
However, if several codecs are used simultaneously (e.g., with
audio and DTMF) or when codec changes occur, the payload type
information may need to be conveyed explicitly as part of the FB
message. This applies to all
以下に注意してください。 メディア送付者側のいくつかのFBメッセージの適切な処理は、送付者が、FBメッセージがどのペイロードタイプについて言及するかを知っているのを必要とするかもしれません。 たいてい、メディアの流れから単独のペイロードタイプだけを使用することでこの知識をおそらく得ることができます。 しかしながら、いくつかのコーデックが同時(例えば、オーディオとDTMFと共に)に、使用されるか、またはコーデック変化が起こると、ペイロードタイプ情報は、FBメッセージの一部として明らかに運ばれる必要があるかもしれません。 これはすべてに適用されます。
Ott, et al. Standards Track [Page 31] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[31ページ]。
payload-specific as well as application layer FB messages. It is
up to the specification of an FB message to define how payload
type information is transmitted.
応用層FBメッセージと同様にペイロード特有です。 それはペイロードタイプ情報がどう伝えられるかを定義するFBメッセージの仕様まで達しています。
This document defines two transport layer and three (video) payload- specific FB messages as well as a single container for application layer FB messages. Additional transport layer and payload-specific FB messages MAY be defined in other documents and MUST be registered through IANA (see Section 9, "IANA Considerations").
このドキュメントは応用層FBメッセージのための単一の容器と同様に2トランスポート層と3つ(ビデオ)のペイロードの特定のFBメッセージを定義します。 追加トランスポート層とペイロード特有のFBメッセージを他のドキュメントで定義されるかもしれなくて、IANAを通して示さなければなりません(セクション9、「IANA問題」を見てください)。
The general syntax and semantics for the above RTCP FB message types are described in the following subsections.
上のRTCP FBメッセージタイプのための一般的な構文と意味論は以下の小区分で説明されます。
6.1. Common Packet Format for Feedback Messages
6.1. フィードバックメッセージのための一般的なパケット・フォーマット
All FB messages MUST use a common packet format that is depicted in Figure 3:
すべてのFBメッセージが図3に表現される一般的なパケット・フォーマットを使用しなければなりません:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT| 太平洋標準時| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット送付者のSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メディア・ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : フィードバック制御情報(FCI): : :
Figure 3: Common Packet Format for Feedback Messages
図3: フィードバックメッセージのための一般的なパケット・フォーマット
The fields V, P, SSRC, and length are defined in the RTP specification [2], the respective meaning being summarized below:
それぞれの意味が以下へまとめられて、分野V、P、SSRC、および長さはRTP仕様[2]に基づき定義されます:
version (V): 2 bits
This field identifies the RTP version. The current version is 2.
バージョン(V): Thisがさばく2ビットはRTPバージョンを特定します。 最新版は2です。
padding (P): 1 bit
If set, the padding bit indicates that the packet contains
additional padding octets at the end that are not part of the
control information but are included in the length field.
詰め物(P): Ifが設定する1ビット、詰め物ビットはパケットが終わりの制御情報の一部ではありませんが、長さの分野に含まれている追加詰め物八重奏を含むのを示します。
Ott, et al. Standards Track [Page 32] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[32ページ]。
Feedback message type (FMT): 5 bits
This field identifies the type of the FB message and is
interpreted relative to the type (transport layer, payload-
specific, or application layer feedback). The values for each of
the three feedback types are defined in the respective sections
below.
フィードバックメッセージタイプ(FMT): Thisがさばく5ビットは、FBメッセージのタイプを特定して、タイプ(ペイロードトランスポート層、特定であるか応用層フィードバック)に比例して解釈されます。 3人のフィードバックタイプ各人のための値は下のそれぞれのセクションで定義されます。
Payload type (PT): 8 bits
This is the RTCP packet type that identifies the packet as being
an RTCP FB message. Two values are defined by the IANA:
有効搭載量タイプ(太平洋標準時の): 8ビットのThisはRTCP FBメッセージであるとしてパケットを特定するRTCPパケットタイプです。 2つの値がIANAによって定義されます:
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
名前| 値| 簡単な説明----------+-------+------------------------------------ RTPFB| 205 | トランスポート層FBメッセージPSFB| 206 | 有効搭載量特有のFBメッセージ
Length: 16 bits
The length of this packet in 32-bit words minus one, including the
header and any padding. This is in line with the definition of
the length field used in RTCP sender and receiver reports [3].
長さ: ヘッダーとどんな詰め物も含む1つを引いた32ビットの単語によるこのパケットの長さの16ビット。 RTCP送付者と受信機レポート[3]で使用される長さの分野の定義に沿ってこれがあります。
SSRC of packet sender: 32 bits
The synchronization source identifier for the originator of this
packet.
パケット送付者のSSRC: 32ビット、同期はこのパケットの生成元のために識別子の出典を明示します。
SSRC of media source: 32 bits
The synchronization source identifier of the media source that
this piece of feedback information is related to.
メディア・ソースのSSRC: 32ビット、これがつなぎあわせるフィードバック情報のメディア・ソースの同期ソース識別子は関連します。
Feedback Control Information (FCI): variable length
The following three sections define which additional information
MAY be included in the FB message for each type of feedback:
transport layer, payload-specific, or application layer feedback.
Note that further FCI contents MAY be specified in further
documents.
フィードバック制御情報(FCI): 次の3つのセクションが定義するそれの追加情報がそれぞれのタイプのフィードバックへのFBメッセージに含まれるかもしれない可変長: 層、ペイロード特有であるか応用層フィードバックを輸送してください。 さらなるFCIコンテンツがさらなるドキュメントで指定されるかもしれないことに注意してください。
Each RTCP feedback packet MUST contain at least one FB message in the FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or not multiple FB messages MAY be compressed into a single FCI field. If this is the case, they MUST be of the same type, i.e., same FMT. If multiple types of feedback messages, i.e., several FMTs, need to be conveyed, then several RTCP FB messages MUST be generated and SHOULD be concatenated in the same compound RTCP packet.
それぞれのRTCPフィードバックパケットはFCI分野に少なくとも1つのFBメッセージを保管しなければなりません。 セクション6.2と6.3 それぞれのFCIタイプのために、複数のFBメッセージがただ一つのFCI分野に圧縮されるかもしれないか否かに関係なく、定義します。 これがそうであるなら、同じタイプには彼らがいるに違いありません、すなわち、同じFMT。すなわち、複数のタイプに関するフィードバックメッセージと、数個のFMTsと、運ばれて、次に、いくつかのRTCP FBメッセージが発生しなければならないということである必要性とSHOULDであるなら、同じ合成RTCPパケットで連結されてください。
Ott, et al. Standards Track [Page 33] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[33ページ]。
6.2. Transport Layer Feedback Messages
6.2. トランスポート層フィードバックメッセージ
Transport layer FB messages are identified by the value RTPFB as RTCP message type.
トランスポート層FBメッセージはRTCPメッセージタイプとして値のRTPFBによって特定されます。
A single general purpose transport layer FB message is defined in this document: Generic NACK. It is identified by means of the FMT parameter as follows:
ただ一つの汎用のトランスポート層FBメッセージは本書では定義されます: 一般的なナック。 それは以下のFMTパラメタによって特定されます:
0: unassigned 1: Generic NACK 2-30: unassigned 31: reserved for future expansion of the identifier number space
0: 1を割り当てません: 一般的なナック2-30: 31を割り当てません: 識別子数のスペースの今後の拡大のために、予約されます。
The following subsection defines the formats of the FCI field for this type of FB message. Further generic feedback messages MAY be defined in the future.
以下の小区分はこのタイプに関するFBメッセージのためにFCI分野の書式を定義します。 さらなる一般的なフィードバックメッセージは将来、定義されるかもしれません。
6.2.1. Generic NACK
6.2.1. 一般的なナック
The Generic NACK message is identified by PT=RTPFB and FMT=1.
Genericナックメッセージは太平洋標準時までに特定されます。=RTPFBとFMT=1。
The FCI field MUST contain at least one and MAY contain more than one Generic NACK.
FCI分野は、少なくとも1つを含まなければならなくて、1Genericのナックを含むかもしれません。
The Generic NACK is used to indicate the loss of one or more RTP packets. The lost packet(s) are identified by the means of a packet identifier and a bit mask.
Genericナックは、1つ以上のRTPパケットの損失を示すのに使用されます。 無くなっているパケットはパケット識別子としばらくマスクの手段で特定されます。
Generic NACK feedback SHOULD NOT be used if the underlying transport protocol is capable of providing similar feedback information to the sender (as may be the case, e.g., with DCCP).
一般的なナックフィードバックSHOULD NOT、基本的なトランスポート・プロトコルが同様のフィードバック情報を送付者に提供できるなら(例えば、DCCPに関してそうであるかもしれないように)、使用されてください。
The Feedback Control Information (FCI) field has the following Syntax (Figure 4):
Feedback Control情報(FCI)分野には、以下のSyntax(図4)があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID| BLP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message
図4: Genericナックメッセージのための構文
Packet ID (PID): 16 bits
The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet.
パケットID(PID): PIDがさばく16ビットは、無くなっているパケットを指定するのに使用されます。 PID分野は無くなっているパケットのRTP一連番号について言及します。
Ott, et al. Standards Track [Page 34] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[34ページ]。
bitmask of following lost packets (BLP): 16 bits
The BLP allows for reporting losses of any of the 16 RTP packets
immediately following the RTP packet indicated by the PID. The
BLP's definition is identical to that given in [6]. Denoting the
BLP's least significant bit as bit 1, and its most significant bit
as bit 16, then bit i of the bit mask is set to 1 if the receiver
has not received RTP packet number (PID+i) (modulo 2^16) and
indicates this packet is lost; bit i is set to 0 otherwise. Note
that the sender MUST NOT assume that a receiver has received a
packet because its bit mask was set to 0. For example, the least
significant bit of the BLP would be set to 1 if the packet
corresponding to the PID and the following packet have been lost.
However, the sender cannot infer that packets PID+2 through PID+16
have been received simply because bits 2 through 15 of the BLP are
0; all the sender knows is that the receiver has not reported them
as lost at this time.
無くなっているパケット(BLP)に続くビットマスク: PIDによって示されたRTPパケットに続いて、16ビット、BLPは、すぐに16のRTPパケットのどれかの損失を報告すると考慮します。 BLPの定義は[6]で与えられたそれと同じです。 ビット1としてBLPの最下位ビットを指示して、ビット16としての最上位ビット、次に、受信機が、RTPパケット番号(PID+i)(法2^16)を受け取っていなくて、このパケットが無くなるのを示すなら、噛み付いているマスクのビットiは1に設定されます。 ビットiは別の方法で0に設定されます。 送付者が、噛み付いているマスクが0に設定されたので受信機がパケットを受けたと仮定してはいけないことに注意してください。 例えば、PIDに対応するパケットと以下のパケットが失われたなら、BLPの最下位ビットは1に設定されるでしょう。 しかしながら、送付者は、単にBLPのビット2〜15が0であるのでPID+16を通したパケットPID+2が受け取られたと推論できません。 送付者が知っているすべては受信機がこのとき失われているようにそれらを報告していないということです。
The length of the FB message MUST be set to 2+n, with n being the number of Generic NACKs contained in the FCI field.
2+nにFBメッセージの長さを設定しなければなりません、FCI分野に保管されていたGeneric NACKsの数であるnで。
The Generic NACK message implicitly references the payload type through the sequence number(s).
Genericナックメッセージは一連番号を通してそれとなくペイロードタイプに参照をつけます。
6.3. Payload-Specific Feedback Messages
6.3. 有効搭載量特有のフィードバックメッセージ
Payload-Specific FB messages are identified by the value PT=PSFB as RTCP message type.
有効搭載量特有のFBメッセージはRTCPメッセージタイプとして太平洋標準時の値=PSFBによって特定されます。
Three payload-specific FB messages are defined so far plus an application layer FB message. They are identified by means of the FMT parameter as follows:
3つのペイロード特有のFBメッセージが、今までのところ、定義されていて応用層FBメッセージです。 それらは以下のFMTパラメタによって特定されます:
0: unassigned
1: Picture Loss Indication (PLI)
2: Slice Loss Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
4-14: unassigned
15: Application layer FB (AFB) message
16-30: unassigned
31: reserved for future expansion of the sequence number space
0: 1を割り当てません: 損失指示(PLI)2について描写してください: 損失指示(SLI)3を切ってください: 参照絵の選択指示(RPSI)4-14: 15を割り当てません: 応用層FB(AFB)メッセージ16-30: 31を割り当てません: 一連番号スペースの今後の拡大のために、予約されます。
The following subsections define the FCI formats for the payload- specific FB messages, Section 6.4 defines FCI format for the application layer FB message.
以下の小区分はペイロードの特定のFBメッセージのためにFCI書式を定義して、セクション6.4は応用層FBメッセージのためにFCI書式を定義します。
Ott, et al. Standards Track [Page 35] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[35ページ]。
6.3.1. Picture Loss Indication (PLI)
6.3.1. 絵の損失指示(PLI)
The PLI FB message is identified by PT=PSFB and FMT=1.
PLI FBメッセージは太平洋標準時までに特定されます。=PSFBとFMT=1。
There MUST be exactly one PLI contained in the FCI field.
FCI分野に保管されていた1PLIがまさにあるに違いありません。
6.3.1.1. Semantics
6.3.1.1. 意味論
With the Picture Loss Indication message, a decoder informs the encoder about the loss of an undefined amount of coded video data belonging to one or more pictures. When used in conjunction with any video coding scheme that is based on inter-picture prediction, an encoder that receives a PLI becomes aware that the prediction chain may be broken. The sender MAY react to a PLI by transmitting an intra-picture to achieve resynchronization (making this message effectively similar to the FIR message as defined in [6]); however, the sender MUST consider congestion control as outlined in Section 7, which MAY restrict its ability to send an intra frame.
Picture Loss Indicationメッセージで、デコーダは1枚以上の絵に属す未定義の量のコード化されたビデオ・データの損失に関してエンコーダを知らせます。 相互の絵の予測に基づいているどんなビデオコード構成に関連して使用されると、PLIを受けるエンコーダは予測チェーンが壊れているかもしれないのを意識するようになります。 送付者が再同期を達成するためにイントラ絵を送ることによってPLIに反応するかもしれない、([6])で定義されるようにこのメッセージを事実上、FIRメッセージと同様にします。 しかしながら、送付者はセクション7(イントラフレームを送る性能を制限するかもしれません)に概説されているように輻輳制御を考えなければなりません。
Other RTP payload specifications such as RFC 2032 [6] already define a feedback mechanism for some for certain codecs. An application supporting both schemes MUST use the feedback mechanism defined in this specification when sending feedback. For backward compatibility reasons, such an application SHOULD also be capable to receive and react to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
RFC2032[6]などの他のRTPペイロード仕様はあるコーデックのためのいくつかのために既にフィードバック・メカニズムを定義します。 両方の計画を支持するアプリケーションはフィードバックを送るときこの仕様に基づき定義されたフィードバック・メカニズムを使用しなければなりません。 後方の互換性理由で、そのようなアプリケーションSHOULDはまた、受信できて、これがそのペイロード形式によって必要とされるならそれぞれのRTPペイロード形式で定義されたフィードバック計画に反応します。
6.3.1.2. Message Format
6.3.1.2. メッセージ・フォーマット
PLI does not require parameters. Therefore, the length field MUST be 2, and there MUST NOT be any Feedback Control Information.
PLIはパラメタを必要としません。 したがって、長さの分野は2であるに違いありません、そして、少しのFeedback Control情報もあるはずがありません。
The semantics of this FB message is independent of the payload type.
このFBメッセージの意味論はペイロードタイプから独立しています。
6.3.1.3. Timing Rules
6.3.1.3. タイミング規則
The timing follows the rules outlined in Section 3. In systems that employ both PLI and other types of feedback, it may be advisable to follow the Regular RTCP RR timing rules for PLI, since PLI is not as delay critical as other FB types.
タイミングはセクション3に概説された規則に従います。 PLIと他のタイプのフィードバックの両方を使うシステムでは、PLIのためのRegular RTCP RRタイミング規則に従うのは賢明であるかもしれません、他のFBタイプとして批判的な遅れとしてPLIがないので。
6.3.1.4. Remarks
6.3.1.4. 注意
PLI messages typically trigger the sending of full intra-pictures. Intra-pictures are several times larger then predicted (inter-) pictures. Their size is independent of the time they are generated. In most environments, especially when employing bandwidth-limited links, the use of an intra-picture implies an allowed delay that is a
PLIメッセージは通常完全なイントラ絵の発信の引き金となります。 何度かイントラ絵がそうである、多大である、その時が予測した、(相互、)、絵。 それらのサイズはそれらが発生する時から独立しています。 ほとんどの環境で、特に帯域幅で限られたリンクを使うとき、イントラ絵の使用はaである許容遅れを含意します。
Ott, et al. Standards Track [Page 36] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[36ページ]。
significant multitude of the typical frame duration. An example: If the sending frame rate is 10 fps, and an intra-picture is assumed to be 10 times as big as an inter-picture, then a full second of latency has to be accepted. In such an environment, there is no need for a particular short delay in sending the FB message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [2] with Tmin=0 does not have a negative impact on the system performance.
典型的なフレーム持続時間の重要な多数。 例: 送付フレームレートが10fpsであり、イントラ絵を相互の絵の10倍大きいと思うなら、潜在のまるまる1秒を受け入れなければなりません。 そのような環境には、FBメッセージを送る特定の少し遅れの必要は全くありません。 したがって、Tmin=0と[2]に従ってRTCPタイミング規則で許容された次の可能な時間帯を待つのはシステム性能でマイナスの影響がありません。
6.3.2. Slice Loss Indication (SLI)
6.3.2. 部分損失指示(SLI)
The SLI FB message is identified by PT=PSFB and FMT=2.
SLI FBメッセージは太平洋標準時までに特定されます。=PSFBとFMT=2。
The FCI field MUST contain at least one and MAY contain more than one SLI.
FCI分野は、少なくとも1つを含まなければならなくて、1SLIを含むかもしれません。
6.3.2.1. Semantics
6.3.2.1. 意味論
With the Slice Loss Indication, a decoder can inform an encoder that it has detected the loss or corruption of one or several consecutive macroblock(s) in scan order (see below). This FB message MUST NOT be used for video codecs with non-uniform, dynamically changeable macroblock sizes such as H.263 with enabled Annex Q. In such a case, an encoder cannot always identify the corrupted spatial region.
Slice Loss Indicationと共に、デコーダは、スキャン命令に1か数個の連続したmacroblock(s)の損失か不正を検出したことを(以下を見てください)エンコーダに知らせることができます。 ビデオコーデックに不均等でこのFBメッセージを使用してはいけなくて、ダイナミックに変わりやすいmacroblockはH.263などのように可能にされたAnnex Q.Inに伴うそのような場合を大きさで分けて、エンコーダはいつも崩壊した空間的な領域を特定できるというわけではありません。
6.3.2.2. Format
6.3.2.2. 形式
The Slice Loss Indication uses one additional FCI field, the content of which is depicted in Figure 6. The length of the FB message MUST be set to 2+n, with n being the number of SLIs contained in the FCI field.
Slice Loss Indicationは1つの追加FCI分野を使用します。その内容は図6に表現されます。 2+nにFBメッセージの長さを設定しなければなりません、FCI分野に保管されていたSLIsの数であるnで。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1番目| 数| PictureID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Loss Indication (SLI)
図6: 部分損失指示の構文(SLI)
First: 13 bits
The macroblock (MB) address of the first lost macroblock. The MB
numbering is done such that the macroblock in the upper left
corner of the picture is considered macroblock number 1 and the
number for each macroblock increases from left to right and then
from top to bottom in raster-scan order (such that if there is a
total of N macroblocks in a picture, the bottom right macroblock
is considered macroblock number N).
最初に: 13ビット、1つの番目もののmacroblock(MB)アドレスはmacroblockをなくしました。 絵の左上隅のmacroblockがmacroblock No.1であると考えられるように付番して、それぞれのmacroblockの数が増えるMBは右と上から下までそして、ラスタスキャン注文でいなくなりました(絵にN macroblocksの合計があれば、右の下部macroblockがmacroblock No.Nであると考えられるように)。
Ott, et al. Standards Track [Page 37] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[37ページ]。
Number: 13 bits
The number of lost macroblocks, in scan order as discussed above.
数: 無くなっているmacroblocksの数であり13ビット、オーダーは中でスキャンします。上で議論するとして。
PictureID: 6 bits
The six least significant bits of the codec-specific identifier
that is used to reference the picture in which the loss of the
macroblock(s) has occurred. For many video codecs, the PictureID
is identical to the Temporal Reference.
PictureID: 6ビット、macroblock(s)の損失が持っている中で絵に参照をつけるのに使用されるコーデック特有の識別子の6つの最下位ビットが起こりました。 多くのビデオコーデックに関しては、PictureIDはTemporal Referenceと同じです。
The applicability of this FB message is limited to a small set of video codecs; therefore, no explicit payload type information is provided.
このFBメッセージの適用性は小さいセットのビデオコーデックに制限されます。 したがって、どんな明白なペイロードタイプ情報も提供しません。
6.3.2.3. Timing Rules
6.3.2.3. タイミング規則
The efficiency of algorithms using the Slice Loss Indication is reduced greatly when the Indication is not transmitted in a timely fashion. Motion compensation propagates corrupted pixels that are not reported as being corrupted. Therefore, the use of the algorithm discussed in Section 3 is highly recommended.
Indicationが直ちに伝えられないとき、アルゴリズムがSlice Loss Indicationを使用する効率は大いに減少します。 動き補償は崩壊するとして報告されない崩壊した画素を伝播します。 したがって、セクション3で議論したアルゴリズムの使用は非常にお勧めです。
6.3.2.4. Remarks
6.3.2.4. 注意
The term Slice is defined and used here in the sense of MPEG-1 -- a consecutive number of macroblocks in scan order. More recent video coding standards sometimes have a different understanding of the term Slice. In H.263 (1998), for example, a concept known as "rectangular slice" exists. The loss of one rectangular slice may lead to the necessity of sending more than one SLI in order to precisely identify the region of lost/damaged MBs.
Sliceという用語は、ここ、MPEG-1の意味で定義されて、使用されます--スキャン命令における、macroblocksの一連番号。 より最近のビデオコーディング標準に、Sliceという用語の異なった理解が時々あります。 H.263(1998)では、例えば、「長方形の部分」として知られている概念は存在しています。 1つの長方形の切れの損失は正確に無くなっているか破損しているMBの領域を特定するために1SLIを送るという必要性に通じるかもしれません。
The first field of the FCI defines the first macroblock of a picture as 1 and not, as one could suspect, as 0. This was done to align this specification with the comparable mechanism available in ITU-T Rec. H.245 [24]. The maximum number of macroblocks in a picture (2**13 or 8192) corresponds to the maximum picture sizes of most of the ITU-T and ISO/IEC video codecs. If future video codecs offer larger picture sizes and/or smaller macroblock sizes, then an additional FB message has to be defined. The six least significant bits of the Temporal Reference field are deemed to be sufficient to indicate the picture in which the loss occurred.
そして、FCIの最初の分野が絵の最初のmacroblockを1と定義する、人は0として疑うことができました。 ITU-T Recで利用可能な匹敵するメカニズムにこの仕様を一直線にするためにこれをしました。 H.245[24]。 絵(2**13か8192)のmacroblocksの最大数はITU-TとISO/IECビデオコーデックの大部分の最大の絵のサイズに対応しています。 将来のビデオコーデックがより大きな構想サイズ、そして/または、、より小さいmacroblockサイズを提供するなら、追加FBメッセージは定義されなければなりません。 Temporal Reference分野の6つの最下位ビットが損失が発生した絵を示すために十分であると考えられます。
The reaction to an SLI is not part of this specification. One typical way of reacting to an SLI is to use intra refresh for the affected spatial region.
SLIへの反応はこの仕様の一部ではありません。 イントラが影響を受ける空間的な領域にリフレッシュする使用にはSLIに反応する1つの典型的な方法があります。
Ott, et al. Standards Track [Page 38] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[38ページ]。
Algorithms were reported that keep track of the regions affected by motion compensation, in order to allow for a transmission of Intra macroblocks to all those areas, regardless of the timing of the FB (see H.263 (2000) Appendix I [17] and [15]). Although the timing of the FB is less critical when those algorithms are used than if they are not, it has to be observed that those algorithms correct large parts of the picture and, therefore, have to transmit much higher data volume in case of delayed FBs.
動き補償で影響を受ける領域の動向をおさえるアルゴリズムが報告されました、それらのすべての領域へのIntra macroblocksのトランスミッションを考慮するために、FBのタイミングにかかわらず。(H.263(2000)付録I[17]と[15])を見てください。 それらのアルゴリズムが使用されているとき、FBのタイミングがそれほど重要でない、それらがないなら、それらのアルゴリズムが絵のかなりの部分を修正して、したがって、遅れたFBsの場合にはるかに高いデータ量を伝えなければならないのが観測されなければなりません。
6.3.3. Reference Picture Selection Indication (RPSI)
6.3.3. 参照絵の選択指示(RPSI)
The RPSI FB message is identified by PT=PSFB and FMT=3.
RPSI FBメッセージは太平洋標準時までに特定されます。=PSFBとFMT=3。
There MUST be exactly one RPSI contained in the FCI field.
FCI分野に保管されていた1RPSIがまさにあるに違いありません。
6.3.3.1. Semantics
6.3.3.1. 意味論
Modern video coding standards such as MPEG-4 visual version 2 [16] or H.263 version 2 [17] allow using older reference pictures than the most recent one for predictive coding. Typically, a first-in-first- out queue of reference pictures is maintained. If an encoder has learned about a loss of encoder-decoder synchronicity, a known-as- correct reference picture can be used. As this reference picture is temporally further away then usual, the resulting predictively coded picture will use more bits.
MPEG-4の視覚バージョン2[16]かH.263バージョン2[17]などの現代のビデオコーディング標準で、予言のコード化に最新のものより古い参照の絵を使用します。 通常、参照の絵の最初に外で中で最初の待ち行列は維持されます。 エンコーダがエンコーダデコーダ共時性の損失に関して学んだなら、知られて正しい参照の絵を使用できます。 この参照の絵がその時時間的に普通の状態でさらに離れているので、結果として起こる予言したようにコード化された絵は、より多くのビットを使用するでしょう。
Both MPEG-4 and H.263 define a binary format for the "payload" of an RPSI message that includes information such as the temporal ID of the damaged picture and the size of the damaged region. This bit string is typically small (a couple of dozen bits), of variable length, and self-contained, i.e., contains all information that is necessary to perform reference picture selection.
MPEG-4とH.263の両方が破損している絵の時のIDや破損している領域のサイズの情報を含んでいるRPSIメッセージの「ペイロード」のためにバイナリフォーマットを定義します。 すなわち、このビット列は、可変長が通常小さくて(2、3 12ビット)、自己充足的です。参照絵の選択を実行するのに必要な状態でそうするすべての情報を含んでいます。
Both MPEG-4 and H.263 allow the use of RPSI with positive feedback information as well. That is, pictures (or Slices) are reported that were decoded without error. Note that any form of positive feedback MUST NOT be used when in a multiparty session (reporting positive feedback about individual reference pictures at RTCP intervals is not expected to be of much use anyway).
MPEG-4とH.263の両方がまた、積極的なフィードバック情報があるRPSIの使用を許します。 すなわち、誤りなしで解読された絵(または、Slices)は報告されます。 「マルチ-パーティー」セッションのときに注意するときにはどんなフォームの積極的なフィードバックも使用してはいけないことに注意してください(RTCP間隔を置いて個々の参照の絵に関する積極的なフィードバックを報告するのが、とにかくあまり使用のものでないと予想されます)。
Ott, et al. Standards Track [Page 39] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[39ページ]。
6.3.3.2. Format
6.3.3.2. 形式
The FCI for the RPSI message follows the format depicted in Figure 7:
RPSIメッセージのためのFCIは図7に表現された書式に従います:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined per codec ... | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pb|0| 有効搭載量タイプ| 固有のRPSIビット列| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コーデック単位で定義されます… | (0)を水増しします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)
図7: 参照絵の選択指示の構文(RPSI)
PB: 8 bits
The number of unused bits required to pad the length of the RPSI
message to a multiple of 32 bits.
Pb: 未使用のビットの数が32ビットの倍数にRPSIメッセージの長さを水増しするのが8ビット、必要です。
0: 1 bit
MUST be set to zero upon transmission and ignored upon reception.
0: 1ビットをトランスミッションのゼロに設定されて、レセプションで無視しなければなりません。
Payload Type: 7 bits
Indicates the RTP payload type in the context of which the native
RPSI bit string MUST be interpreted.
有効搭載量タイプ: 固有のRPSIビット列を解釈しなければならない文脈のRTPペイロードタイプの7ビットのIndicates。
Native RPSI bit string: variable length
The RPSI information as natively defined by the video codec.
固有のRPSIビット列: RPSI情報がビデオコーデックで同じくらいネイティブに定義した可変長。
Padding: #PB bits
A number of bits set to zero to fill up the contents of the RPSI
message to the next 32-bit boundary. The number of padding bits
MUST be indicated by the PB field.
詰め物: #ビットのPBビットA番号は、次の32ビットの境界にRPSIメッセージのコンテンツを満たすためにゼロにセットしました。 PB分野で詰め物ビットの数を示さなければなりません。
6.3.3.3. Timing Rules
6.3.3.3. タイミング規則
RPSI is even more critical to delay than algorithms using SLI. This is because the older the RPSI message is, the more bits the encoder has to spend to re-establish encoder-decoder synchronicity. See [15] for some information about the overhead of RPSI for certain bit rate/frame rate/loss rate scenarios.
RPSIは、遅らせるためにSLIを使用するアルゴリズムよりさらに重要です。 これはRPSIメッセージが古ければ古いほど、エンコーダがエンコーダデコーダ共時性を復職させるために費やさなければならないビットが、より多いからです。 あるビット伝送速度/フレームのレート/損失レートシナリオに関してRPSIのオーバーヘッドの何らかの情報のための[15]を見てください。
Therefore, RPSI messages should typically be sent as soon as possible, employing the algorithm of Section 3.
したがって、セクション3のアルゴリズムを使って、できるだけ早く、RPSIメッセージを通常送るべきです。
Ott, et al. Standards Track [Page 40] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[40ページ]。
6.4. Application Layer Feedback Messages
6.4. 応用層フィードバックメッセージ
Application layer FB messages are a special case of payload-specific messages and are identified by PT=PSFB and FMT=15. There MUST be exactly one application layer FB message contained in the FCI field, unless the application layer FB message structure itself allows for stacking (e.g., by means of a fixed size or explicit length indicator).
応用層FBメッセージは、ペイロード特有のメッセージの特別なケースであり、太平洋標準時までに特定されます。=PSFBとFMT=15。 FCI分野に保管されていた1つの応用層FBメッセージがまさにあるに違いありません、アプリケーションが構造自体が積み重ねる(例えば、固定サイズか明白な長さのインディケータによる)ために許容するFBメッセージを層にしないなら。
These messages are used to transport application-defined data directly from the receiver's to the sender's application. The data that is transported is not identified by the FB message. Therefore, the application MUST be able to identify the message payload.
これらのメッセージは、直接受信機のものから送付者のアプリケーションまでアプリケーションで定義されたデータを輸送するのに使用されます。 輸送されるデータはFBメッセージによって特定されません。 したがって、アプリケーションはメッセージペイロードを特定できなければなりません。
Usually, applications define their own set of messages, e.g., NEWPRED messages in MPEG-4 [16] (carried in RTP packets according to RFC 3016 [23]) or FB messages in H.263/Annex N, U [17] (packetized as per RFC 2429 [14]). These messages do not need any additional information from the RTCP message. Thus, the application message is simply placed into the FCI field as follows and the length field is set accordingly.
NをRFC3016[23])に従ったRTPパケットかH.263のFBメッセージで運ばれるか、または付加してください、U[17]。通常、アプリケーションはそれら自身のメッセージのセットを定義します、例えば、MPEG-4[16]のNEWPREDメッセージ、((RFC2429[14])に従って、packetizedしました。 これらのメッセージはRTCPメッセージからの少しの追加情報も必要としません。 したがって、アプリケーションメッセージは単に以下のFCI分野に置かれます、そして、長さの分野はそれに従って、設定されます。
Application Message (FCI): variable length
This field contains the original application message that should
be transported from the receiver to the source. The format is
application dependent. The length of this field is variable. If
the application data is not 32-bit aligned, padding bits and bytes
MUST be added to achieve 32-bit alignment. Identification of
padding is up to the application layer and not defined in this
specification.
アプリケーションメッセージ(FCI): Thisがさばく可変長は受信機からソースまで輸送されるべきである原出願メッセージを含んでいます。 形式はアプリケーションに依存しています。 この分野の長さは可変です。 並べられた状態でアプリケーションデータが32ビットでないなら、32ビットの整列を達成するためにビットとバイトを水増しするのを加えなければなりません。 詰め物の識別は、応用層まであって、この仕様に基づき定義されません。
The application layer FB message specification MUST define whether or not the message needs to be interpreted specifically in the context of a certain codec (identified by the RTP payload type). If a reference to the payload type is required for proper processing, the application layer FB message specification MUST define a way to communicate the payload type information as part of the application layer FB message itself.
応用層FBメッセージ仕様は、メッセージが、特にあるコーデック(RTPペイロードタイプによって特定される)の文脈で解釈される必要であるかどうかを定義しなければなりません。 ペイロードタイプについての言及が適切な処理に必要であるなら、応用層FBメッセージ仕様は応用層FBメッセージ自体の一部としてペイロードタイプ情報を伝える方法を定義しなければなりません。
7. Early Feedback and Congestion Control
7. 早めのフィードバックと輻輳制御
In the previous sections, the FB messages were defined as well as the timing rules according to which to send these messages. The way to react to the feedback received depends on the application using the feedback mechanisms and hence is beyond the scope of this document.
前項で、FBメッセージはタイミング規則これらのメッセージを送ると同様に定義されました。 受け取られたフィードバックに反応する方法は、フィードバック・メカニズムを使用することでアプリケーションによって、したがって、このドキュメントの範囲を超えています。
Ott, et al. Standards Track [Page 41] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[41ページ]。
However, across all applications, there is a common requirement for (TCP-friendly) congestion control on the media stream as defined in [1] and [2] when operating in a best-effort network environment.
しかしながら、メディアの流れの(TCPに優しい)の輻輳制御のための一般的な要件がベストエフォート型ネットワーク環境で作動するとき、[1]と[2]で定義されるようにすべてのアプリケーションのむこうにあります。
It should be noted that RTCP feedback itself is insufficient for congestion control purposes as it is likely to operate at much slower timescales than other transport layer feedback mechanisms (that usually operate in the order of RTT). Therefore, additional mechanisms are required to perform proper congestion control.
それが他のトランスポート層フィードバック・メカニズムよりはるかに遅いスケールで作動しそうなように(通常、それはRTTの注文で作動します)RTCPフィードバック自体が混雑管理目的ためには不十分であることに注意されるべきです。 したがって、追加メカニズムは適切な輻輳制御を実行しなければなりません。
A congestion control algorithm that shares the available bandwidth reasonably fairly with competing TCP connections, e.g., TFRC [7], MUST be used to determine the data rate for the media stream within the bounds of the RTP sender's and the media session's capabilities if the RTP/AVPF session is transmitted in a best-effort environment.
RTP/AVPFセッションがベストエフォート型環境で伝えられるなら、RTP送付者の領域の中のメディアの流れとメディアセッションの能力のためにデータ信号速度を決定するのに合理的に競争しているTCP接続と利用可能な帯域幅を公正に共有する輻輳制御アルゴリズム(例えば、TFRC[7])を使用しなければなりません。
8. Security Considerations
8. セキュリティ問題
RTP packets transporting information with the proposed payload format are subject to the security considerations discussed in the RTP specification [1] and in the RTP/AVP profile specification [2]. This profile does not specify any additional security services.
提案されたペイロード形式で情報を輸送するRTPパケットはRTP仕様[1]とRTP/AVPプロフィール仕様[2]で議論したセキュリティ問題を受けることがあります。 このプロフィールは少しの追加担保サービスも指定しません。
This profile modifies the timing behavior of RTCP and eliminates the minimum RTCP interval of five seconds and allows for earlier feedback to be provided by receivers. Group members of the associated RTP session (possibly pretending to represent a large number of entities) may disturb the operation of RTCP by sending large numbers of RTCP packets thereby reducing the RTCP bandwidth available for Regular RTCP reporting as well as for Early FB messages. (Note that an entity need not be a member of a multicast group to cause these effects.) Similarly, malicious members may send very large RTCP messages, thereby increasing the avg_rtcp_size variable and reducing the effectively available RTCP bandwidth.
このプロフィールは、RTCPのタイミング行動を変更して、最低5秒のRTCP間隔を排除して、より早くフィードバックが受信機によって提供されるのを許容します。 その結果、多くのRTCPパケットにRegular RTCP報告とEarly FBメッセージに利用可能なRTCP帯域幅を減少させることによって、関連RTPセッション(ことによると、多くの実体を表すふりをする)のグループのメンバーはRTCPの操作を擾乱するかもしれません。 (実体がマルチキャストグループのメンバーである必要はないことに注意して、これらの効果を引き起こしてください。) 同様に、悪意があるメンバーは非常に大きいRTCPメッセージを送るかもしれません、その結果、avg_rtcp_サイズ変数を増加させて、事実上利用可能なRTCP帯域幅を減少させて。
Feedback information may be suppressed if unknown RTCP feedback packets are received. This introduces the risk of a malicious group member reducing Early feedback by simply transmitting payload- specific RTCP feedback packets with random contents that are not recognized by any receiver (so they will suppress feedback) or by the sender (so no repair actions will be taken).
未知のRTCPフィードバックパケットが受け取られているなら、フィードバック情報は抑圧されるかもしれません。 これは単に無作為のコンテンツがあるどんな受信機(フィードバックを抑圧するために)か送付者によっても認識されないペイロードの特定のRTCPフィードバックパケットを伝えることによってEarlyフィードバックを減少させる悪意があるグループのメンバーの危険を導入します(したがって、修理行動を全く取らないでしょう)。
A malicious group member can also report arbitrary high loss rates in the feedback information to make the sender throttle the data transmission and increase the amount of redundancy information or take other action to deal with the pretended packet loss (e.g., send fewer frames or decrease audio/video quality). This may result in a degradation of the quality of the reproduced media stream.
また、悪意があるグループのメンバーは、フィードバック情報の任意の高い損失率が送付者に冗長情報の量のデータ伝送と増加を阻止させるか、または偽りパケット損失に対処するために他の行動を取ると報告できます(例えば、より少ないフレームを送るか、またはオーディオ/ビデオ画質を減少させてください)。 これは再生しているメディアの流れの品質の低下をもたらすかもしれません。
Ott, et al. Standards Track [Page 42] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[42ページ]。
Finally, a malicious group member can act as a large number of group members and thereby obtain an artificially large share of the Early feedback bandwidth and reduce the reactivity of the other group members -- possibly even causing them to no longer operate in Immediate or Early feedback mode and thus undermining the whole purpose of this profile.
悪意があるグループのメンバーは最終的に、多くのグループのメンバーとして務めて、その結果、Earlyフィードバック帯域幅の人工的に大きいシェアを得て、他のグループのメンバーの反動を抑えて、彼らがもうImmediateかEarlyフィードバックモードで作動しないことをことによると引き起こしさえして、その結果、このプロフィールの全体の目的をひそかに害することができます。
Senders as well as receivers SHOULD behave conservatively when observing strange reporting behavior. For excessive failure reporting from one or a few receivers, the sender MAY decide to no longer consider this feedback when adapting its transmission behavior for the media stream. In any case, senders and receivers SHOULD still adhere to the maximum RTCP bandwidth but make sure that they are capable of transmitting at least regularly scheduled RTCP packets. Senders SHOULD carefully consider how to adjust their transmission bandwidth when encountering strange reporting behavior; they MUST NOT increase their transmission bandwidth even if ignoring suspicious feedback.
振舞いを報告しながら奇妙な状態で見るとき、受信機SHOULDと同様に送付者は保守的に振る舞います。 1から報告する過度の失敗かいくつかの受信機に関しては、送付者は、メディアの流れのためのトランスミッションの振舞いを適合させるとき、もうこのフィードバックを考えないと決めるかもしれません。 どのような場合でも、送付者と受信機SHOULDは、まだ最大のRTCP帯域幅を固く守っていますが、彼らが少なくとも定期的に予定されているRTCPパケットを伝えることができるのを確実にします。 送付者SHOULDは慎重に奇妙な報告の振舞いに遭遇するとき、彼らのトランスミッション帯域幅を調整する方法を考えます。 疑わしげなフィードバックを無視しても、それらは自己のトランスミッション帯域幅を増加させてはいけません。
Attacks using false RTCP packets (Regular as well as Early ones) can be avoided by authenticating all RTCP messages. This can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [22]; as a prerequisite, an appropriate combination of those two profiles (an "SAVPF") is being specified [21]. Note that, when employing group authentication (as opposed to source authentication), the aforementioned attacks may be carried out by malicious or malfunctioning group members in possession of the right keying material.
すべてのRTCPメッセージを認証することによって、偽のRTCPパケット(Earlyものと同様に通常の)を使用する攻撃は避けることができます。 Secure RTPプロフィールと共に[22]で定義されるようにAVPFプロフィールを使用することによって、これを達成できます。 前提条件、それらの2の適切な組み合わせが("SAVPF")の輪郭を描くので、指定されるのは、[21]ですか? グループ認証(ソース認証と対照的に)を使うとき、前述の攻撃が材料を合わせながら権利の所有物で悪意があるか誤動作しているグループのメンバーによって行われるかもしれないことに注意してください。
9. IANA Considerations
9. IANA問題
The following contact information shall be used for all registrations included here:
以下の問い合わせ先はここにすべての登録証明書を含むのに使用されるものとします:
Contact: Joerg Ott
mailto:jo@acm.org
tel:+358-9-451-2460
接触: ヨルクオットmailto: jo@acm.org tel:+358-9-451-2460
The feedback profile as an extension to the profile for audio-visual conferences with minimal control has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/AVPF".
最小量のコントロールとの視聴覚の会議のためのプロフィールへの拡大としてのフィードバックプロフィールはSession記述プロトコルのために登録されました(明確にタイプ"proto"): "RTP/AVPF"。
Ott, et al. Standards Track [Page 43] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[43ページ]。
SDP Protocol ("proto"):
SDPは("proto")について議定書の中で述べます:
Name: RTP/AVPF
Long form: Extended RTP Profile with RTCP-based Feedback
Type of name: proto
Type of attribute: Media level only
Purpose: RFC 4585
Reference: RFC 4585
以下を命名してください。 RTP/AVPF Longは形成します: 名前のRTCPベースのFeedback Typeと拡張RTP Profile: 属性のproto Type: メディアはPurposeだけを平らにします: RFC4585参照: RFC4585
SDP Attribute ("att-field"):
SDPは(「att-分野」)を結果と考えます:
Attribute name: rtcp-fb
Long form: RTCP Feedback parameter
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: RFC 4585
Reference: RFC 4585
Values: See this document and registrations below
名前を結果と考えてください: rtcp-fb Longは形成します: 名前のRTCP FeedbackパラメタType: 属性のatt-分野Type: メディアはcharsetにSubjectだけを平らにします: 目的がありません: RFC4585参照: RFC4585値: このドキュメントと以下の登録証明書を見てください。
A new registry has been set up for the "rtcp-fb" attribute, with the following registrations created initially: "ack", "nack", "trr-int", and "app" as defined in this document.
以下の登録証明書が初めは作成されている状態で、新しい登録は"rtcp-fb"属性に設定されました: 本書では定義される"ack"、"nack"、"trr-int"、および「装置。」
Initial value registration for the attribute "rtcp-fb"
属性"rtcp-fb"のための初期の値の登録
Value name: ack
Long name: Positive acknowledgement
Reference: RFC 4585.
名前を評価してください: ack Longは以下を命名します。 積極的な承認Reference: RFC4585。
Value name: nack
Long name: Negative Acknowledgement
Reference: RFC 4585.
名前を評価してください: nack Longは以下を命名します。 否定的承認参照: RFC4585。
Value name: trr-int
Long name: Minimal receiver report interval
Reference: RFC 4585.
名前を評価してください: trr-int Longは以下を命名します。 最小量の受信機レポート間隔Reference: RFC4585。
Value name: app
Long name: Application-defined parameter
Reference: RFC 4585.
名前を評価してください: 装置Longは以下を命名します。 アプリケーションで定義されたパラメタReference: RFC4585。
Further entries may be registered on a first-come first-serve basis. Each new registration needs to indicate the parameter name and the syntax of possible additional arguments. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as
一層のエントリーは最初に来ている最初に、サーブベースで登録されるかもしれません。 各新規登録は、パラメタ名と可能な追加議論の構文を示す必要があります。 各新規登録に、登録されたパラメタ、構文の意味論を指定する永久的で、安定して、公的にアクセス可能なドキュメントが存在するのが、義務的であり、パラメタの意味論は良いです。
Ott, et al. Standards Track [Page 44] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[44ページ]。
corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
対応するフィードバックパケット・フォーマット(必要であるなら)。 [3]の一般的な登録手順は適用されます。
For use with both "ack" and "nack", a joint sub-registry has been set up that initially registers the following values:
"ack"と"nack"、サブ登録が持っているジョイントの両方でセットアップされた使用のために、それは初めは、以下の値を示します:
Initial value registration for the attribute values "ack" and "nack":
属性のための初期の値の登録は"ack"と"nack"を評価します:
Value name: sli
Long name: Slice Loss Indication
Usable with: nack
Reference: RFC 4585.
名前を評価してください: sli Longは以下を命名します。 以下でLoss Indication Usableを切ってください。 nack Reference: RFC4585。
Value name: pli
Long name: Picture Loss Indication
Usable with: nack
Reference: RFC 4585.
名前を評価してください: pli Longは以下を命名します。 以下でLoss Indication Usableについて描写してください。 nack Reference: RFC4585。
Value name: rpsi
Long name: Reference Picture Selection Indication
Usable with: ack, nack
Reference: RFC 4585.
名前を評価してください: rpsi Longは以下を命名します。 以下がある参照Picture Selection Indication Usable ack、nack Reference: RFC4585。
Value name: app
Long name: Application layer feedback
Usable with: ack, nack
Reference: RFC 4585.
名前を評価してください: 装置Longは以下を命名します。 以下がある応用層フィードバックUsable ack、nack Reference: RFC4585。
Further entries may be registered on a first-come first-serve basis. Each registration needs to indicate the parameter name, the syntax of possible additional arguments, and whether the parameter is applicable to "ack" or "nack" feedback or both or some different "rtcp-fb" attribute parameter. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
一層のエントリーは最初に来ている最初に、サーブベースで登録されるかもしれません。 各登録は、パラメタ名、"ack"か"nack"フィードバックか両方に可能な追加議論であってパラメタが適切であるかどうかに関する構文または何らかの異なった"rtcp-fb"属性パラメタを示す必要があります。 各新規登録に、対応するフィードバックパケット・フォーマットと同様にパラメタの登録されたパラメタの意味論、構文、および意味論を指定する永久的で、安定して、公的にアクセス可能なドキュメントが存在するのは(必要であるなら)、義務的です。 [3]の一般的な登録手順は適用されます。
Two RTCP Control Packet Types: for the class of transport layer FB
messages ("RTPFB") and for the class of payload-specific FB messages
("PSFB"). Per Section 6, RTPFB=205 and PSFB=206 have been added to
the RTCP registry.
2RTCPコントロールパケットはタイプされます: トランスポート層FBメッセージのクラス("RTPFB")とペイロード特有のFBメッセージのクラス("PSFB")のために。 セクション6に従って、RTPFB=205とPSFB=206はRTCP登録に加えられます。
Ott, et al. Standards Track [Page 45] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[45ページ]。
RTP RTCP Control Packet types (PT):
RTP RTCP Control Packetはタイプします(太平洋標準時の):
Name: RTPFB
Long name: Generic RTP Feedback
Value: 205
Reference: RFC 4585.
以下を命名してください。 RTPFB Longは以下を命名します。 一般的なRTPフィードバック価値: 205参照: RFC4585。
Name: PSFB
Long name: Payload-specific
Value: 206
Reference: RFC 4585.
以下を命名してください。 PSFB Longは以下を命名します。 有効搭載量特有の値: 206参照: RFC4585。
As AVPF defines additional RTCP payload types, the corresponding "reserved" RTP payload type space (72-76, as defined in [2]), has been expanded accordingly.
AVPFが追加RTCPを定義するとき、ペイロードはタイプされます、対応する「予約」RTPペイロードタイプスペース。(それに従って、[2])で定義される72-76を広げてあります。
A new sub-registry has been set up for the FMT values for both the RTPFB payload type and the PSFB payload type, with the following registrations created initially:
新しいサブ登録はRTPFBペイロードタイプとPSFBペイロードタイプの両方のためにFMT値に設定されました、以下の登録証明書が初めは作成されている状態で:
Within the RTPFB range, the following two format (FMT) values are initially registered:
RTPFB範囲の中では、以下の2形式(FMT)値は初めは、示されます:
Name: Generic NACK
Long name: Generic negative acknowledgement
Value: 1
Reference: RFC 4585.
以下を命名してください。 一般的なナックLongは以下を命名します。 一般的な否定的承認Value: 1つの参照: RFC4585。
Name: Extension
Long name: Reserved for future extensions
Value: 31
Reference: RFC 4585.
以下を命名してください。 拡大Longは以下を命名します。 将来の拡大Valueのために、予約されます: 31参照: RFC4585。
Within the PSFB range, the following five format (FMT) values are initially registered:
PSFB範囲の中では、以下の5形式(FMT)値は初めは、示されます:
Name: PLI
Long name: Picture Loss Indication
Value: 1
Reference: RFC 4585.
以下を命名してください。 PLI Longは以下を命名します。 損失指示価値について描写してください: 1つの参照: RFC4585。
Name: SLI
Long name: Slice Loss Indication
Value: 2
Reference: RFC 4585.
以下を命名してください。 SLI Longは以下を命名します。 損失指示価値を切ってください: 2参照: RFC4585。
Ott, et al. Standards Track [Page 46] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[46ページ]。
Name: RPSI
Long name: Reference Picture Selection Indication
Value: 3
Reference: RFC 4585.
以下を命名してください。 RPSI Longは以下を命名します。 参照絵の選択指示価値: 3参照: RFC4585。
Name: AFB
Long name: Application Layer Feedback
Value: 15
Reference: RFC 4585.
以下を命名してください。 AFB Longは以下を命名します。 応用層フィードバック価値: 15参照: RFC4585。
Name: Extension
Long name: Reserved for future extensions.
Value: 31
Reference: RFC 4585.
以下を命名してください。 拡大Longは以下を命名します。 今後の拡大のために、予約されます。 値: 31参照: RFC4585。
Further entries may be registered following the "Specification Required" rules as defined in RFC 2434 [9]. Each registration needs to indicate the FMT value, if there is a specific FB message to go into the FCI field, and whether or not multiple FB messages may be stacked in a single FCI field. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated FB message (if any). The general registration procedures of [3] apply.
「仕様が必要である」という規則に従って、一層のエントリーはRFC2434[9]で定義されるように登録されるかもしれません。 各登録は、FMT値を示す必要があります、FCI野原に入る特定のFBメッセージがあって、複数のFBメッセージがただ一つのFCI分野で積み重ねられるかもしれないか否かに関係なく。 各新規登録に、構文と同様に登録されたパラメタの意味論と関連FBメッセージ(もしあれば)の意味論を指定する永久的で、安定して、公的にアクセス可能なドキュメントが存在するのは、義務的です。 [3]の一般的な登録手順は適用されます。
10. Acknowledgements
10. 承認
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. The authors would like to thank Steve Casner and Colin Perkins for their comments and suggestions as well as for their responsiveness to numerous questions. The authors would also like to particularly thank Magnus Westerlund for his review and his valuable suggestions and Shigeru Fukunaga for the contributions on FB message formats and semantics.
このドキュメントはIETFのAudio視覚のTransport(AVT)作業部会の製品です。 作者は彼らのコメントと提案と多数の質問へのそれらの反応性についてスティーブCasnerとコリン・パーキンスに感謝したがっています。 また、作者はFBメッセージ・フォーマットと意味論における貢献のために彼の彼のレビュー、貴重な提案、およびShigeru Fukunagaについて特にマグヌスWesterlundに感謝したがっています。
We would also like to thank Andreas Buesching and people at Panasonic for their simulations and the first independent implementations of the feedback profile.
また、パナソニックで彼らのシミュレーションとフィードバックプロフィールの最初の独立している実現についてアンドレアスBueschingと人々に感謝申し上げます。
Ott, et al. Standards Track [Page 47] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[47ページ]。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[2] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[4]Casner、S.、「RTP制御プロトコル(RTCP)帯域幅へのセッション記述プロトコル(SDP)帯域幅修飾語」、RFC3556、2003年7月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[6]TurlettiとT.とC.Huitema、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[7] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
11.2. Informative References
11.2. 有益な参照
[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[10]キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[11] パーキンスとC.とO.ホドソン、「ストリーミング・メディアの修理のためのオプション」、RFC2354、1998年6月。
[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[12] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
Ott, et al. Standards Track [Page 48] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[48ページ]。
[13] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[13] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[14] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.
[14] ボルマン、C.、クライン、L.、Deisher、G.、Gardos、T.、Maciocco、C.、ヌーエル、D.、オット、J.、サリバン、G.、ウェンガー、S.、およびC.朱、「1998年のITU-T RecのバージョンのためのRTP有効搭載量形式。」 「H.263ビデオ(H.263+)」、RFC2429、1998年10月。
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile
video transmission", Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.
[15] B.ジロ、N.フェルバー、「可動の映像の送波のためのフィードバックベースの誤り制御」、Proceedings IEEE、Vol.87、No.10、ページ 1999年10月の1707--1723。
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001.
[16] ISO/IEC14496-2: 2001/Amd、.1:2002、「情報技術(視聴覚の物のコード化)Part2:」 2001に「視覚」
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication", November 2000.
[17] ITU-T推薦H.263、「少ないビット伝送速度コミュニケーションのためのビデオ符号化」、2000年11月。
[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[18] Schulzrinne、H.、およびS.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[19] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[20] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)", Work in Progress, December 2005.
[21] Progress、2005年12月のオットとJ.とE.カラーラ、「RTCPのベースのFeedback(RTP/SAVPF)のための拡張Secure RTP Profile」Work。
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[22]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[23] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams",
RFC 3016, November 2000.
[23] 菊池、Y.、野村、T.、Fukunaga、S.、松井、Y.、およびH.Kimata、「MPEG-4つのオーディオの、または、視覚の流れのためのRTP有効搭載量形式」、RFC3016(2000年11月)。
[24] ITU-T Recommendation H.245, "Control protocol for multimedia
communication", May 2006.
[24] ITU-T Recommendation H.245、「マルチメディア通信のための制御プロトコル」、2006年5月。
Ott, et al. Standards Track [Page 49] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[49ページ]。
Authors' Addresses
作者のアドレス
Joerg Ott Helsinki University of Technology (TKK) Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
技術(TKK)ネットワーク研究所私書箱3000フィン-02015TKKフィンランドのヨルクオットヘルシンキ大学
EMail: jo@acm.org
メール: jo@acm.org
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
シュテファン・ウェンガーノキアリサーチセンター私書箱100 33721タンペレフィンランド
EMail: stewe@stewe.org
メール: stewe@stewe.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi-city, Saitama 335-8510 Japan
ノリユキ佐藤沖電気工業株式会社1-16-8中央、蕨-都市、日本埼玉335-8510
Phone: +81 48 431 5932 Fax: +81 48 431 9115 EMail: sato652@oki.com
以下に電話をしてください。 +81 48 431 5932Fax: +81 48 431 9115はメールされます: sato652@oki.com
Carsten Burmeister Panasonic R&D Center Germany GmbH
カルステンバーマイスターパナソニック研究開発センタードイツGmbH
EMail: carsten.burmeister@eu.panasonic.com
メール: carsten.burmeister@eu.panasonic.com
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセレイパナソニック研究開発センタードイツGmbH Monzastr。 4c D-63225ランゲン(ドイツ)
EMail: jose.rey@eu.panasonic.com
メール: jose.rey@eu.panasonic.com
Ott, et al. Standards Track [Page 50] RFC 4585 RTP/AVPF July 2006
オット、他 規格はRTP/AVPF2006年7月にRFC4585を追跡します[50ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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/SHE 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Ott, et al. Standards Track [Page 51]
オット、他 標準化過程[51ページ]
一覧
スポンサーリンク
