RFC5104 日本語訳
5104 Codec Control Messages in the RTP Audio-Visual Profile withFeedback (AVPF). S. Wenger, U. Chandra, M. Westerlund, B. Burman. February 2008. (Format: TXT=158098 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Wenger
Request for Comments: 5104 U. Chandra
Category: Standards Track Nokia
M. Westerlund
B. Burman
Ericsson
February 2008
コメントを求めるワーキンググループS.ウェンガー要求をネットワークでつないでください: 5104年のU.チャンドラカテゴリ: ビルマの標準化過程のM.Westerlund B.エリクソンノキア2008年2月
Codec Control Messages in the
RTP Audio-Visual Profile with Feedback (AVPF)
フィードバックがある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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
このドキュメントはFeedback(AVPF)と共にAudio視覚のProfileで定義されたメッセージにいくつかの拡大を指定します。 それらは主として集結された多点の機能性が使用中である会話のマルチメディアシナリオで役立っています。 しかしながら、また、或るものも、よりわずかなマルチキャスト環境で使用可能です、そして、ポイントツーポイントは呼びます。
The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off.
議論した拡大はITU-T Recに関連するメッセージです。 H.271のビデオの戻っているチャンネル、完全なイントラ要求、一時的な最大のメディアはビット伝送速度的、そして、時、空間的なトレードオフを流します。
Wenger, et al. Standards Track [Page 1] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
2. Definitions .....................................................5
2.1. Glossary ...................................................5
2.2. Terminology ................................................5
2.3. Topologies .................................................8
3. Motivation ......................................................8
3.1. Use Cases ..................................................9
3.2. Using the Media Path ......................................11
3.3. Using AVPF ................................................11
3.3.1. Reliability ........................................12
3.4. Multicast .................................................12
3.5. Feedback Messages .........................................12
3.5.1. Full Intra Request Command .........................12
3.5.1.1. Reliability ...............................13
3.5.2. Temporal-Spatial Trade-off Request and
Notification .......................................14
3.5.2.1. Point-to-Point ............................15
3.5.2.2. Point-to-Multipoint Using
Multicast or Translators ..................15
3.5.2.3. Point-to-Multipoint Using RTP Mixer .......15
3.5.2.4. Reliability ...............................16
3.5.3. H.271 Video Back Channel Message ...................16
3.5.3.1. Reliability ...............................19
3.5.4. Temporary Maximum Media Stream Bit Rate
Request and Notification ...........................19
3.5.4.1. Behavior for Media Receivers Using TMMBR ..21
3.5.4.2. Algorithm for Establishing Current
Limitations ...............................23
3.5.4.3. Use of TMMBR in a Mixer-Based
Multipoint Operation ......................29
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators ..................30
3.5.4.5. Use of TMMBR in Point-to-Point Operation ..31
3.5.4.6. Reliability ...............................31
4. RTCP Receiver Report Extensions ................................32
4.1. Design Principles of the Extension Mechanism ..............32
4.2. Transport Layer Feedback Messages .........................33
4.2.1. Temporary Maximum Media Stream Bit Rate
Request (TMMBR) ....................................34
4.2.1.1. Message Format ............................34
4.2.1.2. Semantics .................................35
4.2.1.3. Timing Rules ..............................39
4.2.1.4. Handling in Translators and Mixers ........39
4.2.2. Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) ...............................39
4.2.2.1. Message Format ............................39
1. 序論…4 2. 定義…5 2.1. 用語集…5 2.2. 用語…5 2.3. Topologies…8 3. 動機…8 3.1. ケースを使用してください…9 3.2. メディア経路を使用します…11 3.3. AVPFを使用します…11 3.3.1. 信頼性…12 3.4. マルチキャスト…12 3.5. フィードバックメッセージ…12 3.5.1. 完全なイントラ要求コマンド…12 3.5.1.1. 信頼性…13 3.5.2. 時、空間的なトレードオフ要求と通知…14 3.5.2.1. ポイントツーポイント…15 3.5.2.2. マルチキャストか翻訳者を使用するポイントツーマルチポイント…15 3.5.2.3. RTPミキサーを使用するポイントツーマルチポイント…15 3.5.2.4. 信頼性…16 3.5.3. H.271のビデオの逆チャンネルメッセージ…16 3.5.3.1. 信頼性…19 3.5.4. 一時的な最大のメディアはビット伝送速度要求と通知を流します…19 3.5.4.1. TMMBRを使用するメディア受信機のための振舞い。21 3.5.4.2. 現在の制限を確立するためのアルゴリズム…23 3.5.4.3. ミキサーベースの多点操作におけるTMMBRの使用…29 3.5.4.4. マルチキャストか翻訳者を使用する多点へのポイントのTMMBRの使用…30 3.5.4.5. 指すポイントでのTMMBR操作の使用。31 3.5.4.6. 信頼性…31 4. RTCP受信機レポート拡張子…32 4.1. 拡大メカニズムのプリンシプルズを設計してください…32 4.2. 層のフィードバックメッセージを輸送してください…33 4.2.1. 一時的な最大のメディアはビット伝送速度要求(TMMBR)を流します…34 4.2.1.1. メッセージ形式…34 4.2.1.2. 意味論…35 4.2.1.3. タイミングは統治されます…39 4.2.1.4. 翻訳者とミキサーの取り扱い…39 4.2.2. 一時的な最大のメディアはビット伝送速度通知(TMMBN)を流します…39 4.2.2.1. メッセージ形式…39
Wenger, et al. Standards Track [Page 2] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[2ページ]。
4.2.2.2. Semantics .................................40
4.2.2.3. Timing Rules ..............................41
4.2.2.4. Handling by Translators and Mixers ........41
4.3. Payload-Specific Feedback Messages ........................41
4.3.1. Full Intra Request (FIR) ...........................42
4.3.1.1. Message Format ............................42
4.3.1.2. Semantics .................................43
4.3.1.3. Timing Rules ..............................44
4.3.1.4. Handling of FIR Message in Mixers and
Translators ...............................44
4.3.1.5. Remarks ...................................44
4.3.2. Temporal-Spatial Trade-off Request (TSTR) ..........45
4.3.2.1. Message Format ............................46
4.3.2.2. Semantics .................................46
4.3.2.3. Timing Rules ..............................47
4.3.2.4. Handling of Message in Mixers and
Translators ...............................47
4.3.2.5. Remarks ...................................47
4.3.3. Temporal-Spatial Trade-off Notification (TSTN) .....48
4.3.3.1. Message Format ............................48
4.3.3.2. Semantics .................................49
4.3.3.3. Timing Rules ..............................49
4.3.3.4. Handling of TSTN in Mixers and
Translators ...............................49
4.3.3.5. Remarks ...................................49
4.3.4. H.271 Video Back Channel Message (VBCM) ............50
4.3.4.1. Message Format ............................50
4.3.4.2. Semantics .................................51
4.3.4.3. Timing Rules ..............................52
4.3.4.4. Handling of Message in Mixers or
Translators ...............................52
4.3.4.5. Remarks ...................................52
5. Congestion Control .............................................52
6. Security Considerations ........................................53
7. SDP Definitions ................................................54
7.1. Extension of the rtcp-fb Attribute ........................54
7.2. Offer-Answer ..............................................55
7.3. Examples ..................................................56
8. IANA Considerations ............................................58
9. Contributors ...................................................60
10. Acknowledgements ..............................................60
11. References ....................................................60
11.1. Normative References .....................................60
11.2. Informative References ...................................61
4.2.2.2. 意味論…40 4.2.2.3. タイミングは統治されます…41 4.2.2.4. 翻訳者とミキサーによる取り扱い…41 4.3. 有効搭載量特有のフィードバックメッセージ…41 4.3.1. 完全なイントラ要求(モミ)…42 4.3.1.1. メッセージ形式…42 4.3.1.2. 意味論…43 4.3.1.3. タイミングは統治されます…44 4.3.1.4. ミキサーと翻訳者のモミメッセージの取り扱い…44 4.3.1.5. 所見…44 4.3.2. 時、空間的なトレードオフ要求(TSTR)…45 4.3.2.1. メッセージ形式…46 4.3.2.2. 意味論…46 4.3.2.3. タイミングは統治されます…47 4.3.2.4. ミキサーと翻訳者のメッセージの取り扱い…47 4.3.2.5. 所見…47 4.3.3. 時、空間的なトレードオフ通知(TSTN)…48 4.3.3.1. メッセージ形式…48 4.3.3.2. 意味論…49 4.3.3.3. タイミングは統治されます…49 4.3.3.4. ミキサーと翻訳者のTSTNの取り扱い…49 4.3.3.5. 所見…49 4.3.4. H.271ビデオ後部チャンネルメッセージ(VBCM)…50 4.3.4.1. メッセージ形式…50 4.3.4.2. 意味論…51 4.3.4.3. タイミングは統治されます…52 4.3.4.4. ミキサーか翻訳者のメッセージの取り扱い…52 4.3.4.5. 所見…52 5. 混雑コントロール…52 6. セキュリティ問題…53 7. SDP定義…54 7.1. rtcp-fb Attributeの拡大…54 7.2. 申し出で答えてください…55 7.3. 例…56 8. IANA問題…58 9. 貢献者…60 10. 承認…60 11. 参照…60 11.1. 標準の参照…60 11.2. 有益な参照…61
Wenger, et al. Standards Track [Page 3] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[3ページ]。
1. Introduction
1. 序論
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was developed, the main emphasis lay in the efficient support of point- to-point and small multipoint scenarios without centralized multipoint control. However, in practice, many small multipoint conferences operate utilizing devices known as Multipoint Control Units (MCUs). Long-standing experience of the conversational video conferencing industry suggests that there is a need for a few additional feedback messages, to support centralized multipoint conferencing efficiently. Some of the messages have applications beyond centralized multipoint, and this is indicated in the description of the message. This is especially true for the message intended to carry ITU-T Rec. H.271 [H.271] bit strings for Video Back Channel messages.
Feedback(AVPF)[RFC4585]とAudio視覚のProfileが開発されたとき、ポイントのポイントの、そして、小さい多点シナリオの効率的なサポートには主な強調が集結された多点コントロールなしでありました。 しかしながら、実際には、多くの小さいマルチポイント会議が、Multipoint Control Units(MCUs)として知られている装置を利用することで作動します。 会話のビデオ会議産業の長年の経験は、効率的に集結された多点会議を支持するためにいくつかの追加フィードバックメッセージの必要があるのを示します。 メッセージのいくつかには、集結された多点を超えてアプリケーションがあります、そして、これはメッセージの記述で示されます。 ITU-T Recを運ぶことを意図するメッセージに、これは特に本当です。 Video Back ChannelメッセージのためのH.271[H.271]ビット列。
In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs comprise mixers and translators. Most MCUs also include signaling support. During the development of this memo, it was noticed that there is considerable confusion in the community related to the use of terms such as mixer, translator, and MCU. In response to these concerns, a number of topologies have been identified that are of practical relevance to the industry, but are not documented in sufficient detail in [RFC3550]. These topologies are documented in [RFC5117], and understanding this memo requires previous or parallel study of [RFC5117].
レアル-時間Transportプロトコル(RTP)[RFC3550]用語では、MCUsはミキサーと翻訳者を包括します。 また、ほとんどのMCUsが、サポートに合図するのを含んでいます。 このメモの開発の間、かなりの混乱がミキサーや、翻訳者や、MCUなどの用語の使用に関連する共同体にあるのに気付かれました。 これらの関心に対応して、産業には実用的な関連性がありますが、詳細に十分な[RFC3550]に記録されない多くのtopologiesが特定されました。 これらのtopologiesは[RFC5117]に記録されます、そして、このメモを理解しているのは[RFC5117]の前の、または、平行な研究を必要とします。
Some of the messages defined here are forward only, in that they do not require an explicit notification to the message emitter that they have been received and/or indicating the message receiver's actions. Other messages require a response, leading to a two-way communication model that one could view as useful for control purposes. However, it is not the intention of this memo to open up RTP Control Protocol (RTCP) to a generalized control protocol. All mentioned messages have relatively strict real-time constraints, in the sense that their value diminishes with increased delay. This makes the use of more traditional control protocol means, such as Session Initiation Protocol (SIP) [RFC3261], undesirable when used for the same purpose. That is why this solution is recommended instead of "XML Schema for Media Control" [XML-MC], which uses SIP Info to transfer XML messages with similar semantics to what are defined in this memo. Furthermore, all messages are of a very simple format that can be easily processed by an RTP/RTCP sender/receiver. Finally, and most importantly, all messages relate only to the RTP stream with which they are associated, and not to any other property of a communication system. In particular, none of them relate to the properties of the access links traversed by the session.
彼らが単に、彼らが受け取る、そして/または、メッセージ受信機の動作を示しているというメッセージエミッタへの明白な通知を必要としないので、ここで定義されたメッセージのいくつかが前方にあります。 1つが管理目的の役に立つと見なすことができた双方向通信モデルに通じて、他のメッセージは応答を必要とします。 しかしながら、それはこのメモがRTP Controlプロトコル(RTCP)を一般化された制御プロトコルに開けるという意志ではありません。 すべてが、メッセージがそれらの値が増加する遅れで減少するという意味で比較的厳しいリアルタイムの規制を持っていると言及しました。 これは同じ目的に使用されると、より伝統的な制御プロトコルの使用をSession Initiationプロトコル(SIP)[RFC3261]などのように望ましくない手段にします。 それはこの解決策が推薦されて、移すのにSIP Infoを使用する「メディアコントロールのためのXML図式」[XML-M.C.]の代わりに同様の意味論があるXMLメッセージがこのメモで何と定義されるかということである理由です。 その上、すべてのメッセージがRTP/RTCP送付者/受信機で容易に処理できる非常に簡単な形式のものです。最終的に、最も重要に、すべてのメッセージが通信系のいかなる他の特性ではなく、それらが関連しているRTPの流れだけにも関係します。 特に、それらのいずれもセッションで横断されたアクセスリンクの特性に関連しません。
Wenger, et al. Standards Track [Page 4] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[4ページ]。
2. Definitions
2. 定義
2.1. Glossary
2.1. 用語集
AIMD - Additive Increase Multiplicative Decrease AVPF - The extended RTP profile for RTCP-based feedback FCI - Feedback Control Information [RFC4585] FEC - Forward Error Correction FIR - Full Intra Request MCU - Multipoint Control Unit MPEG - Moving Picture Experts Group PLI - Picture Loss Indication PR - Packet rate QP - Quantizer Parameter RTT - Round trip time SSRC - Synchronization Source TMMBN - Temporary Maximum Media Stream Bit Rate Notification TMMBR - Temporary Maximum Media Stream Bit Rate Request TSTN - Temporal-Spatial Trade-off Notification TSTR - Temporal-Spatial Trade-off Request VBCM - Video Back Channel Message
AIMD--付加的なIncrease Multiplicative Decrease AVPF--RTCPベースのフィードバックFCIのための拡張RTPプロフィール--フィードバックControl情報RFC4585 FEC--前進のError Correction FIR--完全なIntra Request MCU--多点Control Unit MPEG--Picture Experts Group PLIを動かします--絵のLoss Indication PR--パケットレート; QP--量子化器Parameter RTT--周遊旅行時間SSRC--同期Source TMMBN--一時的なMaximumメディアStream Bit Rate Notification TMMBR--一時的なMaximumメディアStream Bit Rate Request TSTN--時、空間的な下にTrade Notification TSTR--時、空間的な下にTrade Request VBCM--ビデオBack Channel Message
2.2. Terminology
2.2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Message:
An RTCP feedback message [RFC4585] defined by this
specification, of one of the following types:
メッセージ: 以下のタイプのひとりのこの仕様で定義されたRTCPフィードバックメッセージ[RFC4585]:
Request:
Message that requires acknowledgement
以下を要求してください。 承認を必要とするメッセージ
Command:
Message that forces the receiver to an action
コマンド: 動作に受信機を強制するメッセージ
Indication:
Message that reports a situation
指示: 状況を報告するメッセージ
Notification:
Message that provides a notification that an event has
occurred. Notifications are commonly generated in
response to a Request.
通知: 出来事が起こったという通知を提供するメッセージ。 通知は一般的にRequestに対応して発生します。
Note that, with the exception of "Notification", this terminology is in alignment with ITU-T Rec. H.245 [H245].
「通知」を除いて、この用語がITU-T Recとの整列中であることに注意してください。 H.245[H245]。
Wenger, et al. Standards Track [Page 5] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[5ページ]。
Decoder Refresh Point:
A bit string, packetized in one or more RTP packets, that
completely resets the decoder to a known state.
デコーダはポイントをリフレッシュします: 少し、ストリングであって、1つ以上のRTPパケットでpacketizedされていて、それは知られている状態にデコーダを完全にリセットします。
Examples for "hard" decoder refresh points are Intra pictures
in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and
Instantaneous Decoder Refresh (IDR) pictures in H.264.
"Gradual" decoder refresh points may also be used; see for
example [AVC]. While both "hard" and "gradual" decoder
refresh points are acceptable in the scope of this
specification, in most cases the user experience will benefit
from using a "hard" decoder refresh point.
「困難な」デコーダがポイントをリフレッシュするので、例はH.264のMPEG-4枚のH.261、H.263、MPEG-1、MPEG-2、第2部、およびInstantaneous Decoder Refresh(IDR)の絵のIntraの絵です。 「ゆるやか」デコーダはリフレッシュします。ポイントはそうするかもしれません、また、使用されてください、。 例えば、[AVC]を見てください。 ともに「困難で」「ゆるやかな」デコーダがリフレッシュしますが、ポイントがこの仕様の範囲で許容できる、多くの場合、「困難な」デコーダを使用している経験が利益を得るユーザはポイントをリフレッシュします。
A decoder refresh point also contains all header information
above the picture layer (or equivalent, depending on the video
compression standard) that is conveyed in-band. In H.264, for
example, a decoder refresh point contains parameter set
Network Adaptation Layer (NAL) units that generate parameter
sets necessary for the decoding of the following slice/data
partition NAL units (and that are not conveyed out of band).
デコーダはポイントをリフレッシュします。また、バンドで運ばれる絵の層(または、画像圧縮規格に依存する同等物)を超えてすべてのヘッダー情報を含んでいます。 例えばデコーダがリフレッシュするH.264では、ポイントは以下の部分/データパーティションNALユニットの解読に必要なパラメタセットを発生させるパラメタセットNetwork Adaptation Layer(NAL)単位を含んでいます(それはバンドから運ばれません)。
Decoding:
The operation of reconstructing the media stream.
解読します: メディアの流れを再建する操作。
Rendering:
The operation of presenting (parts of) the reconstructed media
stream to the user.
表現: 提示の操作、(離れている、)、再建されたメディアはユーザに流れます。
Stream thinning:
The operation of removing some of the packets from a media
stream. Stream thinning, preferably, is media-aware, implying
that media packets are removed in the order of increasing
relevance to the reproductive quality. However, even when
employing media-aware stream thinning, most media streams
quickly lose quality when subjected to increasing levels of
thinning. Media-unaware stream thinning leads to even worse
quality degradation. In contrast to transcoding, stream
thinning is typically seen as a computationally lightweight
operation.
間引きを流してください: メディアの流れからいくつかのパケットを取り除く操作。 望ましくは、流れの間引きはメディア意識しています、メディア向けの資料セットが増加する関連性の注文で生殖の品質に移されるのを含意して。 しかしながら、メディア意識している流れの間引きを使うときさえ、増加するレベルの間引きにかけられると、ほとんどのメディアの流れがすぐに品質を失います。 メディア気づかない流れの間引きはさらに悪い品質劣化につながります。 コード変換と対照して、流れの間引きは通常計算上軽量の操作と考えられます。
Media:
Often used (sometimes in conjunction with terms like bit rate,
stream, sender, etc.) to identify the content of the forward
RTP packet stream (carrying the codec data), to which the
codec control message applies.
メディア: コーデックコントロールメッセージが適用される前進のRTPパケットの流れ(コーデックデータを運ぶ)の内容を特定するのにおいてしばしば使用されています(時々ビット伝送速度、流れ、送付者などのような用語に関連した)。
Wenger, et al. Standards Track [Page 6] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[6ページ]。
Media Stream:
The stream of RTP packets labeled with a single
Synchronization Source (SSRC) carrying the media (and also in
some cases repair information such as retransmission or
Forward Error Correction (FEC) information).
メディアは流れます: RTPパケットの流れは運ぶ独身のSynchronization Source(SSRC)でメディアを分類しました(また、いくつかの場合、「再-トランスミッション」かForward Error Correction(FEC)情報などの情報を修理してください)。
Total media bit rate:
The total bits per second transferred in a media stream,
measured at an observer-selected protocol layer and averaged
over a reasonable timescale, the length of which depends on
the application. In general, a media sender and a media
receiver will observe different total media bit rates for the
same stream, first because they may have selected different
reference protocol layers, and second, because of changes in
per-packet overhead along the transmission path. The goal
with bit rate averaging is to be able to ignore any burstiness
on very short timescales (e.g., below 100 ms) introduced by
scheduling or link layer packetization effects.
メディアビット伝送速度を合計してください: 総bpsは観察者によって選択されたプロトコル層で測定されて、妥当なスケールの上で平均されたそれの長さをアプリケーションに依存するメディアの流れで移されました。 一般に、メディア送付者とメディア受信機は同じ流れに関して異なった総メディアビット伝送速度を観測するでしょう、最初に、彼らが異なった参照プロトコル層、および2番目を選択したかもしれないので、トランスミッション経路に沿った1パケットあたりのオーバーヘッドにおける変化のために。 ビット伝送速度平均がある目標はスケジューリングによって導入された非常に短いスケール(例えば、100未満ms)かリンクレイヤpacketization効果のどんなburstinessも無視することであることができます。
Maximum total media bit rate:
The upper limit on total media bit rate for a given media
stream at a particular receiver and for its selected protocol
layer. Note that this value cannot be measured on the
received media stream. Instead, it needs to be calculated or
determined through other means, such as quality of service
(QoS) negotiations or local resource limitations. Also note
that this value is an average (on a timescale that is
reasonable for the application) and that it may be different
from the instantaneous bit rate seen by packets in the media
stream.
最大の総メディアビット伝送速度: 特定の受信機の与えられたメディアの流れとその選択されたプロトコル層のための総メディアビット伝送速度の上限。 容認されたメディアの流れのときにこの値を測定できないことに注意してください。 代わりに、他の手段で計算されるか、または決定するのが必要です、サービスの質(QoS)交渉やローカル資源制限のように。 また、この値が平均(アプリケーションに、妥当なスケールの)であり、それがパケットによってメディアの流れで見られた瞬時に起こっているビット伝送速度と異なるかもしれないことに注意してください。
Overhead:
All protocol header information required to convey a packet
with media data from sender to receiver, from the application
layer down to a pre-defined protocol level (for example, down
to, and including, the IP header). Overhead may include, for
example, IP, UDP, and RTP headers, any layer 2 headers, any
Contributing Sources (CSRCs), RTP padding, and RTP header
extensions. Overhead excludes any RTP payload headers and the
payload itself.
オーバーヘッド: すべてのプロトコルヘッダー情報がメディアデータで送付者から受信機までパケットを運ぶのが必要です、応用層から事前に定義されたプロトコルレベルまで(例えば、下がる、包含、IPヘッダー、) オーバーヘッドは例えばIP、UDP、およびRTPヘッダーを含むかもしれなくて、いずれも2個のヘッダー、どんなContributing Sources(CSRCs)、RTP詰め物、およびRTPヘッダー拡張子も層にします。 オーバーヘッドはどんなRTPペイロードヘッダーとペイロード自体も除きます。
Net media bit rate:
The bit rate carried by a media stream, net of overhead. That
is, the bits per second accounted for by encoded media, any
applicable payload headers, and any directly associated meta
payload information placed in the RTP packet. A typical
example of the latter is redundancy data provided by the use
of RFC 2198 [RFC2198]. Note that, unlike the total media bit
ネットのメディアビット伝送速度: ビット伝送速度はメディアの流れ、オーバーヘッドのネットによって運ばれました。 bpsは、それが情報がRTPパケットに置いたどんな適切なペイロードヘッダーと、あらゆる直接関連しているメタペイロードであることもコード化されたメディアで説明しました。 後者の典型的な例はRFC2198[RFC2198]の使用で提供された冗長データです。 総メディアビットと異なってそれに注意してください。
Wenger, et al. Standards Track [Page 7] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[7ページ]。
rate, the net media bit rate will have the same value at the
media sender and at the media receiver unless any mixing or
translating of the media has occurred.
レート、メディアを混ぜるか、または翻訳するのが少しも起こっていないと、ネットのメディアビット伝送速度はメディア送付者においてメディア受信機に同じ値を持つでしょう。
For a given observer, the total media bit rate for a media
stream is equal to the sum of the net media bit rate and the
per-packet overhead as defined above multiplied by the packet
rate.
与えられた観察者にとって、メディアの流れのための総メディアビット伝送速度はネットのメディアビット伝送速度の合計と等しいです、そして、上で定義される1パケットあたりのオーバーヘッドはパケットレートを掛けました。
Feasible region:
The set of all combinations of packet rate and net media bit
rate that do not exceed the restrictions in maximum media bit
rate placed on a given media sender by the Temporary Maximum
Media Stream Bit Rate Request (TMMBR) messages it has
received. The feasible region will change as new TMMBR
messages are received.
可能な領域: 最大のメディアビット伝送速度における制限を超えていないパケットレートとネットのメディアビット伝送速度のすべての組み合わせのセットは与えられたメディア送付者でそれが受け取ったTemporary MaximumメディアStream Bit Rate Request(TMMBR)メッセージで入賞しました。 新しいTMMBRメッセージが受信されているとき、可能な領域は変化するでしょう。
Bounding set:
The set of TMMBR tuples, selected from all those received at a
given media sender, that define the feasible region for that
media sender. The media sender uses an algorithm such as that
in section 3.5.4.2 to determine or iteratively approximate the
current bounding set, and reports that set back to the media
receivers in a Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) message.
制限はセットしました: そのメディア送付者のために可能な領域を定義する与えられたメディア送付者に受け取られたすべてのものから選択されたTMMBR tuplesのセット。 メディア送付者はTemporary MaximumメディアStream Bit Rate Notification(TMMBN)メッセージでそれがメディア受信機に遅らせた現在の制限に決定するか、または繰り返しに近似する.2が、設定して、報告するセクション3.5.4におけるそれなどのアルゴリズムを使用します。
2.3. Topologies
2.3. Topologies
Please refer to [RFC5117] for an in-depth discussion. The topologies referred to throughout this memo are labeled (consistently with [RFC5117]) as follows:
徹底的な議論について[RFC5117]を参照してください。 このメモ中で言及されたtopologiesは以下の通りとラベルされます(一貫して[RFC5117]と共に):
Topo-Point-to-Point . . . . . Point-to-point communication Topo-Multicast . . . . . . . Multicast communication Topo-Translator . . . . . . . Translator based Topo-Mixer . . . . . . . . . Mixer based Topo-RTP-switch-MCU . . . . . RTP stream switching MCU Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP
指すトポポイント… …… . … . 翻訳者がTopo-ミキサーを基礎づけたというマルチキャストコミュニケーションTopo-翻訳者… 二地点間コミュニケーションTopo-マルチキャスト…MixerはTopo-RTPスイッチMCUを基礎づけました… RTPは、MCUを終えるMCU Topo-RTCPの. . ミキサーの、しかし、終わっているRTCPを切り換えながら、流れます。
3. Motivation
3. 動機
This section discusses the motivation and usage of the different video and media control messages. The video control messages have been under discussion for a long time, and a requirement document was drawn up [Basso]. That document has expired; however, we quote relevant sections of it to provide motivation and requirements.
このセクションは異なったビデオの動機と使用法を論じます、そして、メディアはメッセージを制御します。 ビデオコントロールメッセージは長い間、議論中であります、そして、要件ドキュメントは作成されました[低音部]。 そのドキュメントは期限が切れました。 しかしながら、私たちは、動機と要件を提供するために関連セクションのそれを引用します。
Wenger, et al. Standards Track [Page 8] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[8ページ]。
3.1. Use Cases
3.1. ケースを使用してください。
There are a number of possible usages for the proposed feedback messages. Let us begin by looking through the use cases Basso et al. [Basso] proposed. Some of the use cases have been reformulated and comments have been added.
提案されたフィードバックメッセージのための多くの可能な用法があります。 使用に目を通すことによって、ケースBasso他を始めましょう。 [低音部]は提案しました。 使用では、いくつか、ケースは再定式化されました、そして、コメントは加えられます。
1. An RTP video mixer composes multiple encoded video sources into a
single encoded video stream. Each time a video source is added,
the RTP mixer needs to request a decoder refresh point from the
video source, so as to start an uncorrupted prediction chain on
the spatial area of the mixed picture occupied by the data from
the new video source.
1. RTPビデオミキサーはただ一つのコード化されたビデオストリームの中に複数のコード化されたビデオソースを構成します。 ビデオソースが加えられる各回、デコーダを要求するRTPミキサーの必要性はビデオソースからのポイントをリフレッシュします、新しいビデオソースからのデータによって占領された複雑な状況の空間的な領域に腐敗していない予測チェーンを始動するために。
2. An RTP video mixer receives multiple encoded RTP video streams
from conference participants, and dynamically selects one of the
streams to be included in its output RTP stream. At the time of a
bit stream change (determined through means such as voice
activation or the user interface), the mixer requests a decoder
refresh point from the remote source, in order to avoid using
unrelated content as reference data for inter picture prediction.
After requesting the decoder refresh point, the video mixer stops
the delivery of the current RTP stream and monitors the RTP stream
from the new source until it detects data belonging to the decoder
refresh point. At that time, the RTP mixer starts forwarding the
newly selected stream to the receiver(s).
2. RTPビデオミキサーは、会議の参加者から複数のコード化されたRTPビデオストリームを受けて、流れの1つが出力RTPの流れで含まれているのをダイナミックに選択します。 しばらく流れの変化(音声駆動かユーザーインタフェースなどの手段で、決定する)時点で、ミキサー要求aデコーダはリモートソースからのポイントをリフレッシュします、間の絵の予測に参考資料として関係ない内容を使用するのを避けるために。 ビデオミキサーは現在のRTPの流れの配送を止めます、そして、デコーダを要求した後に、ポイントをリフレッシュしてください、そして、データがデコーダに属すのを検出するまで、RTPが新しいソースから流すモニターはポイントをリフレッシュします。 その時、RTPミキサーは新たに選択された流れを受信機に送り始めます。
3. An application needs to signal to the remote encoder that the
desired trade-off between temporal and spatial resolution has
changed. For example, one user may prefer a higher frame rate and
a lower spatial quality, and another user may prefer the opposite.
This choice is also highly content dependent. Many current video
conferencing systems offer in the user interface a mechanism to
make this selection, usually in the form of a slider. The
mechanism is helpful in point-to-point, centralized multipoint and
non-centralized multipoint uses.
3. アプリケーションは、時の、そして、空間的な解決の間の必要なトレードオフが変えたリモートエンコーダに合図する必要があります。 例えば、1人のユーザが、より高いフレームレートと下側の空間的な品質を好むかもしれません、そして、別のユーザは正反対を好むかもしれません。 この選択は非常にも満足している扶養家族です。 多くの現在のビデオ会議システムがこの選択をするようにユーザーインタフェースでメカニズムを提供します、通常スライダーの形で。 メカニズムは、役立っている指すポイントの、そして、集結された多点と非集結された多点用途です。
4. Use case 4 of the Basso document applies only to Picture Loss
Indication (PLI) as defined in AVPF [RFC4585] and is not
reproduced here.
4. 4通のBassoドキュメントがAVPFで[RFC4585]を定義して、ここで再生しないPicture Loss Indication(PLI)だけに適用するケースを使用してください。
5. Use case 5 of the Basso document relates to a mechanism known as
"freeze picture request". Sending freeze picture requests over a
non-reliable forward RTCP channel has been identified as
problematic. Therefore, no freeze picture request has been
included in this memo, and the use case discussion is not
reproduced here.
5. 5通のBassoドキュメントが「凍結絵の要求」として知られているメカニズムに関係づけるケースを使用してください。 前方で非高信頼のRTCPチャンネルの上に凍結絵の要求を送るのは問題の多いとして特定されました。 したがって、凍結は全くこのメモ、および使用に含まれていません絵が、要求する。ケース議論はここで再生しません。
Wenger, et al. Standards Track [Page 9] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[9ページ]。
6. A video mixer dynamically selects one of the received video
streams to be sent out to participants and tries to provide the
highest bit rate possible to all participants, while minimizing
stream trans-rating. One way of achieving this is to set up
sessions with endpoints using the maximum bit rate accepted by
each endpoint, and accepted by the call admission method used by
the mixer. By means of commands that reduce the maximum media
stream bit rate below what has been negotiated during session set
up, the mixer can reduce the maximum bit rate sent by endpoints to
the lowest of all the accepted bit rates. As the lowest accepted
bit rate changes due to endpoints joining and leaving or due to
network congestion, the mixer can adjust the limits at which
endpoints can send their streams to match the new value. The
mixer then requests a new maximum bit rate, which is equal to or
less than the maximum bit rate negotiated at session setup for a
specific media stream, and the remote endpoint can respond with
the actual bit rate that it can support.
6. ビデオミキサーは、流れの移-格付けを最小にしている間、容認されたビデオストリームの1つが関係者に出されるのをダイナミックに選択して、すべての関係者にとって、可能な最も高いビット伝送速度を提供しようとします。 これを達成する1つの方法は各終点によって受け入れられて、ミキサーによって使用されるコール許可方法で受け入れられた最大のビット伝送速度を使用する終点とのセッションをセットアップすることです。 最大のメディアを減少させるコマンドによって、セッションの間に交渉されていることの下における流れのビット伝送速度はセットアップされて、ミキサーは終点によってすべての受け入れられたビット伝送速度で最も低く送られた最大のビット伝送速度を減少させることができます。 最も低いのがネットワークの混雑を接合して、残すか、ネットワークの混雑による終点によるビット伝送速度変化を受け入れたので、ミキサーは終点が新しい値を合わせるために彼らの流れを送ることができる限界を調整できます。 そして、ミキサーは、特定のメディアの流れには、等しいか、またはセッションセットアップで交渉された最大のビット伝送速度より少ない最大の新しいビット伝送速度と遠く離れた終点がそれが支持できる実際のビット伝送速度で応じることができるよう要求します。
The picture Basso, et al., draw up covers most applications we foresee. However, we would like to extend the list with two additional use cases:
絵のBasso(他)は私たちが見通すほとんどのアプリケーションをカバーに引き込みます。 しかしながら、追加使用がケースに入れる2でリストを広げたいと思います:
7. Currently deployed congestion control algorithms (AIMD and TCP
Friendly Rate Control (TFRC) [RFC3448]) probe for additional
available capacity as long as there is something to send. With
congestion control algorithms using packet loss as the indication
for congestion, this probing generally results in reduced media
quality (often to a point where the distortion is large enough to
make the media unusable), due to packet loss and increased delay.
7. 何か送るものがある限り、現在配備された輻輳制御アルゴリズム(AIMDとTCP Friendly Rate Control(TFRC)[RFC3448])は追加有効な容量のために調べられます。 輻輳制御アルゴリズムが混雑に指示としてパケット損失を使用していて、一般に、この調べは減少しているメディア品質(しばしばひずみがメディアを使用不可能にすることができるくらい大きいポイントへの)をもたらします、パケット損失と増加する遅れのため。
In a number of deployment scenarios, especially cellular ones, the
bottleneck link is often the last hop link. That cellular link
also commonly has some type of QoS negotiation enabling the
cellular device to learn the maximal bit rate available over this
last hop. A media receiver behind this link can, in most (if not
all) cases, calculate at least an upper bound for the bit rate
available for each media stream it presently receives. How this
is done is an implementation detail and not discussed herein.
Indicating the maximum available bit rate to the transmitting
party for the various media streams can be beneficial to prevent
that party from probing for bandwidth for this stream in excess of
a known hard limit. For cellular or other mobile devices, the
known available bit rate for each stream (deduced from the link
bit rate) can change quickly, due to handover to another
transmission technology, QoS renegotiation due to congestion, etc.
To enable minimal disruption of service, quick convergence is
necessary, and therefore media path signaling is desirable.
多くの展開シナリオ、特にセルのものでは、しばしばボトルネックリンクは最後のホップリンクです。 また、そのセルリンクには、一般的に、セル装置がこの最後のホップの上で有効な最大限度のビット伝送速度を学ぶのを可能にするタイプのQoS交渉があります。 ほとんどの(すべて)場合では、このリンクの後ろのメディア受信機はそれが現在受けるそれぞれのメディアの流れに有効なビット伝送速度のために少なくとも上限について計算できます。 これがどう完了しているかは、詳細でここに議論されなかった実現です。 様々なメディアの流れのために最大の有効なビット伝送速度を伝えるパーティーに示すのは、そのパーティーがこの流れのために知られている困難な限界を超えて帯域幅に調べるのを防ぐのに有益である場合があります。 セルの、または、他のモバイル機器に関しては、各流れ(リンクビット伝送速度から、推論される)のための知られている有効なビット伝送速度は急速に変化できます、別のトランスミッション技術への引き渡し、混雑によるQoS renegotiationなどのため 最小量のサービスの分裂を可能にするのに、迅速な集合が必要です、そして、したがって、メディア経路シグナリングは望ましいです。
Wenger, et al. Standards Track [Page 10] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[10ページ]。
8. The use of reference picture selection (RPS) as an error
resilience tool was introduced in 1997 as NEWPRED [NEWPRED], and
is now widely deployed. When RPS is in use, simplistically put,
the receiver can send a feedback message to the sender,
indicating a reference picture that should be used for future
prediction. ([NEWPRED] mentions other forms of feedback as
well.) AVPF contains a mechanism for conveying such a message,
but did not specify for which codec and according to which syntax
the message should conform. Recently, the ITU-T finalized Rec.
H.271, which (among other message types) also includes a feedback
message. It is expected that this feedback message will fairly
quickly enjoy wide support. Therefore, a mechanism to convey
feedback messages according to H.271 appears to be desirable.
8. 誤り弾力ツールとしての参照絵の選択(RPS)の使用は、1997年にNEWPRED[NEWPRED]として導入されて、現在、広く配備されます。 RPSが使用中に、simplisticallyに置かれるとき、受信機はフィードバックメッセージを送付者に送ることができます、今後の予測に使用されるべきである参照の絵を示して。 ([NEWPRED]はまた、他のフォームのフィードバックに言及します。) AVPFはどのコーデックとメッセージがどの構文を従わせるべきであるかに従って指定しなかったのを除いて、そのようなメッセージを伝えるためのメカニズムを含んでいます。 最近、ITU-TはRecを成立させました。 H.271。(また、そのH.271はフィードバックメッセージを含んでいます(他のメッセージタイプで))。 このフィードバックメッセージがすぐに幅広い支持を公正に楽しむと予想されます。 したがって、H.271に従ってフィードバックメッセージを伝えるメカニズムは望ましいように見えます。
3.2. Using the Media Path
3.2. メディア経路を使用します。
There are two reasons why we use the media path for the codec control messages.
私たちがコーデックコントロールメッセージにメディア経路を使用する2つの理由があります。
First, systems employing MCUs often separate the control and media processing parts. As these messages are intended for or generated by the media part rather than the signaling part of the MCU, having them on the media path avoids transmission across interfaces and unnecessary control traffic between signaling and processing. If the MCU is physically decomposed, the use of the media path avoids the need for media control protocol extensions (e.g., in media gateway control (MEGACO) [RFC3525]).
まず最初に、MCUsを使うシステムがしばしば部品を加工処理するコントロールとメディアを切り離します。 これらのメッセージはMCUのシグナリング部分よりむしろ部分が意図するか、またはメディアによって発生するとき、メディア経路にそれらを持っていると、トランスミッションはシグナリングと処理の間のインタフェースと不要なコントロール交通の向こう側に避けられます。 MCUが物理的に分解されるなら、メディア経路の使用はメディア制御プロトコル拡大(例えば、メディアゲートウェイコントロール(MEGACO)[RFC3525]における)の必要性を避けます。
Secondly, the signaling path quite commonly contains several signaling entities, e.g., SIP proxies and application servers. Avoiding going through signaling entities avoids delay for several reasons. Proxies have less stringent delay requirements than media processing, and due to their complex and more generic nature may result in significant processing delay. The topological locations of the signaling entities are also commonly not optimized for minimal delay, but rather towards other architectural goals. Thus, the signaling path can be significantly longer in both geographical and delay sense.
第二に、シグナリング経路が全く一般的にいくつかのシグナリング実体を含んでいて、例えば、SIPはプロキシとアプリケーション・サーバーです。 シグナリング実体に直面しているのを避けるのがいくつかの理由で遅れを避けます。 プロキシには、厳しい遅れ要件よりメディア処理があります、そして、彼らの複雑でより一般的な本質への支払われるべきものは重要な処理遅れをもたらすかもしれません。 シグナリング実体の位相的な位置はまた、最小量の遅れのために一般的に最適化されるのではなく、むしろ他の建築目標に向かって最適化されます。 したがって、シグナリング経路はともに地理的、そして、遅れ意味はかなり長い場合があります。
3.3. Using AVPF
3.3. AVPFを使用します。
The AVPF feedback message framework [RFC4585] provides the appropriate framework to implement the new messages. AVPF implements rules controlling the timing of feedback messages to avoid congestion through network flooding by RTCP traffic. We re-use these rules by referencing AVPF.
AVPFフィードバックメッセージ枠組み[RFC4585]は、新しいメッセージを実行するために適切な枠組みを提供します。 AVPFはRTCP交通でネットワーク氾濫による混雑を避けるフィードバックメッセージのタイミングを制御する規則を実行します。 私たちは、AVPFに参照をつけることによって、これらの規則を再使用します。
Wenger, et al. Standards Track [Page 11] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[11ページ]。
The signaling setup for AVPF allows each individual type of function to be configured or negotiated on an RTP session basis.
AVPFのためのシグナリングセットアップは、それぞれの独特のタイプの関数がRTPセッションベースに関して構成されるか、または交渉されるのを許容します。
3.3.1. Reliability
3.3.1. 信頼性
The use of RTCP messages implies that each message transfer is unreliable, unless the lower layer transport provides reliability. The different messages proposed in this specification have different requirements in terms of reliability. However, in all cases, the reaction to an (occasional) loss of a feedback message is specified.
下層輸送が信頼性を提供しない場合、RTCPメッセージの使用は、それぞれのメッセージ転送が頼り無いのを含意します。 この仕様で提案された異なったメッセージは信頼性に関して異なった要件を持っています。 しかしながら、すべての場合では、フィードバックメッセージの(時々)の損失への反応は指定されます。
3.4. Multicast
3.4. マルチキャスト
The codec control messages might be used with multicast. The RTCP timing rules specified in [RFC3550] and [RFC4585] ensure that the messages do not cause overload of the RTCP connection. The use of multicast may result in the reception of messages with inconsistent semantics. The reaction to inconsistencies depends on the message type, and is discussed for each message type separately.
コーデックコントロールメッセージはマルチキャストと共に使用されるかもしれません。 [RFC3550]と[RFC4585]で指定されたRTCPタイミング規則は、メッセージがRTCP接続のオーバーロードを引き起こさないのを確実にします。 マルチキャストの使用は首尾一貫しない意味論があるメッセージのレセプションをもたらすかもしれません。 矛盾への反応について、メッセージタイプに頼っていて、それぞれのメッセージタイプのために別々に議論します。
3.5. Feedback Messages
3.5. フィードバックメッセージ
This section describes the semantics of the different feedback messages and how they apply to the different use cases.
このセクションは異なったフィードバックメッセージとそれらがどう異なった使用にケースを適用するかに関する意味論について説明します。
3.5.1. Full Intra Request Command
3.5.1. 完全なイントラ要求コマンド
A Full Intra Request (FIR) Command, when received by the designated media sender, requires that the media sender sends a Decoder Refresh Point (see section 2.2) at the earliest opportunity. The evaluation of such an opportunity includes the current encoder coding strategy and the current available network resources.
指定されたメディア送付者によって受け取られると、Full Intra Request(FIR)コマンドは、メディア送付者ができるだけ早い機会に、Decoder Refresh Point(セクション2.2を見る)を送るのを必要とします。 そのような機会の評価は戦略をコード化する現在のエンコーダと現在の利用可能なネットワーク資源を含んでいます。
FIR is also known as an "instantaneous decoder refresh request", "fast video update request" or "video fast update request".
また、FIRは「瞬時に起こっているデコーダは要求をリフレッシュする」か、「速いビデオ更新要求」または「ビデオの速い更新要求」として知られています。
Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream. For predictive media types that are not video, the analogue applies. For example, if in MPEG-4 systems scene updates are used, the decoder refresh point consists of the full representation of the scene and is not delta-coded relative to previous updates.
どんなその後の絵のコード化の過程の参照も流れを送ったとき、デコーダがリフレッシュするaをどんな絵も使用するのを控えるポイントが含意する使用するのがそのポイント前で発信しました。 ビデオでない予言のメディアタイプのために、アナログは申し込まれます。 例えば、場面アップデートがMPEG-4台のシステムで使用されているなら、デコーダはリフレッシュします。ポイントは、場面の完全な上演から成って、デルタによって前のアップデートに比例してコード化されていません。
Wenger, et al. Standards Track [Page 12] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[12ページ]。
Decoder refresh points, especially Intra or IDR pictures, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration.
一般に、デコーダは、何度かサイズで予測された絵より大きい状態でポイント、特にIntraまたはIDRの絵をリフレッシュして、あります。 したがって、有効なビット伝送速度が小さく、デコーダの使用がリフレッシュするということであるシナリオでは、ポイントは典型的な絵の持続時間よりかなり長い遅れを含意します。
Usage in multicast is possible; however, aggregation of the commands is recommended. A receiver that receives a request closely after sending a decoder refresh point -- within 2 times the longest round trip time (RTT) known, plus any AVPF-induced RTCP packet sending delays -- should await a second request message to ensure that the media receiver has not been served by the previously delivered decoder refresh point. The reason for the specified delay is to avoid sending unnecessary decoder refresh points. A session participant may have sent its own request while another participant's request was in-flight to them. Suppressing those requests that may have been sent without knowledge about the other request avoids this issue.
マルチキャストにおける用法は可能です。 しかしながら、コマンドの集合はお勧めです。 デコーダを送ると最も長い周遊旅行の知られている時間(RTT)、および遅れを送るどんなAVPFによって誘発されたRTCPパケットの2倍の中のポイントがリフレッシュした後に密接に要求を受け取る受信機は受信機が以前に渡されたデコーダによって役立たれていないメディアがポイントをリフレッシュするのを保証する2番目の要求メッセージを待つはずです。 理由は、指定された遅れが不要なデコーダを送るのを避けることであるので、ポイントをリフレッシュします。 別の関係者の要求がそれらに機内であった間、セッション関係者はそれ自身の要求を送ったかもしれません。 もう片方の要求に関する知識なしで送られたかもしれないそれらの要求を抑圧すると、この問題は避けられます。
Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for precisely that purpose.
エラーを回復するFIRコマンドを使用するのは明らかに禁じられます、そして、代わりに、AVPF[RFC4585]で定義されたPLIメッセージは使用されるべきです。 PLIメッセージは、無くなっている絵を報告して、正確にその目的のためのAVPFに含まれています。
Full Intra Request is applicable in use-cases 1 and 2.
完全なIntra Requestはケースを使用している1と2で適切です。
3.5.1.1. Reliability
3.5.1.1. 信頼性
The FIR message results in the delivery of a decoder refresh point, unless the message is lost. Decoder refresh points are easily identifiable from the bit stream. Therefore, there is no need for protocol-level notification, and a simple command repetition mechanism is sufficient for ensuring the level of reliability required. However, the potential use of repetition does require a mechanism to prevent the recipient from responding to messages already received and responded to.
メッセージが無くならない場合、デコーダの配送におけるFIRメッセージ結果はポイントをリフレッシュします。 デコーダはリフレッシュします。ポイントはビットストリームから容易に身元保証可能です。 したがって、プロトコルレベル通知の必要は全くありません、そして、信頼性のレベルが必要であることを確実にするのに簡単なコマンド反復メカニズムは十分です。 しかしながら、反復の潜在的使用は、受取人が既に受け取られて、応じるメッセージに応じるのを防ぐためにメカニズムを必要とします。
To ensure the best possible reliability, a sender of FIR may repeat the FIR until the desired content has been received. The repetition interval is determined by the RTCP timing rules applicable to the session. Upon reception of a complete decoder refresh point or the detection of an attempt to send a decoder refresh point (which got damaged due to a packet loss), the repetition of the FIR must stop. If another FIR is necessary, the request sequence number must be increased. A FIR sender shall not have more than one FIR (different request sequence number) outstanding at any time per media sender in the session.
可能な限り良い信頼性を確実にするために、FIRの送付者は必要な内容を受け取るまでFIRを繰り返すかもしれません。 反復間隔はセッションに適切なRTCPタイミング規則で決定します。 完全なデコーダのレセプションでは、ポイントをリフレッシュしてください。さもないと、デコーダを送る試みの検出はポイント(パケット損失のため破損しました)(FIR欠かせない立ち寄り先の反復)をリフレッシュします。 別のFIRが必要であるなら、要求一連番号は増加しなければなりません。 FIR送付者はセッションのいつでもメディア送付者あたりの未払いの1FIR(異なった要求一連番号)を持っていないものとします。
Wenger, et al. Standards Track [Page 13] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[13ページ]。
The receiver of FIR (i.e., the media sender) behaves in complementary fashion to ensure delivery of a decoder refresh point. If it receives repetitions of the FIR more than 2*RTT after it has sent a decoder refresh point, it shall send a new decoder refresh point. Two round trip times allow time for the decoder refresh point to arrive back to the requestor and for the end of repetitions of FIR to reach and be detected by the media sender.
(すなわち、メディア送付者)がデコーダの配送を確実にするために補足的なファッションで反応させるFIRの受信機はポイントをリフレッシュします。 それがデコーダを送った後に2*RTTがポイントをリフレッシュするより新しいデコーダを送るものとする、FIRの反復を受けるなら、ポイントをリフレッシュしてください。 要請者とFIRの反復の終わりに達するように帰って来て、メディア送付者によって検出されるように、回がデコーダのための時間を許容する2周遊旅行はポイントをリフレッシュします。
An RTP mixer or RTP switching MCU that receive a FIR from a media receiver is responsible to ensure that a decoder refresh point is delivered to the requesting receiver. It may be necessary for the mixer/MCU to generate FIR commands. From a reliability perspective, the two legs (FIR-requesting endpoint to mixer/MCU, and mixer/MCU to decoder refresh point generating endpoint) are handled independently from each other.
デコーダがポイントをリフレッシュするのを要求受信機に渡します。ミキサー/MCUがFIRコマンドを発生させるのが必要であるかもしれないことを保証するのにおいてメディア受信機からFIRを受けるMCUを切り換えるRTPミキサーかRTPが原因となります。 信頼性の見解から、2本の脚(終点をFIR要求して、ミキサー/MCU、およびデコーダへのMCUがリフレッシュするミキサー/に、終点を発生させながら、指す)が互いから独自に扱われます。
3.5.2. Temporal-Spatial Trade-off Request and Notification
3.5.2. 時、空間的なトレードオフ要求と通知
The Temporal-Spatial Trade-off Request (TSTR) instructs the video encoder to change its trade-off between temporal and spatial resolution. Index values from 0 to 31 indicate monotonically a desire for higher frame rate. That is, a requester asking for an index of 0 prefers a high quality and is willing to accept a low frame rate, whereas a requester asking for 31 wishes a high frame rate, potentially at the cost of low spatial quality.
Temporal空間的な下にTrade Request(TSTR)は、時の、そして、空間的な解決の間でトレードオフを変えるようビデオエンコーダに命令します。 0〜31までのインデックス値は、より高いフレームレートに関する願望を単調に示します。 すなわち、0のインデックスを求めるリクエスタは、高い品質を好んで、低フレームレートにもかかわらず、リクエスタが低空間的な品質の費用で潜在的に高いフレームレートに31の願望を求めますが、受け入れても構わないと思っています。
In general, the encoder reaction time may be significantly longer than the typical picture duration. See use case 3 for an example. The encoder decides whether and to what extent the request results in a change of the trade-off. It returns a Temporal-Spatial Trade-off Notification (TSTN) message to indicate the trade-off that it will use henceforth.
一般に、エンコーダ反応時間は典型的な絵の持続時間よりかなり長いかもしれません。 使用が例のために3をケースに入れるのを見てください。 エンコーダが決める、そして、要求はトレードオフの変化をどんな範囲にもたらしますか? それはそれが今後は使用するトレードオフを示すTemporal空間的な下にTrade Notification(TSTN)メッセージを返します。
TSTR and TSTN have been introduced primarily because it is believed that control protocol mechanisms, e.g., a SIP re-invite, are too heavyweight and too slow to allow for a reasonable user experience. Consider, for example, a user interface where the remote user selects the temporal/spatial trade-off with a slider. An immediate feedback to any slider movement is required for a reasonable user experience. A SIP re-INVITE [RFC3261] would require at least two round-trips more (compared to the TSTR/TSTN mechanism) and may involve proxies and other complex mechanisms. Even in a well-designed system, it could take a second or so until the new trade-off is finally selected. Furthermore, the use of RTCP solves the multicast use case very efficiently.
主として制御プロトコルメカニズム(例えば、SIP再招待)がヘビー級の、そして、考慮できないくらい遅過ぎる合理的なユーザー・エクスペリエンスであると信じられているので、TSTRとTSTNを導入しました。 リモート・ユーザーがスライダーによる時の、または、空間的なトレードオフを選択するところで例えばユーザーインタフェースを考えてください。 どんなスライダー運動への即座のフィードバックも合理的なユーザー・エクスペリエンスに必要です。 SIP再INVITE[RFC3261]は少なくとももう2つの周遊旅行(TSTR/TSTNメカニズムと比較される)を必要として、プロキシと他の複雑なメカニズムにかかわるかもしれません。よく設計されたシステムでさえ、新しいトレードオフが最終的に選択されるまで、それはおよそ1秒かかることができました。 その上、RTCPの使用は使用が非常に効率的にケースに入れるマルチキャストを解決します。
The use of TSTR and TSTN in multipoint scenarios is a non-trivial subject, and can be achieved in many implementation-specific ways.
多点シナリオのTSTRとTSTNの使用は、重要な対象であり、多くの実現特有の方法で達成できます。
Wenger, et al. Standards Track [Page 14] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[14ページ]。
Problems stem from the fact that TSTRs will typically arrive unsynchronized, and may request different trade-off values for the same stream and/or endpoint encoder. This memo does not specify a translator's, mixer's, or endpoint's reaction to the reception of a suggested trade-off as conveyed in the TSTR. We only require the receiver of a TSTR message to reply to it by sending a TSTN, carrying the new trade-off chosen by its own criteria (which may or may not be based on the trade-off conveyed by the TSTR). In other words, the trade-off sent in a TSTR is a non-binding recommendation, nothing more.
TSTRsが通常到着するという事実からの問題軸は、同じ流れ、そして/または、終点エンコーダのための異なったトレードオフ値を非連動して、要求するかもしれません。 このメモはTSTRを運ばれるように提案されたトレードオフのレセプションへの翻訳者、ミキサー、または終点の反応を指定しません。 私たちはTSTNを送ることによってそれに答えるTSTRメッセージの受信機を必要とするだけです、それ自身の評価基準(TSTRによって伝えられたトレードオフに基づくかもしれない)によって選ばれた新しいトレードオフを運んで。 言い換えれば、トレードオフは、TSTRが拘束力がない推薦、何もより多くないものであることを送りました。
Three TSTR/TSTN scenarios need to be distinguished, based on the topologies described in [RFC5117]. The scenarios are described in the following subsections.
3つのTSTR/TSTNシナリオが、[RFC5117]で説明されたtopologiesに基づいて区別される必要があります。 シナリオは以下の小区分で説明されます。
3.5.2.1. Point-to-Point
3.5.2.1. ポイントツーポイント
In this most trivial case (Topo-Point-to-Point), the media sender typically adjusts its temporal/spatial trade-off based on the requested value in TSTR, subject to its own capabilities. The TSTN message conveys back the new trade-off value (which may be identical to the old one if, for example, the sender is not capable of adjusting its trade-off).
この最も些細な場合(指すトポポイント)では、メディア送付者はTSTRでそれ自身の能力を条件として要求された値に基づく時の、または、空間的なトレードオフを通常調整します。 TSTNメッセージは新しいトレードオフ値(例えば、送付者がトレードオフを調整できないなら、古い方と同じであるかもしれない)を伝えて戻します。
3.5.2.2. Point-to-Multipoint Using Multicast or Translators
3.5.2.2. マルチキャストか翻訳者を使用するポイントツーマルチポイント
RTCP Multicast is used either with media multicast according to Topo-Multicast, or following RFC 3550's translator model according to Topo-Translator. In these cases, unsynchronized TSTR messages from different receivers may be received, possibly with different requested trade-offs (because of different user preferences). This memo does not specify how the media sender tunes its trade-off. Possible strategies include selecting the mean or median of all trade-off requests received, giving priority to certain participants, or continuing to use the previously selected trade-off (e.g., when the sender is not capable of adjusting it). Again, all TSTR messages need to be acknowledged by TSTN, and the value conveyed back has to reflect the decision made.
Topo-翻訳者によると、RTCP MulticastはTopo-マルチキャストに従ったメディアマルチキャスト、または次のRFC3550の翻訳者モデルと共に使用されます。 これらの場合では、異なった受信機からのunsynchronized TSTRメッセージを受け取るかもしれません、ことによると異なった要求されたトレードオフ(異なったユーザー選択による)で。 このメモはメディア送付者がどうトレードオフを調整するかを指定しません。 可能な戦略は、要求が受けたすべてのトレードオフの平均かメディアンを選択するのを含んでいます、確信している関係者を最優先させるか、または以前に選択されたトレードオフを使用し続けていて(例えば、送付者はいつそれを調整できませんか)。 一方、すべてのTSTRメッセージが、TSTNによって承認される必要があります、そして、伝えて戻された値は人工で決定を反映しなければなりません。
3.5.2.3. Point-to-Multipoint Using RTP Mixer
3.5.2.3. RTPミキサーを使用するポイントツーマルチポイント
In this scenario (Topo-Mixer), the RTP mixer receives all TSTR messages, and has the opportunity to act on them based on its own criteria. In most cases, the mixer should form a "consensus" of potentially conflicting TSTR messages arriving from different participants, and initiate its own TSTR message(s) to the media sender(s). As in the previous scenario, the strategy for forming
このシナリオ(トポミキサー)では、RTPミキサーは、それ自身の評価基準に基づいてすべてのTSTRメッセージを受け取って、それらに影響する機会を持っています。 多くの場合、ミキサーは、異なった関係者から到着する潜在的に闘争しているTSTRメッセージの「コンセンサス」を形成して、それ自身のTSTRメッセージをメディア送付者に開始するはずです。 シナリオ、形成するための前の戦略として
Wenger, et al. Standards Track [Page 15] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[15ページ]。
this "consensus" is up to the implementation, and can, for example, encompass averaging the participants' request values, giving priority to certain participants, or using session default values.
この「コンセンサス」は、実現まであって、例えば、関係者の要求が評価する平均を取り囲むことができます、確信している関係者に優先的に取り扱うか、またはセッションデフォルト値を使用して。
Even if a mixer or translator performs transcoding, it is very difficult to deliver media with the requested trade-off, unless the content the mixer or translator receives is already close to that trade-off. Thus, if the mixer changes its trade-off, it needs to request the media sender(s) to use the new value, by creating a TSTR of its own. Upon reaching a decision on the used trade-off, it includes that value in the acknowledgement to the downstream requestors. Only in cases where the original source has substantially higher quality (and bit rate) is it likely that transcoding alone can result in the requested trade-off.
ミキサーか翻訳者がコード変換を実行しても、要求されたトレードオフと共にメディアを渡すのは非常に難しいです、そのトレードオフの近くにミキサーか翻訳者が受け取る内容が既にない場合。 したがって、ミキサーがトレードオフを変えるなら、新しい値を使用するようメディア送付者に要求するのが必要です、それ自身のTSTRを作成することによって。 中古のトレードオフのときに決断を下すと、それは承認で川下の要請者にその値を含めます。 一次資料が実質的により高い品質(そして、ビット伝送速度)を持っている場合だけでは、それはそのコード変換だけが要求されたトレードオフをもたらすことができる傾向があります。
3.5.2.4. Reliability
3.5.2.4. 信頼性
A request and reception acknowledgement mechanism is specified. The Temporal-Spatial Trade-off Notification (TSTN) message informs the requester that its request has been received, and what trade-off is used henceforth. This acknowledgement mechanism is desirable for at least the following reasons:
要求とレセプション承認メカニズムは指定されます。 Temporal空間的な下にTrade Notification(TSTN)メッセージは要求を受け取って、どんなトレードオフが今後は使用されるかがそうすることをリクエスタに知らせます。 この承認メカニズムは少なくとも以下の理由で望ましいです:
o A change in the trade-off cannot be directly identified from the
media bit stream.
o User feedback cannot be implemented without knowing the chosen
trade-off value, according to the media sender's constraints.
o Repetitive sending of messages requesting an unimplementable
trade-off can be avoided.
o 選ばれたトレードオフ値を知らないで、o Userフィードバックを実行できません、メディア送付者の規制に従って。メディアビットストリームからトレードオフにおける変化を直接特定できません。非実行可能トレードオフを要求するメッセージのo Repetitive発信は避けることができます。
3.5.3. H.271 Video Back Channel Message
3.5.3. H.271のビデオの逆チャンネルメッセージ
ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder reaction to a Video Back Channel Message. The structure defined in this memo is used to transparently convey such a message from media receiver to media sender. In this memo, we refrain from an in-depth discussion of the available code points within H.271 and refer to the specification text [H.271] instead.
ITU-T Rec。 H.271は構文、意味論、およびVideo Back Channel Messageへの提案されたエンコーダ反応を定義します。 このメモで定義された構造は、メディア受信機からメディア送付者まで透明にそのようなメッセージを伝えるのに使用されます。 このメモでは、私たちは、H.271の中に利用可能なコード・ポイントの徹底的な議論を控えて、代わりに、仕様テキスト[H.271]を参照します。
However, we note that some H.271 messages bear similarities with native messages of AVPF and this memo. Furthermore, we note that some H.271 message are known to require caution in multicast environments -- or are plainly not usable in multicast or multipoint scenarios. Table 1 provides a brief, simplified overview of the messages currently defined in H.271, their roughly corresponding AVPF or Codec Control Messages (CCMs) (the latter as specified in this memo), and an indication of our current knowledge of their multicast safety.
しかしながら、私たちは、いくつかのH.271メッセージにはAVPFの固有のメッセージとこのメモがある類似性があることに注意します。 その上、私たちは、何らかのH.271メッセージがマルチキャスト環境における警告を必要とするのが知られていることに注意します--または、マルチキャストか多点シナリオで明らかに使用可能ではありません。 テーブル1はそれらの簡潔なCodec Control Messages、現在H.271で定義されているメッセージの簡易型の概観、およそ対応するAVPFまたはCodec Control Messages(CCMs)に(指定されるとしてのこのメモによる後者)、および彼らのマルチキャスト安全に関する私たちの現在の知識のしるしを供給します。
Wenger, et al. Standards Track [Page 16] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[16ページ]。
H.271 msg type AVPF/CCM msg type multicast-safe
--------------------------------------------------------------------
0 (when used for
reference picture
selection) AVPF RPSI No (positive ACK of pictures)
1 picture loss AVPF PLI Yes
2 partial loss AVPF SLI Yes
3 one parameter CRC N/A Yes (no required sender action)
4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes
H.271 msgタイプAVPF/CCM msgはマルチキャスト金庫をタイプします。-------------------------------------------------------------------- 0、(いつが参照絵の選択) AVPF RPSIノー(絵の積極的なACK)の1枚の絵の損失AVPF PLIにはい、2の部分的な損失AVPF SLIを使用したか、はい、3の1つのパラメタのCRC N/A、はい、(必要な送付者動作がありません)4、すべてのパラメタCRC N/、(必要な送付者動作がありません)5がリフレッシュするはいがCCM FIRを指す、はい。
Table 1: H.271 messages and their AVPF/CCM equivalents
テーブル1: H.271メッセージとそれらのAVPF/CCM同等物
Note: H.271 message type 0 is not a strict equivalent to
AVPF's Reference Picture Selection Indication (RPSI); it is an
indication of known-as-correct reference picture(s) at the
decoder. It does not command an encoder to use a defined
reference picture (the form of control information envisioned
to be carried in RPSI). However, it is believed and intended
that H.271 message type 0 will be used for the same purpose as
AVPF's RPSI -- although other use forms are also possible.
以下に注意してください。 H.271メッセージタイプ0はAVPFのReference Picture Selection Indication(RPSI)と厳しい同等物ではありません。 それが指示である、同じくらい正しい状態で知られていて、デコーダで絵に参照をつけてください。 それは、エンコーダが定義された参照の絵(RPSIで運ばれるために思い描かれた制御情報のフォーム)を使用すると命令しません。 しかしながら、H.271メッセージタイプ0がAVPFのRPSIと同じ目的に使用されることを信じられていて、意図します--他の使用ですが、また、フォームも可能です。
In response to the opaqueness of the H.271 messages, especially with respect to the multicast safety, the following guidelines MUST be followed when an implementation wishes to employ the H.271 video back channel message:
実現がH.271のビデオの逆チャンネルメッセージを使いたがっているとき、H.271メッセージの不透明に対応して、特にマルチキャスト安全に関して、以下のガイドラインに従わなければなりません:
1. Implementations utilizing the H.271 feedback message MUST stay in
compliance with congestion control principles, as outlined in
section 5.
1. H.271フィードバックメッセージを利用する実現は輻輳制御原則に従ってセクション5で概説されているように残らなければなりません。
2. An implementation SHOULD utilize the IETF-native messages as
defined in [RFC4585] and in this memo instead of similar messages
defined in [H.271]. Our current understanding of similar messages
is documented in Table 1 above. One good reason to divert from
the SHOULD statement above would be if it is clearly understood
that, for a given application and video compression standard, the
aforementioned "similarity" is not given, in contrast to what the
table indicates.
2. [RFC4585]とこのメモで定義されて、SHOULDが[H.271]で定義された同様のメッセージの代わりにネイティブのIETFメッセージを利用する実現。 私たちの同様のメッセージの現在の理解は上のTable1に記録されます。 上のSHOULD声明から転換する1つのもっともな理由は前述の「類似性」が与えられたアプリケーションと画像圧縮規格において与えられていないのが明確に理解されているかどうかということでしょう、テーブルが示すことと対照して。
3. It has been observed that some of the H.271 code points currently
in existence are not multicast-safe. Therefore, the sensible
thing to do is not to use the H.271 feedback message type in
multicast environments. It MAY be used only when all the issues
mentioned later are fully understood by the implementer, and
properly taken into account by all endpoints. In all other cases,
the H.271 message type MUST NOT be used in conjunction with
multicast.
3. 現在現存するいくつかのH.271コード・ポイントがマルチキャスト安全でないと認められました。 したがって、する分別があることはマルチキャスト環境でH.271フィードバックメッセージタイプを使用しないことです。 それは、後で参照されたすべての問題がimplementerに完全に解釈されるときだけ、使用されて、すべての終点によって適切に考慮に入れられるかもしれません。 他のすべての場合では、マルチキャストに関連してH.271メッセージタイプを使用してはいけません。
Wenger, et al. Standards Track [Page 17] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[17ページ]。
4. It has been observed that even in centralized multipoint
environments, where the mixer should theoretically be able to
resolve issues as documented below, the implementation of such a
mixer and cooperative endpoints is a very difficult and tedious
task. Therefore, H.271 messages MUST NOT be used in centralized
multipoint scenarios, unless all the issues mentioned below are
fully understood by the implementer, and properly taken into
account by both mixer and endpoints.
4. 集結された多点環境でさえ、そのようなミキサーと協力的な終点の実現が非常に難しくて退屈なタスクであることが観測されました。(そこでは、ミキサーが以下に記録されるように理論的に問題を解決するはずであることができます)。 したがって、集結された多点シナリオでH.271メッセージを使用してはいけません、以下に参照されたすべての問題がimplementerによって完全に理解されて、ミキサーと終点の両方によって適切に考慮に入れられない場合。
Issues to be taken into account when considering the use of H.271 in multipoint environments:
多点環境におけるH.271の使用を考えるとき考慮に入れられるべき問題:
1. Different state on different receivers. In many environments, it
cannot be guaranteed that the decoder state of all media receivers
is identical at any given point in time. The most obvious reason
for such a possible misalignment of state is a loss that occurs on
the path to only one of many media receivers. However, there are
other not so obvious reasons, such as recent joins to the
multipoint conference (be it by joining the multicast group or
through additional mixer output). Different states can lead the
media receivers to issue potentially contradicting H.271 messages
(or one media receiver issuing an H.271 message that, when
observed by the media sender, is not helpful for the other media
receivers). A naive reaction of the media sender to these
contradicting messages can lead to unpredictable and annoying
results.
1. 異なった受信機の異なった状態。 多くの環境で、時間内にのポイントを考えて、すべてのメディア受信機のデコーダ状態がいずれでも同じであることを保証できません。 状態のそのような可能な調整不良の最も明白な理由は経路に1つだけに発生する多くのメディア受信機の損失です。 しかしながら、他のあまりに明白でない理由があって、最近としてのそのようなものはマルチポイント会議につなぎます(マルチキャストグループに加わることか追加ミキサー出力にかかわらず)。 異なった州は、メディア受信機が潜在的にH.271メッセージを反駁に発行するように導くことができます(他のメディア受信機において、メディア送付者によって観測されるとH.271メッセージにそれを発行する1台のメディア受信機は役立っていません)。 メッセージに矛盾するこれらへのメディア送付者のナイーブな反応は予測できないで煩わしい結果につながることができます。
2. Combining messages from different media receivers in a media
sender is a non-trivial task. As reasons, we note that these
messages may be contradicting each other, and that their transport
is unreliable (there may well be other reasons). In case of many
H.271 messages (i.e., types 0, 2, 3, and 4), the algorithm for
combining must be aware both of the network/protocol environment
(i.e., with respect to congestion) and of the media codec
employed, as H.271 messages of a given type can have different
semantics for different media codecs.
2. メディア送付者で異なったメディア受信機からのメッセージを結合するのは、重要なタスクです。 理由として、私たちはこれらのメッセージが互いに逆らっているかもしれなくて、彼らの輸送が頼り無いことに注意します(たぶん、他の理由があるでしょう)。 多くのH.271メッセージ(すなわち、0、2、3、および4をタイプする)の場合には、結合するためのアルゴリズムはネットワーク/プロトコル環境(すなわち、混雑に関する)と与えられたタイプに関するH.271メッセージが異なったメディアコーデックのための異なった意味論を持つことができるので使われたメディアコーデックを知っているに違いありません。
3. The suppression of requests may need to go beyond the basic
mechanisms described in AVPF (which are driven exclusively by
timing and transport considerations on the protocol level). For
example, a receiver is often required to refrain from (or delay)
generating requests, based on information it receives from the
media stream. For instance, it makes no sense for a receiver to
issue a FIR when a transmission of an Intra/IDR picture is
ongoing.
3. 要求の秘匿は、AVPF(排他的にタイミングによって動かされて、プロトコルレベルで問題を輸送する)で説明された基本的機構を越える必要があるかもしれません。 例えば、受信機が要求を発生させるのを控えること(延着する)にしばしば必要です、それがメディアの流れから受け取る情報に基づいて。 例えば、受信機のために、Intra/IDRの絵のトランスミッションが進行中であるときに、FIRを発行するのは理解できません。
Wenger, et al. Standards Track [Page 18] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[18ページ]。
4. When using the non-multicast-safe messages (e.g., H.271 type 0
positive ACK of received pictures/slices) in larger multicast
groups, the media receiver will likely be forced to delay or even
omit sending these messages. For the media sender, this looks
like data has not been properly received (although it was received
properly), and a naively implemented media sender reacts to these
perceived problems where it should not.
4. より大きいマルチキャストグループに非マルチキャストの金庫メッセージ(例えば、H.271は容認された絵/部分の0の積極的なACKをタイプする)を使用するとき、延着するか、またはメディア受信機は、これらのメッセージを送るのをおそらくやむを得ず忘れるだろうというのさえ。 メディア送付者に関しては、これは、データが適切に受け取られていない(適切にそれを受け取りましたが)ように見えます、そして、純真に実行されたメディア送付者はそれがそうするべきでない問題であると知覚されたこれらに反応します。
3.5.3.1. Reliability
3.5.3.1. 信頼性
H.271 Video Back Channel Messages do not require reliable transmission, and confirmation of the reception of a message can be derived from the forward video bit stream. Therefore, no specific reception acknowledgement is specified.
H.271ビデオBack Channel Messagesは信頼できるトランスミッションを必要としません、そして、前進のビデオビットストリームからメッセージのレセプションの確認を得ることができます。 したがって、どんな特定のレセプション承認も指定されません。
With respect to re-sending rules, section 3.5.1.1 applies.
再送規則、.1が適用するセクション3.5.1に関して。
3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification
3.5.4. 一時的な最大のメディアはビット伝送速度要求と通知を流します。
A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber") to request a sender to limit the maximum bit rate for a media stream (see section 2.2) to, or below, the provided value. The Temporary Maximum Media Stream Bit Rate Notification (TMMBN) contains the media sender's current view of the most limiting subset of the TMMBR-defined limits it has received, to help the participants to suppress TMMBRs that would not further restrict the media sender. The primary usage for the TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case 6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo- Point-to-Point.
受信機、翻訳者、またはミキサーが、メディアの流れ(セクション2.2を見る)のために値、または、提供された値の下が最大のビット伝送速度を制限するよう送付者に要求するのに、Temporary MaximumメディアStream Bit Rate Request(TMMBR、「材木」)を使用します。 Temporary MaximumメディアStream Bit Rate Notification(TMMBN)は、関係者がさらにメディア送付者を制限しないTMMBRsを抑圧するのを助けるためにメディア送付者のそれが受けたTMMBRによって定義された限界の最も多くの制限部分集合の現在の視点を含んでいます。 TMMBR/TMMBNメッセージのための第一の用法がシナリオにMCUかミキサーであります(ケース6を使用してください)、Topo-翻訳者かTopo-ミキサーに対応していますが、Topoに、ポイントをまた示してください。
Each temporary limitation on the media stream is expressed as a tuple. The first component of the tuple is the maximum total media bit rate (as defined in section 2.2) that the media receiver is currently prepared to accept for this media stream. The second component is the per-packet overhead that the media receiver has observed for this media stream at its chosen reference protocol layer.
メディアの流れのそれぞれの一時的な制限はtupleとして言い表されます。 tupleの最初の部品はメディア受信機が現在このメディアの流れのために受け入れるように準備される最大の総メディアビット伝送速度(セクション2.2で定義されるように)です。 1パケットあたり2番目のコンポーネントはメディア受信機が選ばれた参照プロトコル層のこのメディアの流れに関して観察したオーバーヘッドです。
As indicated in section 2.2, the overhead as observed by the sender of the TMMBR (i.e., the media receiver) may differ from the overhead observed at the receiver of the TMMBR (i.e., the media sender) due to use of a different reference protocol layer at the other end or due to the intervention of translators or mixers that affect the amount of per packet overhead. For example, a gateway in between the two that converts between IPv4 and IPv6 affects the per-packet overhead by 20 bytes. Other mechanisms that change the overhead include tunnels. The problem with varying overhead is also discussed in
セクション2.2にみられるように、TMMBR(すなわち、メディア受信機)の送付者によって観察されるオーバーヘッドはパケットオーバーヘッド単位でもう一方の端の異なった参照プロトコル層か翻訳者かミキサーの介入のためそれを使用するのにおいて当然の(すなわち、メディア送付者)が量に影響するTMMBRの受信機で観察されたオーバーヘッドと異なるかもしれません。 例えば、2つの間のIPv4とIPv6の間で変換されるゲートウェイは1パケットあたりのオーバーヘッドに20バイト影響します。 オーバーヘッドを変える他のメカニズムがトンネルを含んでいます。 またオーバーヘッドについて議論する異なるのに関する問題
Wenger, et al. Standards Track [Page 19] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[19ページ]。
[RFC3890]. As will be seen in the description of the algorithm for use of TMMBR, the difference in perceived overhead between the sending and receiving ends presents no difficulty because calculations are carried out in terms of variables that have the same value at the sender as at the receiver -- for example, packet rate and net media rate.
[RFC3890。] TMMBRの使用のためのアルゴリズムの記述で見られるように、計算が受信機のように送付者における同じ値を持っている変数で行われるので、発信と犠牲者の間の知覚されたオーバーヘッドの違いは困難を全く提示しません--例えば、パケットレートとネットのメディアは評価します。
Reporting both maximum total media bit rate and per-packet overhead allows different receivers to provide bit rate and overhead values for different protocol layers, for example, at the IP level, at the outer part of a tunnel protocol, or at the link layer. The protocol level a peer reports on depends on the level of integration the peer has, as it needs to be able to extract the information from that protocol level. For example, an application with no knowledge of the IP version it is running over cannot meaningfully determine the overhead of the IP header, and hence will not want to include IP overhead in the overhead or maximum total media bit rate calculation.
最大の総メディアビット伝送速度と1パケットあたりのオーバーヘッドの両方を報告するのに、例えば、異なった受信機はIPレベルにおいて、または、トンネルプロトコルの外側の部分において、または、リンクレイヤでビット伝送速度と頭上の値を異なったプロトコル層に供給できます。 同輩がオンであると報告するプロトコルレベルを同輩が持っている統合のレベルに依存します、そのプロトコルレベルから情報を抜粋できるのが必要であるときに。 例えば、それがひいているIPバージョンに関する知識のないアプリケーションは、意味深長にIPヘッダーのオーバーヘッドを決定できないで、したがって、頭上の、または、最大の総メディアビット伝送速度計算におけるIPオーバーヘッドを含みたくならないでしょう。
It is expected that most peers will be able to report values at least for the IP layer. In certain implementations, it may be advantageous to also include information pertaining to the link layer, which in turn allows for a more precise overhead calculation and a better optimization of connectivity resources.
ほとんどの同輩が少なくともIP層のために値を報告できると予想されます。 ある実現では、また、リンクレイヤに関係する情報を含んでいるのは有利であるかもしれません。(順番に、情報は頭上で、より正確な計算と接続性リソースの、より良い最適化を考慮します)。
The Temporary Maximum Media Stream Bit Rate messages are generic messages that can be applied to any RTP packet stream. This separates them from the other codec control messages defined in this specification, which apply only to specific media types or payload formats. The TMMBR functionality applies to the transport, and the requirements the transport places on the media encoding.
Temporary MaximumメディアStream Bit RateメッセージはどんなRTPパケットの流れにも適用できる一般的なメッセージです。 これは特定のメディアタイプかこの仕様に基づき定義された他のコーデックコントロールメッセージだけからペイロード形式までそれらを切り離します。(メッセージは適用されます)。 TMMBRの機能性はメディアコード化の輸送場所を輸送、および要件に適用します。
The reasoning below assumes that the participants have negotiated a session maximum bit rate, using a signaling protocol. This value can be global, for example, in case of point-to-point, multicast, or translators. It may also be local between the participant and the peer or mixer. In either case, the bit rate negotiated in signaling is the one that the participant guarantees to be able to handle (depacketize and decode). In practice, the connectivity of the participant also influences the negotiated value -- it does not make much sense to negotiate a total media bit rate that one's network interface does not support.
シグナリングプロトコルを使用して、以下での推理は、関係者がセッションの最大のビット伝送速度を交渉したと仮定します。 この値は例えば、ポイントツーポイント、マルチキャスト、または翻訳者の場合にグローバルである場合があります。 また、それも関係者と同輩かミキサーの間で地方であるかもしれません。 どちらかの場合では、シグナリングで交渉されたビット伝送速度は関係者が扱うことができるのを(depacketizeして、解読します)保証するものです。 また、実際には、関係者の接続性は交渉された値に影響を及ぼします--それは人のネットワーク・インターフェースが支持しない総メディアビット伝送速度を交渉する多くの意味になりません。
It is also beneficial to have negotiated a maximum packet rate for the session or sender. RFC 3890 provides an SDP [RFC4566] attribute that can be used for this purpose; however, that attribute is not usable in RTP sessions established using offer/answer [RFC3264]. Therefore, an optional maximum packet rate signaling parameter is specified in this memo.
また、最大のパケットレートにセッションか送付者を交渉したのも有益です。 RFC3890はこのために使用できるSDP[RFC4566]属性を提供します。 しかしながら、その属性は申し出/答え[RFC3264]を使用することで確立されたRTPセッションのときに使用可能ではありません。 したがって、任意の最大のパケットレートシグナリングパラメタはこのメモで指定されます。
Wenger, et al. Standards Track [Page 20] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[20ページ]。
An already established maximum total media bit rate may be changed at any time, subject to the timing rules governing the sending of feedback messages. The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling. However, even if a sender has received a TMMBR message allowing an increase in the bit rate, all increases must be governed by a congestion control mechanism. TMMBR indicates known limitations only, usually in the local environment, and does not provide any guarantees about the full path. Furthermore, any increases in TMMBR-established bit rate limits are to be executed only after a certain delay from the sending of the TMMBN message that notifies the world about the increase in limit. The delay is specified as at least twice the longest RTT as known by the media sender, plus the media sender's calculation of the required wait time for the sending of another TMMBR message for this session based on AVPF timing rules. This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower.
いつでも、フィードバックメッセージの発信を治めるタイミング規則を条件として既に確立した最大の総メディアビット伝送速度を変えるかもしれません。 限界はセッション設立シグナリングの間、交渉されるようにゼロとセッション最大の間でどんな値にも変化するかもしれません。 しかしながら、送付者がビット伝送速度の増加を許容するTMMBRメッセージを受け取ったとしても、混雑制御機構ですべての増加を管理しなければなりません。 TMMBRは通常、地方の環境で知られている制限だけを示して、フルパスに関してどんな保証も提供しません。 その上、TMMBRが確立したビット伝送速度限界のどんな増加もある遅れの後にだけ限界の増加に関して世界に通知するTMMBNメッセージの発信から実行されることです。 このセッションへの別のTMMBRメッセージの発信がタイミングをAVPFに基礎づけたので少なくとも最も長い必要な待ち時間がメディア送付者、およびメディア送付者の計算で知られているRTTの2倍が統治するように遅れは指定されます。 他のセッション関係者が彼らの低いかもしれないビット伝送速度限界要件を明らかにするのを許容するためにこの遅れを導入します。
If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol.
セッションの残りに有効であるのがTMMBRによって示された新しい値がなるありそうであるなら、TMMBR送付者がセッションシグナリングプロトコルを使用することでセッション上限の再交渉を実行すると予想されます。
3.5.4.1. Behavior for Media Receivers Using TMMBR
3.5.4.1. TMMBRを使用するメディア受信機のための振舞い
This section is an informal description of behaviour described more precisely in section 4.2.
このセクションはセクション4.2で、より正確に説明されたふるまいの非公式の記述です。
A media sender begins the session limited by the maximum media bit rate and maximum packet rate negotiated in session signaling, if any. Note that this value may be negotiated for another protocol layer than the one the participant uses in its TMMBR messages. Each media receiver selects a reference protocol layer, forms an estimate of the overhead it is observing (or estimating it if no packets has been seen yet) at that reference level, and determines the maximum total media bit rate it can accept, taking into account its own limitations and any transport path limitations of which it may be aware. In case the current limitations are more restricting than what was agreed on in the session signaling, the media receiver reports its initial estimate of these two quantities to the media sender using a TMMBR message. Overall message traffic is reduced by the possibility of including tuples for multiple media senders in the same TMMBR message.
メディア送付者はもしあれば合図するセッションのときに交渉された最大のメディアビット伝送速度と最大のパケットレートによって制限されたセッションを始めます。 この値が別のプロトコル層のために関係者がTMMBRメッセージで使用するものより交渉されるかもしれないことに注意してください。 それぞれのメディア受信機は、参照プロトコル層を選択して、それがその参照レベルで観察している(まだパケットでないならそれを見積もっているのを見てあります)オーバーヘッドの見積りを形成して、それが受け入れることができる最大の総メディアビット伝送速度を測定します、それが意識しているかもしれないそれ自身の制限とどんな輸送経路制限も考慮に入れて。 現在の制限がセッションシグナリングで同意したことより多くの制限であるといけないので、メディア受信機はTMMBRメッセージを使用することでこれらの2つの量の初期の見積りをメディア送付者に報告します。 tuplesを含んでいる可能性によって総合的なメッセージ交通は同じTMMBRメッセージのマルチメディア送付者のために抑えられます。
The media sender applies an algorithm such as that specified in section 3.5.4.2 to select which of the tuples it has received are most limiting (i.e., the bounding set as defined in section 2.2). It modifies its operation to stay within the feasible region (as defined
送付者がアルゴリズムを適用するそれがtuplesのどれを受けたかを選択するためにセクション3.5.4で.2を指定したメディアは(すなわち、セクション2.2で定義される制限セット)を最も制限しています。 それが可能な領域の範囲内にとどまるように操作を変更する、(定義されます。
Wenger, et al. Standards Track [Page 21] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[21ページ]。
in section 2.2), and also sends out a TMMBN to the media receivers indicating the selected bounding set. That notification also indicates who was responsible for the tuples in the bounding set, i.e., the "owner"(s) of the limitation. A session participant that owns no tuple in the bounding set is called a "non-owner".
中、セクション2.2)、また、選択された制限がセットしたのを示すメディア受信機にTMMBNを出します。 また、その通知は、だれがすなわち、制限セット、制限の「所有者」でtuplesに責任があったかを示します。 制限セットでtupleを全く所有していないセッション関係者は「非所有者」と呼ばれます。
If a media receiver does not own one of the tuples in the bounding set reported by the TMMBN, it applies the same algorithm as the media sender to determine if its current estimated (maximum total media bit rate, overhead) tuple would enter the bounding set if known to the media sender. If so, it issues a TMMBR reporting the tuple value to the sender. Otherwise, it takes no action for the moment. Periodically, its estimated tuple values may change or it may receive a new TMMBN. If so, it reapplies the algorithm to decide whether it needs to issue a TMMBR.
メディア受信機がTMMBNによって報告された制限セットでtuplesの1つを所有していないなら、それは、メディア送付者にとって知られているなら現在のおよそ(頭上の最大の総メディアビット伝送速度)のtupleが制限セットに入るかどうか決定するためにメディア送付者と同じアルゴリズムを適用します。 そうだとすれば、それはtuple値を送付者に報告するTMMBRを発行します。 さもなければ、それはさしあたり、行動を全く取りません。 定期的に、およそtuple値が変化するかもしれませんか、またはそれは新しいTMMBNを受けるかもしれません。 そうだとすれば、それは、それが、TMMBRを発行する必要であるかどうか決めるためにアルゴリズムを再び使います。
If, alternatively, a media receiver owns one of the tuples in the reported bounding set, it takes no action until such time as its estimate of its own tuple values changes. At that time, it sends a TMMBR to the media sender to report the changed values.
あるいはまた、メディア受信機が報告された制限セットでtuplesの1つを所有しているなら、それ自身のtupleに関する見積りのような時間が変化を評価するまで、それは行動を全く取りません。 その時、それは、変えられた値を報告するためにメディア送付者にTMMBRを送ります。
A media receiver may change status between owner and non-owner of a bounding tuple between one TMMBN message and the next. Thus, it must check the contents of each TMMBN to determine its subsequent actions.
メディア受信機は1つのTMMBNメッセージと次の間の制限tupleの所有者と非所有者の間の状態を変えるかもしれません。 したがって、それは、その後の動作を決定するためにそれぞれのTMMBNのコンテンツをチェックしなければなりません。
Implementations may use other algorithms of their choosing, as long as the bit rate limitations resulting from the exchange of TMMBR and TMMBN messages are at least as strict (at least as low, in the bit rate dimension) as the ones resulting from the use of the aforementioned algorithm.
実現は彼らが選ぶ他のアルゴリズムを使用するかもしれません、TMMBRとTMMBNメッセージの交換から生じるビット伝送速度制限が前述のアルゴリズムの使用から生じるものと少なくとも同じくらい厳しい(ビット伝送速度寸法で少なくとも同じくらい低い)限り。
Obviously, in point-to-point cases, when there is only one media receiver, this receiver becomes "owner" once it receives the first TMMBN in response to its own TMMBR, and stays "owner" for the rest of the session. Therefore, when it is known that there will always be only a single media receiver, the above algorithm is not required. Media receivers that are aware they are the only ones in a session can send TMMBR messages with bit rate limits both higher and lower than the previously notified limit, at any time (subject to the AVPF [RFC4585] RTCP RR send timing rules). However, it may be difficult for a session participant to determine if it is the only receiver in the session. Because of this, any implementation of TMMBR is required to include the algorithm described in the next section or a stricter equivalent.
明らかに指すポイントのケース、1台のメディア受信機しかないとき、この受信機は、いったんそれ自身のTMMBRに対応して最初のTMMBNを受けると「所有者」になって、セッションの残りのために「所有者」に滞在しています。 したがって、単一のメディア受信機しかいつもないのを知られているとき、上のアルゴリズムは必要ではありません。 ビット伝送速度限界が、より高くて、かつ以前に通知された限界より低い状態でそれらがセッションで唯一のものであることを意識しているメディア受信機はメッセージをTMMBRに送ることができます、いつでも(規則を調節するRTCP RRが送るAVPF[RFC4585]を条件とした)。 しかしながら、セッション関係者が、セッションのときにそれが唯一の受信機であるかどうかと決心しているのは、難しいかもしれません。 これのために、TMMBRの実現が、次のセクションで説明されたアルゴリズムか、より厳しい同等物を含むのに必要です。
Wenger, et al. Standards Track [Page 22] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[22ページ]。
3.5.4.2. Algorithm for Establishing Current Limitations
3.5.4.2. 現在の制限を確立するためのアルゴリズム
This section introduces an example algorithm for the calculation of a session limit. Other algorithms can be employed, as long as the result of the calculation is at least as restrictive as the result that is obtained by this algorithm.
このセクションはセッション限界の計算のための例のアルゴリズムを導入します。 他のアルゴリズムを使うことができます、計算の結果がこのアルゴリズムで得られる結果と少なくとも同じくらい制限している限り。
First, it is important to consider the implications of using a tuple for limiting the media sender's behavior. The bit rate and the overhead value result in a two-dimensional solution space for the calculation of the bit rate of media streams. Fortunately, the two variables are linked. Specifically, the bit rate available for RTP payloads is equal to the TMMBR reported bit rate minus the packet rate used, multiplied by the TMMBR reported overhead converted to bits. As a result, when different bit rate/overhead combinations need to be considered, the packet rate determines the correct limitation. This is perhaps best explained by an example:
まず最初に、メディア送付者の振舞いを制限するのにtupleを使用する含意を考えるのは重要です。 メディアのビット伝送速度の計算のための二次元解決策スペースのビット伝送速度と頭上の値の結果は流れます。幸い、2つの変数が繋がっています。 明確に、RTPペイロードに有効なビット伝送速度は頭上であると報告されたTMMBRによって中古の、そして、掛けられたパケットレートを引いた報告されたビット伝送速度がビットに変換したTMMBRと等しいです。 その結果、異なったビット伝送速度/頭上の組み合わせが、考えられる必要があると、パケットレートは正しい制限を決定します。 恐らく例でこれについて説明するのは最も良いです:
Example:
例:
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
受信機A: TMMBR_最大合計BRは35キロビット毎秒と等しく、TMMBR_OHは40バイトのReceiver Bと等しいです: TMMBR_最大合計BRは40キロビット毎秒、TMMBR_と60OH=バイト等しいです。
For a given packet rate (PR), the bit rate available for media payloads in RTP will be:
与えられたパケットレート(PR)のために、RTPのメディアペイロードに有効なビット伝送速度は以下の通りになるでしょう。
Max_net media_BR_A =
TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
マックス_ネットメディア_BRはTMMBR_最大合計BRと等しいです--PR*TMMBR_OH*8… (1)
Max_net media_BR_B =
TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
マックス_ネットメディア_BR_BはTMMBR_最大合計BR_Bと等しいです--PR*TMMBR_OH_B*8… (2)
For a PR = 20, these calculations will yield a Max_net media_BR_A = 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that receiver A is the limiting one for this packet rate. However, at a certain PR there is a switchover point at which receiver B becomes the limiting one. The switchover point can be identified by setting Max_media_BR_A equal to Max_media_BR_B and breaking out PR:
PR=20のために、これらの計算はマックス_のネットのメディア_BR=28600ビーピーエスをもたらすでしょう、そして、マックス_ネットメディア_BR_Bは30400ビーピーエスと等しいです。(それは、受信機Aがこのパケットレートのための制限ものであると示唆します)。 しかしながら、あるPRには、受信機Bが制限ものになる転換ポイントがあります。 BRがマックス_メディア_BR_Bと等しいマックス_メディア_を設定して、PRを広げることによって、転換ポイントを特定できます:
TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3)
8*(TMMBR_OH_A - TMMBR_OH_B)
TMMBR_最大合計BR--TMMBR_最大合計BR_B PR=------------------------------------------- ... (3) 8*(TMMBR_OH--TMMBR_OH_B)
which, for the numbers above, yields 31.25 as the switchover point between the two limits. That is, for packet rates below 31.25 per second, receiver A is the limiting receiver, and for higher packet rates, receiver B is more limiting. The implications of this behavior have to be considered by implementations that are going to
上の数のために、2つの限界の間の転換ポイントとして31.25をもたらします。 すなわち、1秒あたり31.25未満のパケットレートのために、受信機Aは制限受信機です、そして、より高いパケットレートのために、受信機Bはさらに制限されています。 この振舞いの含意は行く実現で考えられなければなりません。
Wenger, et al. Standards Track [Page 23] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[23ページ]。
control media encoding and its packetization. As exemplified above, multiple TMMBR limits may apply to the trade-off between net media bit rate and packet rate. Which limitation applies depends on the packet rate being considered.
メディアコード化とそのpacketizationを制御してください。 上で例示されるように、複数のTMMBR限界がネットのメディアビット伝送速度とパケットレートの間のトレードオフに適用されるかもしれません。 考えられて、どの制限が適用されるかはパケットレートに依存します。
This also has implications for how the TMMBR mechanism needs to work. First, there is the possibility that multiple TMMBR tuples are providing limitations on the media sender. Secondly, there is a need for any session participant (media sender and receivers) to be able to determine if a given tuple will become a limitation upon the media sender, or if the set of already given limitations is stricter than the given values. In the absence of the ability to make this determination, the suppression of TMMBRs would not work.
また、これには、TMMBRメカニズムが、どう働く必要があるか意味があります。 まず最初に、複数のTMMBR tuplesがメディア送付者の上で制限を提供している可能性があります。 第二に、何かセッション関係者(メディア送付者と受信機)が与えられたtupleがメディア送付者で制限になるかどうか、または既に与えられた制限のセットが与えられた値より厳しいかどうか決定できる必要があります。 この決断をする能力がないとき、TMMBRsの抑圧は働いていないでしょう。
The basic idea of the algorithm is as follows. Each TMMBR tuple can be viewed as the equation of a straight line (cf. equations (1) and (2)) in a space where packet rate lies along the X-axis and net bit rate along the Y-axis. The lower envelope of the set of lines corresponding to the complete set of TMMBR tuples, together with the X and Y axes, defines a polygon. Points lying within this polygon are combinations of packet rate and bit rate that meet all of the TMMBR constraints. The highest feasible packet rate within this region is the minimum of the rate at which the bounding polygon meets the X-axis or the session maximum packet rate (SMAXPR, measured in packets per second) provided by signaling, if any. Typically, a media sender will prefer to operate at a lower rate than this theoretical maximum, so as to increase the rate at which actual media content reaches the receivers. The purpose of the algorithm is to distinguish the TMMBR tuples constituting the bounding set and thus delineate the feasible region, so that the media sender can select its preferred operating point within that region
アルゴリズムの基本的な考え方は以下の通りです。 直線の方程式として各TMMBR tupleを見なすことができる、(Cf Y-軸に沿ったX-軸とネットのビット伝送速度に沿ってパケットレートがあるスペースの方程式(1)と(2))。 TMMBR tuplesの完全なセットに対応する線のセットの下側の封筒はXとY軸と共に多角形を定義します。 この多角形に属すポイントはTMMBR規制のすべてに会うパケットレートとビット伝送速度の組み合わせです。 この領域の中の最も高い可能なパケットレートはもしあれば合図することによって提供された制限多角形がX-軸に触れるレートかセッションの最大のパケット率(1秒あたりのパケットで測定されたSMAXPR)の最小限です。 通常、メディア送付者は、この理論上の最大より低レートで作動するのを好むでしょう、実際のメディア内容が受信機に達するレートを増加させるように。 アルゴリズムの目的は、制限セットを構成するTMMBR tuplesを区別して、その結果、可能な領域を図で表わすことです、メディア送付者がその領域の中で都合のよい操作ポイントを選択できるように
Figure 1 below shows a bounding polygon formed by TMMBR tuples A and B. A third tuple C lies outside the bounding polygon and is therefore irrelevant in determining feasible trade-offs between media rate and packet rate. The line labeled ss..s represents the limit on packet rate imposed by the session maximum packet rate (SMAXPR) obtained by signaling during session setup. In Figure 1, the limit determined by tuple B happens to be more restrictive than SMAXPR. The situation could easily be the reverse, meaning that the bounding polygon is terminated on the right by the vertical line representing the SMAXPR constraint.
以下の図1は、制限多角形の外でTMMBR tuples AとB.A3番目のtuple Cによって形成された制限多角形があるのを示して、したがって、メディアレートとパケットレートの間の可能なトレードオフを決定するのにおいて無関係です。 線はssをラベルしました。sはセッションセットアップの間、合図することによって得られたセッションの最大のパケット率(SMAXPR)によって課されたパケットレートにおける限界を表します。 図1では、tuple Bで決定している限界はSMAXPRよりたまたま制限しています。 状況は容易に逆であるかもしれません、制限多角形がSMAXPR規制を表しながら右で縦線によって終えられることを意味して。
Wenger, et al. Standards Track [Page 24] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[24ページ]。
Net ^
Media|a c b s
Bit | a c b s
Rate | a c b s
| a cb s
| a c s
| a bc s
| a b c s
| ab c s
| Feasible b c s
| region ba s
| b a s c
| b s c
| b s a
| bs
+------------------------------>
ネット^メディア|c b s Bit| c b s Rate| c b s| cb s| c s| bc s| b c s| 腹筋c s| 可能なb c s| 領域Ba s| bはs cです。| b s c| b s a| bs+------------------------------>。
Packet rate
パケットレート
Figure 1 - Geometric Interpretation of TMMBR Tuples
図1--TMMBR Tuplesの幾何学的解釈
Note that the slopes of the lines making up the bounding polygon are increasingly negative as one moves in the direction of increasing packet rate. Note also that with slight rearrangement, equations (1) and (2) have the canonical form:
パケットレートを増加させることの向きに人が動くとき制限多角形を作る線のスロープがますます否定的であることに注意してください。 また、わずかな配列換えによって、方程式(1)と(2)には標準形があることに注意してください:
y = mx + b
yはmx+bと等しいです。
where
m is the slope and has value equal to the negative of the tuple
overhead (in bits),
and
b is the y-intercept and has value equal to the tuple maximum
total media bit rate.
mがスロープであり、値を持っているところでは、tupleオーバーヘッド(ビットの)、およびbの否定的への同輩は、y-インタセプトであり、tupleの最大の総メディアビット伝送速度と等しい値を持っています。
These observations lead to the conclusion that when processing the TMMBR tuples to select the initial bounding set, one should sort and process the tuples by order of increasing overhead. Once a particular tuple has been added to the bounding set, all tuples not already selected and having lower overhead can be eliminated, because the next side of the bounding polygon has to be steeper (i.e., the corresponding TMMBR must have higher overhead) than the latest added tuple.
これらの観測は初期の制限セットを選択するためにTMMBR tuplesを処理するとき、増加するオーバーヘッドの注文でtuplesを分類して、処理するべきであるという結論につながります。 特定のtupleがいったん制限セットに追加されると、既に選択されて、低いオーバーヘッドを持っていないすべてのtuplesは排除できます、制限多角形次の側が最新の加えられたtupleより急でなければならないので(すなわち、対応するTMMBRには、より高いオーバーヘッドがなければなりません)。
Line cc..c in Figure 1 illustrates another principle. This line is parallel to line aa..a, but has a higher Y-intercept. That is, the corresponding TMMBR tuple contains a higher maximum total media bit rate value. Since line cc..c is outside the bounding polygon, it
ccを裏打ちしてください。図1のcは別の原則を例証します。 この直線は線aaに平行です。より高いY-インタセプトを持っています。 すなわち、対応するTMMBR tupleは、より高い最大の総メディアビット伝送速度価値を含んでいます。 以来、ccを裏打ちしてください。制限多角形の外でcがある、それ
Wenger, et al. Standards Track [Page 25] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[25ページ]。
illustrates the conclusion that if two TMMBR tuples have the same overhead value, the one with higher maximum total media bit rate value cannot be part of the bounding set and can be set aside.
2TMMBR tuplesに同じ頭上の値があるなら、より高い最大の総メディアビット伝送速度価値に従った1つが制限セットの一部であるはずがないという結論を例証して、かたわらに置くことができます。
Two further observations complete the algorithm. Obviously, moving from the left, the successive corners of the bounding polygon (i.e., the intersection points between successive pairs of sides) lie at successively higher packet rates. On the other hand, again moving from the left, each successive line making up the bounding set crosses the X-axis at a lower packet rate.
さらなる2つの観測がアルゴリズムを完成します。 明らかに、左から動いて、制限多角形(すなわち、連続した組の側の間の交差点ポイント)の連続した角は相次ぎより高いパケットレートで位置しています。 他方では、再び左から動いて、制限セットを構成しているそれぞれの連続した線が低いパケットレートにX-軸に交差しています。
The complete algorithm can now be specified. The algorithm works with two lists of TMMBR tuples, the candidate list X and the selected list Y, both ordered by increasing overhead value. The algorithm terminates when all members of X have been discarded or removed for processing. Membership of the selected list Y is probationary until the algorithm is complete. Each member of the selected list is associated with an intersection value, which is the packet rate at which the line corresponding to that TMMBR tuple intersects with the line corresponding to the previous TMMBR tuple in the selected list. Each member of the selected list is also associated with a maximum packet rate value, which is the lesser of the session maximum packet rate SMAXPR (if any) and the packet rate at which the line corresponding to that tuple crosses the X-axis.
現在、完全なアルゴリズムを指定できます。 アルゴリズムはTMMBR tuplesの2つのリスト、候補リストX、および選抜表Yで利きます、と両方が頭上の値を増加させることによって、命令しました。 処理のためにXのすべてのメンバーを捨てるか、または免職したとき、アルゴリズムは終わります。 アルゴリズムが完全になるまで、選抜表Yの会員資格は試験です。 選抜表のそれぞれのメンバーは交差点値に関連しています。(それは、そのTMMBR tupleに対応する線が選抜表の前のTMMBR tupleに対応する線と交差するパケットレートです)。 また、選抜表のそれぞれのメンバーも最大のパケットレート価値に関連しています。((もしあれば)のセッションの最大のパケット率のSMAXPRとそのtupleに対応する線がX-軸に交差するパケットレートではそれは、より少ないです)。
When the algorithm terminates, the selected list is equal to the bounding set as defined in section 2.2.
アルゴリズムが終わるとき、選抜表はセクション2.2で定義されるように設定された制限と等しいです。
Initial Algorithm
初期のアルゴリズム
This algorithm is used by the media sender when it has received one or more TMMBRs and before it has determined a bounding set for the first time.
1TMMBRsを受けて、初めてそれの前に制限セットを決定したとき、このアルゴリズムはメディア送付者によって使用されます。
1. Sort the TMMBR tuples by order of increasing overhead. This is
the initial candidate list X.
1. 増加するオーバーヘッドの注文でTMMBR tuplesを分類してください。 これは初期の候補リストXです。
2. When multiple tuples in the candidate list have the same overhead
value, discard all but the one with the lowest maximum total media
bit rate value.
2. 候補リストの複数のtuplesに同じ頭上の値があるときには、最も低い最大の総メディアビット伝送速度価値に従ったもの以外のすべてを捨ててください。
3. Select and remove from the candidate list the TMMBR tuple with the
lowest maximum total media bit rate value. If there is more than
one tuple with that value, choose the one with the highest
overhead value. This is the first member of the selected list Y.
Set its intersection value equal to zero. Calculate its maximum
3. 候補リストから最も低い最大の総メディアビット伝送速度価値があるTMMBR tupleを選択して、取り外してください。 その値がある1tupleがあれば、最も高い頭上の値に従ったものを選んでください。 これは第1代交差点値がゼロと等しい選抜表Y.Setのメンバーです。 最大について計算してください。
Wenger, et al. Standards Track [Page 26] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[26ページ]。
packet rate as the minimum of SMAXPR (if available) and the value
obtained from the following formula, which is the packet rate at
which the corresponding line crosses the X-axis.
対応する線がX-軸に交差するSMAXPR(利用可能であるなら)の最小限としてのパケットレートとパケットである以下の公式から得られた値は評価します。
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
マックスPR=TMMBRは総BR/(8*TMMBR OH)に最大限にします… (4)
4. Discard from the candidate list all tuples with a lower overhead
value than the selected tuple.
4. 候補リストから、選択されたtupleより頭上の低値ですべてのtuplesを捨ててください。
5. Remove the first remaining tuple from the candidate list for
processing. Call this the current candidate.
5. 処理のための候補リストからtupleのままで残っていて、1番目を取り除いてください。 現在の候補にこれに電話をしてください。
6. Calculate the packet rate PR at the intersection of the line
generated by the current candidate with the line generated by the
last tuple in the selected list Y, using equation (3).
6. 線が選抜表Yにおける最後のtupleによって発生している状態で現在の候補によって発生した線の交差点でパケットレートPRについて計算してください、方程式(3)を使用して。
7. If the calculated value PR is equal to or lower than the
intersection value stored for the last tuple of the selected list,
discard the last tuple of the selected list and go back to step 6
(retaining the same current candidate).
7. 計算された値のPRが選抜表の最後のtupleのために格納された交差点値より等しいか、または低いなら、選抜表の最後のtupleを捨ててください、そして、ステップ6に戻ってください(同じ現在の候補を保有して)。
Note that the choice of the initial member of the selected list Y
in step 3 guarantees that the selected list will never be emptied
by this process, meaning that the algorithm must eventually (if
not immediately) fall through to step 8.
ステップ3における選抜表Yの初期のメンバーの選択が、選抜表がこの工程で決して空にされないのを保証することに注意してください、アルゴリズムが結局ステップ8に失敗に終わらなければならないことを(すぐに)意味して。
8. (This step is reached when the calculated PR value of the current
candidate is greater than the intersection value of the current
last member of the selected list Y.) If the calculated value PR
of the current candidate is lower than the maximum packet rate
associated with the last tuple in the selected list, add the
current candidate tuple to the end of the selected list. Store PR
as its intersection value. Calculate its maximum packet rate as
the lesser of SMAXPR (if available) and the maximum packet rate
calculated using equation (4).
8. (現在の候補の計算されたPR値が選抜表Y.の最後の現在のメンバーの交差点値より大きいときに、このステップに達しています) 現在の候補の計算された値のPRが最大のパケットレートが選抜表における最後のtupleと交際したより低いなら、現在の候補tupleを選抜表の終わりに加えてください。 交差点値としてPRを格納してください。 SMAXPRで、より少ない、そして、(利用可能)としての最大のパケットレートと方程式(4)を使用することで計算された最大のパケットレートについて計算してください。
9. If any tuples remain in the candidate list, go back to step 5.
9. 何かtuplesが候補リストに残っているなら、ステップ5に戻ってください。
Incremental Algorithm
増加のアルゴリズム
The previous algorithm covered the initial case, where no selected list had previously been created. It also applied only to the media sender. When a previously created selected list is available at either the media sender or media receiver, two other cases can be considered:
前のアルゴリズムは初期のケースをカバーしました。そこでは、選抜表が全く以前に、作成されていませんでした。 また、それはメディア送付者だけに適用されました。 以前に作成された選抜表がメディア送付者かメディア受信機で利用可能であるときに、他の2つのケースを考えることができます:
o when a TMMBR tuple not currently in the selected list is a
candidate for addition;
o TMMBR tupleであるときに、現在、選抜表には、候補は添加のためにいません。
Wenger, et al. Standards Track [Page 27] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[27ページ]。
o when the values change in a TMMBR tuple currently in the
selected list.
o 値が現在、選抜表のTMMBR tupleで変化すると。
At the media receiver, these cases correspond, respectively, to those of the non-owner and owner of a tuple in the TMMBN-reported bounding set.
メディア受信機では、これらのケースはそれぞれTMMBNによって報告された制限セットにおけるtupleの非所有者と所有者のものに対応しています。
In either case, the process of updating the selected list to take account of the new/changed tuple can use the basic algorithm described above, with the modification that the initial candidate set consists only of the existing selected list and the new or changed tuple. Some further optimization is possible (beyond starting with a reduced candidate set) by taking advantage of the following observations.
どちらの場合ではも、新しいか変えられたtupleを考慮に入れるために選抜表をアップデートする過程は上で説明された基本的なアルゴリズムを使用できて、変更で、初期の候補がセットしたのは既存の選抜表と新しいか変えられたtupleだけから成ります。 さらなる何らかの最適化が以下の観測を利用することによって、可能です(減少している候補セットから始まることを超えた)。
The first observation is that if the new/changed candidate becomes part of the new selected list, the result may be to cause zero or more other tuples to be dropped from the list. However, if more than one other tuple is dropped, the dropped tuples will be consecutive. This can be confirmed geometrically by visualizing a new line that cuts off a series of segments from the previously existing bounding polygon. The cut-off segments are connected one to the next, the geometric equivalent of consecutive tuples in a list ordered by overhead value. Beyond the dropped set in either direction all of the tuples that were in the earlier selected list will be in the updated one. The second observation is that, leaving aside the new candidate, the order of tuples remaining in the updated selected list is unchanged because their overhead values have not changed.
最初の観測は新しいか変えられた候補が新しい選抜表の一部になるなら、リストから落とされるために原因ゼロか他の、より多くのtuplesには結果があるかもしれないということです。 しかしながら、他の1tupleが落とされると、低下しているtuplesは連続するようになるでしょう。 以前に既存の制限多角形から一連のセグメントを断ち切る復帰改行を想像することによって、幾何学上これを確認できます。 締切りのセグメントは次への接続ものです、とリストの連続したtuplesの幾何学上同等物が頭上の値で命令しました。 どちらかの指示に基づく低下しているセットを超えて、アップデートされたものには以前の選抜表にあったtuplesのすべてがあるでしょう。 2番目の観測はそれらの頭上の値が今まで変わっていないのでアップデートされた選抜表に残っているtuplesの注文が新しい候補は別にして変わりがないということです。
The consequence of these two observations is that, once the placement of the new candidate and the extent of the dropped set of tuples (if any) has been determined, the remaining tuples can be copied directly from the candidate list into the selected list, preserving their order. This conclusion suggests the following modified algorithm:
これらの2つの観測の結果は新しい候補のプレースメントとtuples(もしあれば)の低下しているセットの範囲がいったん決定するようになると直接候補リストから選抜表の中に残っているtuplesをコピーできるということです、彼らのオーダーを保存して。 この結論は以下の変更されたアルゴリズムを示します:
o Run steps 1-4 of the basic algorithm.
o 基本的なアルゴリズムの階段1-4を動かしてください。
o If the new candidate has survived steps 2 and 4 and has become
the new first member of the selected list, run steps 5-9 on
subsequent candidates until another candidate is added to the
selected list. Then move all remaining candidates to the
selected list, preserving their order.
o 新しい候補がステップ2と4を乗り切って、第1代選抜表の新しいメンバーになったなら、別の候補が選抜表に追加されるまで、その後の候補の上の階段5-9を動かしてください。 その時、彼らのオーダーを保存して、選抜表へのすべての残っている候補が移ります。
o If the new candidate has survived steps 2 and 4 and has not
become the new first member of the selected list, start by
moving all tuples in the candidate list with lower overhead
values than that of the new candidate to the selected list,
preserving their order. Run steps 5-9 for the new candidate,
o 新しい候補がステップ2と4を乗り切って、第1代選抜表の新しいメンバーになっていないなら、候補リストで新しい候補のものより頭上の低値ですべてのtuplesを選抜表に動かすことによって、始まってください、彼らのオーダーを保存して。 新しい候補のための階段5-9を動かしてください。
Wenger, et al. Standards Track [Page 28] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[28ページ]。
with the modification that the intersection values and maximum
packet rates for the tuples on the selected list have to be
calculated on the fly because they were not previously stored.
Continue processing only until a subsequent tuple has been
added to the selected list, then move all remaining candidates
to the selected list, preserving their order.
選抜表の上のtuplesの交差点値と最大のパケットレートがそうしなければならない変更で、それらが以前に格納されなかったので、急いで計算されてください。 その後のtupleが選抜表に追加されるまでしか処理し続けないでください、そして、次に、すべての残っている候補を選抜表に動かしてください、彼らのオーダーを保存して。
Note that the new candidate could be added to the selected
list only to be dropped again when the next tuple is
processed. It can easily be seen that in this case the new
candidate does not displace any of the earlier tuples in the
selected list. The limitations of ASCII art make this
difficult to show in a figure. Line cc..c in Figure 1 would
be an example if it had a steeper slope (tuple C had a higher
overhead value), but still intersected line aa..a beyond where
line aa..a intersects line bb..b.
新しい候補を選抜表に追加できたことに注意してください次のtupleが処理されるとき再び低下する。 容易に、この場合新しい候補が選抜表で以前のtuplesのいずれも置き換えないのを見ることができます。 ASCII芸術の制限は、図にこれを示すのを難しくします。 ccを裏打ちしてください。それには、より急なスロープがありましたが(tuple Cには、より高い頭上の値がありました)、線aaがまだ交差しているなら、図1のcは例でしょうに。ところを超えて線aaであるa。aは交差しています。線bb。b。
The algorithm just described is approximate, because it does not take account of tuples outside the selected list. To see how such tuples can become relevant, consider Figure 1 and suppose that the maximum total media bit rate in tuple A increases to the point that line aa..a moves outside line cc..c. Tuple A will remain in the bounding set calculated by the media sender. However, once it issues a new TMMBN, media receiver C will apply the algorithm and discover that its tuple C should now enter the bounding set. It will issue a TMMBR to the media sender, which will repeat its calculation and come to the appropriate conclusion.
選抜表の外でtuplesを考慮に入れないので、ただ説明されたアルゴリズムは大体です。 そのようなtuplesがどう関連するようになることができるかを見るために、図1を考えてください、そして、tuple Aの最大の総メディアビット伝送速度がその線aaをポイントに増加させると仮定してください。移動外線cc。c。 Tuple Aはメディア送付者によって計算された制限セットに残るでしょう。 しかしながら、それがいったん新しいTMMBNを発行すると、メディア受信機Cは、アルゴリズムを申し込んで、tuple Cが今制限セットに入るはずであると発見するでしょう。 それは計算を繰り返して、適切な結論に達するメディア送付者にTMMBRを発行するでしょう。
The rules of section 4.2 require that the media sender refrain from raising its sending rate until media receivers have had a chance to respond to the TMMBN. In the example just given, this delay ensures that the relaxation of tuple A does not actually result in an attempt to send media at a rate exceeding the capacity at C.
セクション4.2の規則は、メディア送付者が、メディア受信機にはTMMBNに応じる機会があるまで送付レートを上げるのを控えるのを必要とします。 ただ出された例では、この遅れは、tuple Aの緩和が実際にレートにおけるメディアにCで容量を超えさせる試みをもたらさないのを確実にします。
3.5.4.3. Use of TMMBR in a Mixer-Based Multipoint Operation
3.5.4.3. ミキサーベースの多点操作におけるTMMBRの使用
Assume a small mixer-based multiparty conference is ongoing, as depicted in Topo-Mixer of [RFC5117]. All participants have negotiated a common maximum bit rate that this session can use. The conference operates over a number of unicast paths between the participants and the mixer. The congestion situation on each of these paths can be monitored by the participant in question and by the mixer, utilizing, for example, RTCP receiver reports (RRs) or the transport protocol, e.g., Datagram Congestion Control Protocol (DCCP) [RFC4340]. However, any given participant has no knowledge of the congestion situation of the connections to the other participants. Worse, without mechanisms similar to the ones discussed in this document, the mixer (which is aware of the congestion situation on
[RFC5117]のTopo-ミキサーに表現されるように小さいミキサーを拠点とする「マルチ-パーティー」会議が進行中であると仮定してください。 すべての関係者がこのセッションが使用できる一般的な最大のビット伝送速度を交渉しました。 会議は関係者とミキサーの間の多くのユニキャスト経路にわたって作動します。 問題の関係者とミキサーでそれぞれのこれらの経路の混雑状況をモニターできます、例えばRTCP受信機レポート(RRs)かトランスポート・プロトコル例えば、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]を利用して しかしながら、どんな与えられた関係者も接続の混雑状況に関する知識を全く他の関係者に持っていません。 より悪い、本書では議論したもの、ミキサーと同様のメカニズムなしで(どれが混雑状況を知っているか、オン
Wenger, et al. Standards Track [Page 29] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[29ページ]。
all connections it manages) has no standardized means to inform media senders to slow down, short of forging its own receiver reports (which is undesirable). In principle, a mixer confronted with such a situation is obliged to thin or transcode streams intended for connections that detected congestion.
それが管理するすべての接続) 急にそれ自身の受信機レポートを偽造するのを減速させるメディア送付者に知らせる標準化された手段(望ましくありません)を全く持っていません。 原則として、ミキサーは薄くする状況が強いられるそのようなものか「移-コード」に混雑を検出した接続のために意図する流れに立ち向かいました。
In practice, unfortunately, media-aware streaming thinning is a very difficult and cumbersome operation and adds undesirable delay. If media-unaware, it leads very quickly to unacceptable reproduced media quality. Hence, a means to slow down senders even in the absence of congestion on their connections to the mixer is desirable.
残念ながら、メディア意識しているストリーミングの間引きは、実際には、非常に難しくて厄介な操作であり、望ましくない遅れを加えます。 メディア気づかないなら、それは非常に急速に容認できない再生しているメディア品質に通じます。 したがって、彼らの接続の混雑がないときでさえ送付者をミキサーに減速させる手段は望ましいです。
To allow the mixer to throttle traffic on the individual links, without performing transcoding, there is a need for a mechanism that enables the mixer to ask a participant's media encoders to limit the media stream bit rate they are currently generating. TMMBR provides the required mechanism. When the mixer detects congestion between itself and a given participant, it executes the following procedure:
ミキサーがコード変換を実行しないで個々のリンクにおける交通を阻止するのを許容するために、ミキサーが、それらが現在発生させているメディア流れのビット伝送速度を制限するように関係者のメディアエンコーダに頼むのを可能にするメカニズムの必要があります。 TMMBRは必要なメカニズムを提供します。 ミキサーがそれ自体と与えられた関係者の間の混雑を検出するとき、以下の手順を実行します:
1. It starts thinning the media traffic to the congested participant
to the supported bit rate.
1. それは混雑している関係者へのメディア交通を支持されたビット伝送速度に薄くし始めます。
2. It uses TMMBR to request the media sender(s) to reduce the total
media bit rate sent by them to the mixer, to a value that is in
compliance with congestion control principles for the slowest
link. Slow refers here to the available bandwidth / bit rate /
capacity and packet rate after congestion control.
2. それはそれらによってミキサーに送られた総メディアビット伝送速度を減少させるようメディア送付者に要求するのにTMMBRを使用します、最も遅いリンクへの輻輳制御原則に従ってある値に。 遅くなってください。ここで、有効な帯域幅/ビット伝送速度/容量とパケットレートは輻輳制御の後に参照されます。
3. As soon as the bit rate has been reduced by the sending part, the
mixer stops stream thinning implicitly, because there is no need
for it once the stream is in compliance with congestion control.
3. ビット伝送速度が送付部分で減少するとすぐに、ミキサーはそれとなく流れの間引きを止めます、流れが輻輳制御に従っていったんあるとそれの必要は全くないので。
This use of stream thinning as an immediate reaction tool followed up by a quick control mechanism appears to be a reasonable compromise between media quality and the need to combat congestion.
即座の反応ツールが迅速な制御機構によって追求されたので、流れの間引きのこの使用はメディア品質と混雑と戦う必要性の間の合理的な妥協であるように見えます。
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using Multicast or
Translators
3.5.4.4. マルチキャストか翻訳者を使用する多点へのポイントのTMMBRの使用
In these topologies, corresponding to Topo-Multicast or Topo- Translator, RTCP RRs are transmitted globally. This allows all participants to detect transmission problems such as congestion, on a medium timescale. As all media senders are aware of the congestion situation of all media receivers, the rationale for the use of TMMBR in the previous section does not apply. However, even in this case the congestion control response can be improved when the unicast
これらのtopologiesでは、Topo-マルチキャストかTopo翻訳者に文通していて、RTCP RRsはグローバルに伝えられます。 これで、すべての関係者が中くらいのスケールにおける混雑などのトランスミッション問題を検出できます。 すべてのメディア送付者がすべてのメディア受信機の混雑状況を知っているように、前項でのTMMBRの使用のための原理は適用されません。 しかしながら、この場合さえユニキャストであるときに、混雑操舵応答を改良できます。
Wenger, et al. Standards Track [Page 30] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[30ページ]。
links are using congestion controlled transport protocols (such as TCP or DCCP). A peer may also report local limitations to the media sender.
リンクは混雑の制御トランスポート・プロトコル(TCPかDCCPなどの)を使用しています。 また、同輩は地方の制限をメディア送付者に報告するかもしれません。
3.5.4.5. Use of TMMBR in Point-to-Point Operation
3.5.4.5. 指すポイントでのTMMBR操作の使用
In use case 7, it is possible to use TMMBR to improve the performance when the known upper limit of the bit rate changes. In this use case, the signaling protocol has established an upper limit for the session and total media bit rates. However, at the time of transport link bit rate reduction, a receiver can avoid serious congestion by sending a TMMBR to the sending side. Thus, TMMBR is useful for putting restrictions on the application and thus placing the congestion control mechanism in the right ballpark. However, TMMBR is usually unable to provide the continuously quick feedback loop required for real congestion control. Nor do its semantics match those of congestion control given its different purpose. For these reasons, TMMBR SHALL NOT be used as a substitute for congestion control.
使用中であり、7をケースに入れてください、そして、ビット伝送速度の知られている上限が変化するときの性能を向上させるのにTMMBRを使用するのは可能です。 これでは、ケースを使用してください、そして、シグナリングプロトコルはセッションと総メディアビット伝送速度のために上限を確立しました。 しかしながら、輸送リンクビット伝送速度減少時点で、受信機は、送付側にTMMBRを送ることによって、重大な混雑を避けることができます。 したがって、TMMBRはアプリケーションのときに制限して、その結果、混雑制御機構を正しい球場に置くことの役に立ちます。 しかしながら、通常、TMMBRは実際の輻輳制御に必要である絶え間なく迅速なフィードバックループを提供できません。 異なる役割を考えて、混雑のものが制御する意味論マッチもそうしません。 TMMBR SHALL NOT、これらを推論します。輻輳制御の代用品として、使用されてください。
3.5.4.6. Reliability
3.5.4.6. 信頼性
The reaction of a media sender to the reception of a TMMBR message is not immediately identifiable through inspection of the media stream. Therefore, a more explicit mechanism is needed to avoid unnecessary re-sending of TMMBR messages. Using a statistically based retransmission scheme would only provide statistical guarantees of the request being received. It would also not avoid the retransmission of already received messages. In addition, it would not allow for easy suppression of other participants' requests. For these reasons, a mechanism based on explicit notification is used.
TMMBRメッセージのレセプションへのメディア送付者の反応はすぐに、メディアの流れの点検で身元保証可能ではありません。 したがって、より明白なメカニズムが、TMMBRメッセージの不要な再送を避けるのに必要です。 統計的に基づいた「再-トランスミッション」計画を使用すると、受け取られる要求の統計的な保証は提供されるだけでしょう。 また、それは既に受信されたメッセージの「再-トランスミッション」を避けないでしょう。 さらに、それは他の関係者の要求の簡単な秘匿を考慮しないでしょう。 これらの理由で、明白な通知に基づくメカニズムは使用されています。
Upon the reception of a TMMBR, a media sender sends a TMMBN containing the current bounding set, and indicating which session participants own that limit. In multicast scenarios, that allows all other participants to suppress any request they may have, if their limitations are less strict than the current ones (i.e., define lines lying outside the feasible region as defined in section 2.2). Keeping and notifying only the bounding set of tuples allows for small message sizes and media sender states. A media sender only keeps state for the SSRCs of the current owners of the bounding set of tuples; all other requests and their sources are not saved. Once the bounding set has been established, new TMMBR messages should be generated only by owners of the bounding tuples and by other entities that determine (by applying the algorithm of section 3.5.4.2 or its equivalent) that their limitations should now be part of the bounding set.
TMMBRのレセプションに、メディア送付者は、現在の制限を含むTMMBNが、設定されて、どのセッション関係者がその限界を所有しているかを示すのを送ります。 マルチキャストシナリオでは、他のすべての関係者がそれで彼らが持っているどんな要求も抑圧できます、彼らの制限が現在のものほど厳しくないなら(すなわち、可能な領域の外にセクション2.2で定義されるようにある線を定義してください)。 tuplesの制限セットだけを維持して、通知すると、小さいメッセージサイズとメディア送付者州は考慮されます。 メディア送付者はtuplesの制限セットの現在の所有者のSSRCsのために状態を維持するだけです。 他のすべての要求と彼らのソースは救われません。 制限セットがいったん設立されると、新しいTMMBRメッセージは単にバウンドしているtuplesの所有者と彼らの制限が現在制限セットの一部であるべきであると決心している(セクション3.5.4のアルゴリズムを適用するのによる.2かその同等物)他の実体で発生するべきです。
Wenger, et al. Standards Track [Page 31] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[31ページ]。
4. RTCP Receiver Report Extensions
4. RTCP受信機レポート拡張子
This memo specifies six new feedback messages. The Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal- Spatial Trade-off Notification (TSTN), and Video Back Channel Message (VBCM) are "Payload Specific Feedback Messages" as defined in section 6.3 of AVPF [RFC4585]. The Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are "Transport Layer Feedback Messages" as defined in section 6.2 of AVPF.
このメモは6つの新しいフィードバックメッセージを指定します。 Full Intra Request(FIR)、Temporal空間的な下にTrade Request(TSTR)、Temporalの空間的な下にTrade Notification(TSTN)、およびVideo Back Channel Message(VBCM)はAVPF[RFC4585]のセクション6.3で定義されるように「有効搭載量の特定のフィードバックメッセージ」です。 Temporary MaximumメディアのStream Bit Rate Request(TMMBR)とTemporary MaximumメディアStream Bit Rate Notification(TMMBN)はAVPFのセクション6.2で定義されるように「トランスポート層フィードバックメッセージ」です。
The new feedback messages are defined in the following subsections, following a similar structure to that in sections 6.2 and 6.3 of the AVPF specification [RFC4585].
新しいフィードバックメッセージは以下の小区分で定義されます、AVPF仕様[RFC4585]のセクション6.2と6.3でそれに類似構造物に従って。
4.1. Design Principles of the Extension Mechanism
4.1. 拡大メカニズムの設計原理
RTCP was originally introduced as a channel to convey presence, reception quality statistics and hints on the desired media coding. A limited set of media control mechanisms was introduced in early RTP payload formats for video formats, for example, in RFC 2032 [RFC2032] (which was obsoleted by RFC 4587 [RFC4587]). However, this specification, for the first time, suggests a two-way handshake for some of its messages. There is danger that this introduction could be misunderstood as a precedent for the use of RTCP as an RTP session control protocol. To prevent such a misunderstanding, this subsection attempts to clarify the scope of the extensions specified in this memo, and it strongly suggests that future extensions follow the rationale spelled out here, or compellingly explain why they divert from the rationale.
元々、必要なメディアコード化のときに存在、レセプション品質統計、およびヒントを伝えるためにチャンネルとしてRTCPを導入しました。 例えば、限られたセットのメディア制御機構はRFC2032[RFC2032](RFC4587[RFC4587]によって時代遅れにされた)でビデオ形式のための早めのRTPペイロード形式で紹介されました。 しかしながら、この仕様は初めて、メッセージのいくつかのために両用握手を示します。 RTPセッション制御プロトコルとしてRTCPの使用のための先例としてこの序論を誤解できたという危険があります。 それは、そのような誤解を防ぐために、この小区分が、このメモで指定された拡大の範囲をはっきりさせるのを試みて、今後の拡大でここにつづられた原理に従うか、またはなぜ原理からそれるかが強制的にわかるのを強く示します。
In this memo, and in AVPF [RFC4585], only such messages have been included as:
このメモ、およびAVPF[RFC4585]では、そのようなメッセージだけが以下として含まれています。
a) have comparatively strict real-time constraints, which prevent the
use of mechanisms such as a SIP re-invite in most application
scenarios (the real-time constraints are explained separately for
each message where necessary);
a) 比較的厳しいリアルタイムの規制にほとんどのアプリケーションシナリオ(リアルタイムの規制は各メッセージのために別々に必要であるところで説明される)で再招待させます。(規制はSIPなどのメカニズムの使用を防ぎます)。
b) are multicast-safe in that the reaction to potentially
contradicting feedback messages is specified, as necessary for
each message; and
b) 潜在的にフィードバックメッセージに矛盾することへの反応が各メッセージに必要に応じて指定されるので、マルチキャスト安全です。 そして
c) are directly related to activities of a certain media codec, class
of media codecs (e.g., video codecs), or a given RTP packet
stream.
c) 直接あるメディアコーデックの活動、メディアコーデック(例えば、ビデオコーデック)のクラス、または与えられたRTPパケットの流れに関連されます。
Wenger, et al. Standards Track [Page 32] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[32ページ]。
In this memo, a two-way handshake is introduced only for messages for which:
このメモでは、メッセージのためだけに両用握手を導入する、どれ、:
a) a notification or acknowledgement is required due to their nature.
An analysis to determine whether this requirement exists has been
performed separately for each message.
a) 通知か承認が彼らの自然のため必要です。 この要件が存在しているか否かに関係なく、決定する分析は各メッセージのために別々に実行されました。
b) the notification or acknowledgement cannot be easily derived from
the media bit stream.
b) メディアビットストリームから通知か承認を容易に得ることができません。
All messages in AVPF [RFC4585] and in this memo present their contents in a simple, fixed binary format. This accommodates media receivers that have not implemented higher control protocol functionalities (SDP, XML parsers, and such) in their media path.
AVPF[RFC4585]とこのメモによるすべてのメッセージが簡単で、固定されたバイナリフォーマットでそれらのコンテンツを提示します。 これはそれらのメディア経路で、より高い制御プロトコルの機能性(SDP、XMLパーサ、およびそのようなもの)を実行していないメディア受信機を収容します。
Messages that do not conform to the design principles just described are not an appropriate use of RTCP or of the Codec Control Framework defined in this document.
ただ説明された設計原理に従わないメッセージはRTCPかCodec Control Frameworkが本書では定義された適切な使用ではありません。
4.2. Transport Layer Feedback Messages
4.2. トランスポート層フィードバックメッセージ
As specified in section 6.1 of RFC 4585 [RFC4585], transport layer feedback messages are identified by the RTCP packet type value RTPFB (205).
RFC4585[RFC4585]のセクション6.1で指定されるように、トランスポート層フィードバックメッセージはRTCPパケットタイプ値のRTPFB(205)によって特定されます。
In AVPF, one message of this category had been defined. This memo specifies two more such messages. They are identified by means of the feedback message type (FMT) parameter as follows:
AVPFでは、このカテゴリに関する1つのメッセージが定義されました。 このメモはそのようなより多くの2つのメッセージを指定します。 それらは以下のフィードバックメッセージタイプ(FMT)パラメタによって特定されます:
Assigned in AVPF [RFC4585]:
AVPF[RFC4585]で割り当てられる:
1: Generic NACK
31: reserved for future expansion of the identifier number space
1: 一般的なナック31: 識別子数のスペースの今後の拡大のために、予約されます。
Assigned in this memo:
このメモで割り当てられる:
2: reserved (see note below)
3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
2: 予約された(以下での注意を見る)3: 一時的な最大のメディアはビット伝送速度要求(TMMBR)4を流します: 一時的な最大のメディアはビット伝送速度通知を流します。(TMMBN)
Note: early versions of AVPF [RFC4585] reserved FMT=2 for a
code point that has later been removed. It has been pointed
out that there may be implementations in the field using this
value in accordance with the expired document. As there is
sufficient numbering space available, we mark FMT=2 as
reserved so to avoid possible interoperability problems with
any such early implementations.
以下に注意してください。 AVPF[RFC4585]の早めのバージョンは後で取り除かれたコード・ポイントへのFMT=2を予約しました。 実現が満期のドキュメントによると、この値を使用する分野にあるかもしれないと指摘されました。 利用可能な十分な付番スペースがあって、私たちはそのようなどんな早めの実現に関する可能な相互運用性問題も避けるために予約されるようにFMT=2をマークします。
Wenger, et al. Standards Track [Page 33] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[33ページ]。
Available for assignment:
課題に利用可能:
0: unassigned
5-30: unassigned
0: 5-30に割り当てられません: 割り当てられません。
The following subsection defines the formats of the Feedback Control Information (FCI) entries for the TMMBR and TMMBN messages, respectively, and specifies the associated behaviour at the media sender and receiver.
以下の小区分は、TMMBRとTMMBNメッセージのためにそれぞれFeedback Control情報(FCI)エントリーの書式を定義して、メディア送付者と受信機で関連ふるまいを指定します。
4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)
4.2.1. 一時的な最大のメディアはビット伝送速度要求を流します。(TMMBR)
The Temporary Maximum Media Stream Bit Rate Request is identified by RTCP packet type value PT=RTPFB and FMT=3.
Temporary MaximumメディアStream Bit Rate RequestはRTCPパケットタイプのRTPFBと太平洋標準時の値=FMT=3によって特定されます。
The FCI field of a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message SHALL contain one or more FCI entries.
SHALLが1つ以上のFCIエントリーを含んでいるというTemporary MaximumメディアStream Bit Rate Request(TMMBR)メッセージのFCI分野。
4.2.1.1. Message Format
4.2.1.1. メッセージ・フォーマット
The Feedback Control Information (FCI) consists of one or more TMMBR FCI entries with the following syntax:
Feedback Control情報(FCI)は1つ以上のTMMBR 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MxTBR Exp| MxTBR仮数|頭上では、測定されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Syntax of an FCI Entry in the TMMBR Message
図2--TMMBRメッセージにおけるFCIエントリーの構文
SSRC (32 bits): The SSRC value of the media sender that is
requested to obey the new maximum bit rate.
SSRC(32ビット): 新しい最大のビット伝送速度に従うよう要求されているメディア送付者のSSRC値。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
maximum total media bit rate value. The value is an
unsigned integer [0..63].
MxTBR Exp(6ビット): 最大の総メディアビット伝送速度価値のための仮数の指数のスケーリング。 値は符号のない整数[0 .63]です。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media
bit rate value as an unsigned integer.
MxTBR Mantissa(17ビット): 符号のない整数としての最大の総メディアビット伝送速度価値の仮数。
Measured Overhead (9 bits): The measured average packet overhead
value in bytes. The measurement SHALL be done according
to the description in section 4.2.1.2. The value is an
unsigned integer [0..511].
測定Overhead(9ビット): バイトで表現されるパケットの測定平均したオーバーヘッド価値。 測定SHALL、セクション4.2.1における記述に従って、.2にしてください。 値は符号のない整数[0 .511]です。
Wenger, et al. Standards Track [Page 34] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[34ページ]。
The maximum total media bit rate (MxTBR) value in bits per second is calculated from the MxTBR exponent (exp) and mantissa in the following way:
bpsにおける最大の総メディアビット伝送速度(MxTBR)値はMxTBR解説者(exp)と仮数から以下の方法で計算されます:
MxTBR = mantissa * 2^exp
MxTBRは仮数*2^expと等しいです。
This allows for 17 bits of resolution in the range 0 to 131072*2^63 (approximately 1.2*10^24).
これは範囲0〜131072*2^63(およそ1.2*10^24)の解決の17ビットを考慮します。
The length of the TMMBR feedback message SHALL be set to 2+2*N where N is the number of TMMBR FCI entries.
TMMBRフィードバックの長さはNがTMMBR FCIの数である2+2*NへのセットがエントリーであったならSHALLを通信させます。
4.2.1.2. Semantics
4.2.1.2. 意味論
Behaviour at the Media Receiver (Sender of the TMMBR)
メディア受信機のふるまい(TMMBRの送付者)
TMMBR is used to indicate a transport-related limitation at the reporting entity acting as a media receiver. TMMBR has the form of a tuple containing two components. The first value is the highest bit rate per sender of a media stream, available at a receiver-chosen protocol layer, which the receiver currently supports in this RTP session. The second value is the measured header overhead in bytes as defined in section 2.2 and measured at the chosen protocol layer in the packets received for the stream. The measurement of the overhead is a running average that is updated for each packet received for this particular media source (SSRC), using the following formula:
TMMBRは、メディア受信機として機能する会計主体で輸送関連の制限を示すのに使用されます。TMMBRには、2つのコンポーネントを含むtupleのフォームがあります。 メディアの流れの送付者あたり最初の値は最も高いビット伝送速度です、受信機に選ばれたプロトコル層では、利用可能です。(受信機はこのRTPセッションのときに現在、それを支えます)。 2番目の値はセクション2.2で定義されて、流れのために受け取られたパケットで選ばれたプロトコル層で測定されるようにバイトが測定ヘッダーオーバーヘッドです。 オーバーヘッドの測定はこの特定のメディア・ソース(SSRC)のために受け取られた各パケットのためにアップデートされる移動平均です、以下の公式を使用して:
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
avg_OH(新しい)は15/16*avg_OH(老人)+1/16*pckt_OHと等しいです。
where avg_OH is the running (exponentially smoothed) average and pckt_OH is the overhead observed in the latest packet.
_avg_OHが走行(指数関数的に整えられる)平均とpcktであるところでは、OHは最新のパケットで観察されたオーバーヘッドです。
If a maximum bit rate has been negotiated through signaling, the maximum total media bit rate that the receiver reports in a TMMBR message MUST NOT exceed the negotiated value converted to a common basis (i.e., with overheads adjusted to bring it to the same reference protocol layer).
最大のビット伝送速度がシグナリングを通して交渉されたなら、受信機がTMMBRメッセージで報告する最大の総メディアビット伝送速度は共有基準(すなわち、オーバーヘッドが同じ参照プロトコル層にそれを持って来るように調整されている)に変換された交渉された値を超えてはいけません。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. Within a particular TMMBR FCI entry, the "SSRC of media source" in the FCI field denotes the media sender that the tuple applies to. This is useful in the multicast or translator topologies where the reporting entity may address all of the media senders in a single TMMBR message using multiple FCI entries.
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は、要求の源、使用されない「メディア・ソースのSSRC」、およびSHALLが0に用意ができているのを示します。 特定のTMMBR FCIエントリーの中では、FCI分野の「メディア・ソースのSSRC」はtupleが申し込むメディア送付者を指示します。 これは会計主体がただ一つのTMMBRメッセージに複数のFCIエントリーを使用することでメディア送付者のすべてを記述するかもしれないマルチキャストか翻訳者topologiesで役に立ちます。
Wenger, et al. Standards Track [Page 35] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[35ページ]。
The media receiver SHALL save the contents of the latest TMMBN message received from each media sender.
メディア受信機SHALLはそれぞれのメディア送付者から受け取られた最新のTMMBNメッセージのコンテンツを救います。
The media receiver MAY send a TMMBR FCI entry to a particular media sender under the following circumstances:
メディア受信機は以下の状況による特定のメディア送付者にTMMBR FCIエントリーを送るかもしれません:
o before any TMMBN message has been received from that media
sender;
o 以前、そのメディア送付者からどんなTMMBNメッセージも受け取ったことがあります。
o when the media receiver has been identified as the source of a
bounding tuple within the latest TMMBN message received from
that media sender, and the value of the maximum total media bit
rate or the overhead relating to that media sender has changed;
o メディア受信機がいつ制限tupleの源として最新のTMMBNメッセージの中で特定されたかはそのメディア送付者から受信されました、そして、最大の総メディアビット伝送速度の値かそのメディア送付者に関係するオーバーヘッドが変化しました。
o when the media receiver has not been identified as the source
of a bounding tuple within the latest TMMBN message received
from that media sender, and, after the media receiver applies
the incremental algorithm from section 3.5.4.2 or a stricter
equivalent, the media receiver's tuple relating to that media
sender is determined to belong to the bounding set.
o そして、メディア受信機がそのメディア送付者に関係する.2か、より厳しい同等物、メディア受信機のtupleが属すことを決定しているセクション3.5.4から増加のアルゴリズムを適用した後に最新のTMMBNメッセージの中の制限tupleの源がそのメディア送付者から受信したのでメディア受信機が特定されていないとき、制限はセットしました。
A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no Temporary Maximum Media Stream Bit Rate Notification (TMMBN) FCI has been received from the media sender at the time of transmission of the next RTCP packet. The bit rate value of a TMMBR FCI entry MAY be changed from one TMMBR message to the next. The overhead measurement SHALL be updated to the current value of avg_OH each time the entry is sent.
次のRTCPパケットのトランスミッション時点でメディア送付者からTemporary MaximumメディアStream Bit Rate Notification(TMMBN)FCIを全く受け取っていないなら、その後のTMMBRメッセージでTMMBR FCIエントリーを繰り返すかもしれません。 TMMBR FCIエントリーのビット伝送速度値は1つのTMMBRメッセージから次に変わるかもしれません。 頭上の測定SHALL、エントリーを送るたびにavg_OHの現行価値にアップデートしてください。
If the value set by a TMMBR message is expected to be permanent, the TMMBR setting party SHOULD renegotiate the session parameters to reflect that using session setup signaling, e.g., a SIP re-invite.
TMMBRメッセージによる選択値群が永久的であると予想されるなら、パーティーSHOULDを設定するTMMBRはセッションセットアップシグナリングを使用することでそれを反映するためにセッションパラメタを再交渉します、例えば、SIP再招待。
Behaviour at the Media Sender (Receiver of the TMMBR)
メディア送付者のふるまい(TMMBRの受信機)
When it receives a TMMBR message containing an FCI entry relating to it, the media sender SHALL use an initial or incremental algorithm as applicable to determine the bounding set of tuples based on the new information. The algorithm used SHALL be at least as strict as the corresponding algorithm defined in section 3.5.4.2. The media sender MAY accumulate TMMBRs over a small interval (relative to the RTCP sending interval) before making this calculation.
それに関連するFCIエントリーを含むTMMBRメッセージを受け取るとき、メディア送付者SHALLは新情報に基づくtuplesの制限セットを決定するのにおいて適切であるとして初期の、または、増加のアルゴリズムを使用します。 アルゴリズムはSHALLを使用しました。対応するアルゴリズムがセクション3.5.4で.2を定義したのと少なくとも同じくらい厳しくいてください。 この計算をする前に、メディア送付者は小さい間隔(RTCP送付間隔に比例した)にわたってTMMBRsを蓄積するかもしれません。
Once it has determined the bounding set of tuples, the media sender MAY use any combination of packet rate and net media bit rate within the feasible region that these tuples describe to produce a lower
いったんtuplesの制限セットを決定すると、メディア送付者はこれらのtuplesが、より低くaを生産するために説明する可能な領域の中でパケットレートとネットのメディアビット伝送速度のどんな組み合わせも使用するかもしれません。
Wenger, et al. Standards Track [Page 36] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[36ページ]。
total media stream bit rate, as it may need to address a congestion situation or other limiting factors. See section 5 (congestion control) for more discussion.
混雑状況か他の限定因子を記述するのが必要であるときに、総メディアはビット伝送速度を流します。 より多くの議論に関してセクション5(輻輳制御)を見てください。
If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set. This delay period is estimated by the formula:
メディア送付者が最大の総メディアビット伝送速度価値を増加させることができて、制限セットにはtupleがいることを決定するならそのように、そして、しばらく実際にメディア受信機がTMMBNに応じるのを許容できるくらいの長い間する前のSHALL待ちであると結論を下すなら。 この遅れの期間は公式によって見積もられています:
2 * RTT + T_Dither_Max,
2*RTT+T_震え_マックス
where RTT is the longest round trip time known to the media sender and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in point-to-point sessions, a media sender MUST obey the aforementioned rule, as it is not guaranteed that a participant is able to determine correctly whether all the sources are co-located in a single node, and are coordinated.
RTTがどこの_メディア送付者とT Dither_マックスにとって知られている中で最も長い周遊旅行時間であるかは[RFC4585]のセクション3.4で定義されます。 指すポイントさえのセッション、メディア送付者は前述の規則に従わなければなりません、関係者がすべてのソースがただ一つのノードに共同位置していて、連携しているかどうか正しく決定できるのが保証されないとき。
A TMMBN message SHALL be sent by the media sender at the earliest possible point in time, in response to any TMMBR messages received since the last sending of TMMBN. The TMMBN message indicates the calculated set of bounding tuples and the owners of those tuples at the time of the transmission of the message.
TMMBNメッセージSHALLが時間内に可能な限り前のポイントのメディア送付者によって送られて、TMMBNの最後の発信以来どんなTMMBRに対応してメッセージは受信されました。 TMMBNメッセージはメッセージの伝達時点で、制限tuplesの計算されたセットとそれらのtuplesの所有者を示します。
An SSRC may time out according to the default rules for RTP session participants, i.e., the media sender has not received any RTP or RTCP packets from the owner for the last five regular reporting intervals. An SSRC may also explicitly leave the session, with the participant indicating this through the transmission of an RTCP BYE packet or using an external signaling channel. If the media sender determines that the owner of a tuple in the bounding set has left the session, the media sender SHALL transmit a new TMMBN containing the previously determined set of bounding tuples but with the tuple belonging to the departed owner removed.
SSRCは容認されたいずれもRTPではなく、RTPセッション関係者、すなわち、送付者が持っているメディアのための省略時の解釈に従ったタイムアウトかここ5回の一定の報告間隔の間の所有者からのRTCPパケットがそうするかもしれません。 また、SSRCは明らかにセッションを残すかもしれません、関係者がRTCP BYEパケットのトランスミッションでこれを示すか、または外部のシグナリングチャンネルを使用していて。 メディア送付者が、制限セットにおけるtupleの所有者がセッションを残したと決心しているなら、メディア送付者SHALLは制限tuplesの以前に決定しているセットを含む新しいTMMBNを伝えますが、tupleで、去られた所有者に属すのは取り外されました。
A media sender MAY proactively initiate the equivalent to a TMMBR message to itself, when it is aware that its transmission path is more restrictive than the current limitations. As a result, a TMMBN indicating the media source itself as the owner of a tuple is being sent, thereby avoiding unnecessary TMMBR messages from other participants. However, like any other participant, when the media sender becomes aware of changed limitations, it is required to change the tuple, and to send a corresponding TMMBN.
メディア送付者はTMMBRメッセージと同等物をそれ自体に予測して開始するかもしれません、トランスミッション経路が現在の制限より制限しているのが、意識しているとき。 その結果、tupleの所有者としてメディア・ソース自身を示すTMMBNを送ります、その結果、他の関係者からの不要なTMMBRメッセージを避けます。 しかしながら、いかなる他の関係者のようにも、メディア送付者が変えられた制限を意識するようになるとき、それが、tupleを変えて、対応するTMMBNを送るのに必要です。
Wenger, et al. Standards Track [Page 37] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[37ページ]。
Discussion
議論
Due to the unreliable nature of transport of TMMBR and TMMBN, the above rules may lead to the sending of TMMBR messages that appear to disobey those rules. Furthermore, in multicast scenarios it can happen that more than one "non-owning" session participant may determine, rightly or wrongly, that its tuple belongs in the bounding set. This is not critical for a number of reasons:
TMMBRとTMMBNの輸送の頼り無い本質のため、上の規則はそれらの規則に背くように見えるTMMBRメッセージの発信に通じるかもしれません。 その上、マルチキャストシナリオでは、1人以上の「非所有している」セッション関係者が、制限セットにはtupleがいると正しいか誤って決心しているかもしれないのを起こることができます。 これは様々な意味で批判的ではありません:
a) If a TMMBR message is lost in transmission, either the media
sender sends a new TMMBN message in response to some other media
receiver or it does not send a new TMMBN message at all. In the
first case, the media receiver applies the incremental algorithm
and, if it determines that its tuple should be part of the
bounding set, sends out another TMMBR. In the second case, it
repeats the sending of a TMMBR unconditionally. Either way, the
media sender eventually gets the information it needs.
a) TMMBRメッセージがトランスミッションで失われているなら、メディア送付者がある他のメディア受信機に対応して新しいTMMBNメッセージを送るか、またはそれは全く新しいTMMBNメッセージを送りません。 前者の場合、メディア受信機は、増加のアルゴリズムを適用して、tupleが制限セットの一部であるべきであることを決定するなら、別のTMMBRを出します。 2番目の場合では、それは無条件にTMMBRの発信を繰り返します。 いずれにせよ、メディア送付者は結局、それが必要とする情報を得ます。
b) Similarly, if a TMMBN message gets lost, the media receiver that
has sent the corresponding TMMBR does not receive the notification
and is expected to re-send the request and trigger the
transmission of another TMMBN.
b) 同様に、TMMBNメッセージが失せるなら、対応するTMMBRを送ったメディア受信機は、通知を受け取らないで、要求を再送して、別のTMMBNのトランスミッションの引き金となると予想されます。
c) If multiple competing TMMBR messages are sent by different session
participants, then the algorithm can be applied taking all of
these messages into account, and the resulting TMMBN provides the
participants with an updated view of how their tuples compare with
the bounded set.
c) 複数の競争しているTMMBRメッセージが異なったセッション関係者によって送られるなら、これらのメッセージのすべてを考慮に入れながら、アルゴリズムを適用できます、そして、結果として起こるTMMBNは彼らのtuplesがどう有界集合と比較されるかに関するアップデートされた意見を関係者に提供します。
d) If more than one session participant happens to send TMMBR
messages at the same time and with the same tuple component
values, it does not matter which of those tuples is taken into the
bounding set. The losing session participant will determine,
after applying the algorithm, that its tuple does not enter the
bounding set, and will therefore stop sending its TMMBR.
d) 1人以上のセッション関係者がたまたま同時間と同じtuple成分値があるメッセージをTMMBRに送るなら、それは重要ではありません(それらのtuplesについて制限セットに連れていかれます)。 アルゴリズムを適用した後に、負けているセッション関係者は、tupleが、制限セットに入らないで、したがって、TMMBRを送るのを止めると決心するでしょう。
It is important to consider the security risks involved with faked TMMBRs. See the security considerations in section 6.
見せかけられたTMMBRsに伴われるセキュリティ危険を考えるのは重要です。 セクション6のセキュリティ問題を見てください。
As indicated already, the feedback messages may be used in both multicast and unicast sessions in any of the specified topologies. However, for sessions with a large number of participants, using the lowest common denominator, as required by this mechanism, may not be the most suitable course of action. Large sessions may need to consider other ways to adapt the bit rate to participants' capabilities, such as partitioning the session into different quality tiers or using some other method of achieving bit rate scalability.
既に示されるように、フィードバックメッセージは指定されたtopologiesのどれかのマルチキャストとユニキャストセッションの両方で使用されるかもしれません。 しかしながら、多くの関係者とのセッションに必要に応じてこのメカニズムで最小公分母を使用するのは、最も適当な行動でないかもしれません。 大きいセッションは、関係者の能力にビット伝送速度を適合させる他の方法を考える必要があるかもしれません、異なった上質の層にセッションを仕切るか、またはビット伝送速度スケーラビリティを達成するある他の方法を使用するのなどように。
Wenger, et al. Standards Track [Page 38] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[38ページ]。
4.2.1.3. Timing Rules
4.2.1.3. タイミング規則
The first transmission of the TMMBR message MAY use early or immediate feedback in cases when timeliness is desirable. Any repetition of a request message SHOULD use regular RTCP mode for its transmission timing.
タイムリーが望ましいときに、TMMBRメッセージの最初の伝達は場合に早いか即座のフィードバックを使用するかもしれません。 SHOULDがトランスミッションタイミングに通常のRTCPモードを使用するという要求メッセージのどんな反復。
4.2.1.4. Handling in Translators and Mixers
4.2.1.4. 翻訳者とミキサーの取り扱い
Media translators and mixers will need to receive and respond to TMMBR messages as they are part of the chain that provides a certain media stream to the receiver. The mixer or translator may act locally on the TMMBR and thus generate a TMMBN to indicate that it has done so. Alternatively, in the case of a media translator it can forward the request, or in the case of a mixer generate one of its own and pass it forward. In the latter case, the mixer will need to send a TMMBN back to the original requestor to indicate that it is handling the request.
メディア翻訳者とミキサーは、それらが、あるメディアの流れを受信機に供給するチェーンの一部であるのでTMMBRメッセージに受信して、応じる必要があるでしょう。ミキサーか翻訳者が、局所的にTMMBRに影響して、その結果、それがそうしたのを示すためにTMMBNを発生させるかもしれません。 あるいはまた、メディア翻訳者の場合では、それは、要求を転送するか、ミキサーの場合でそれ自身の1つを発生させて、またはそれを前方へパスすることができます。 後者の場合では、ミキサーは、要求を扱っているのを示すためにオリジナルの要請者にTMMBNを送り返す必要があるでしょう。
4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
4.2.2. 一時的な最大のメディアはビット伝送速度通知を流します。(TMMBN)
The Temporary Maximum Media Stream Bit Rate Notification is identified by RTCP packet type value PT=RTPFB and FMT=4.
Temporary MaximumメディアStream Bit Rate NotificationはRTCPパケットタイプのRTPFBと太平洋標準時の値=FMT=4によって特定されます。
The FCI field of the TMMBN feedback message may contain zero, one, or more TMMBN FCI entries.
TMMBNフィードバックメッセージのFCI分野はゼロ、1つ以上のTMMBN FCIエントリーを含むかもしれません。
4.2.2.1. Message Format
4.2.2.1. メッセージ・フォーマット
The Feedback Control Information (FCI) consists of zero, one, or more TMMBN FCI entries with the following syntax:
Feedback Control情報(FCI)はゼロ、以下の構文による1つ以上のTMMBN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MxTBR Exp| MxTBR仮数|頭上では、測定されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax of an FCI Entry in the TMMBN Message
図3--TMMBNメッセージにおけるFCIエントリーの構文
SSRC (32 bits): The SSRC value of the "owner" of this tuple.
SSRC(32ビット): このtupleの「所有者」のSSRC値。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
maximum total media bit rate value. The value is an
unsigned integer [0..63].
MxTBR Exp(6ビット): 最大の総メディアビット伝送速度価値のための仮数の指数のスケーリング。 値は符号のない整数[0 .63]です。
Wenger, et al. Standards Track [Page 39] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[39ページ]。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media
bit rate value as an unsigned integer.
MxTBR Mantissa(17ビット): 符号のない整数としての最大の総メディアビット伝送速度価値の仮数。
Measured Overhead (9 bits): The measured average packet overhead
value in bytes represented as an unsigned integer
[0..511].
測定Overhead(9ビット): 符号のない整数[0 .511]として表されたバイトで表現されるパケットの測定平均したオーバーヘッド価値。
Thus, the FCI within the TMMBN message contains entries indicating the bounding tuples. For each tuple, the entry gives the owner by the SSRC, followed by the applicable maximum total media bit rate and overhead value.
したがって、TMMBNメッセージの中のFCIはバウンドしているtuplesを示すエントリーを含んでいます。 各tupleに関しては、エントリーは適切な最大の総メディアビット伝送速度と頭上の値があとに続いたSSRCで所有者に与えます。
The length of the TMMBN message SHALL be set to 2+2*N where N is the number of TMMBN FCI entries.
TMMBNの長さはNがTMMBN FCIの数である2+2*NへのセットがエントリーであったならSHALLを通信させます。
4.2.2.2. Semantics
4.2.2.2. 意味論
This feedback message is used to notify the senders of any TMMBR message that one or more TMMBR messages have been received or that an owner has left the session. It indicates to all participants the current set of bounding tuples and the "owners" of those tuples.
このフィードバックメッセージは、1つ以上のTMMBRメッセージを受け取ったか、または所有者がセッションを残したことをどんなTMMBRメッセージの送付者にも通知するのに使用されます。 それは電流が設定した制限tuplesの関係者とそれらのtuplesの「所有者」をすべてに示します。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the notification. The "SSRC of media source" is not used and SHALL be set to 0.
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は通知の源を示します。 使用されない「メディア・ソースのSSRC」とSHALL、0に設定されてください。
A TMMBN message SHALL be scheduled for transmission after the reception of a TMMBR message with an FCI entry identifying this media sender. Only a single TMMBN SHALL be sent, even if more than one TMMBR message is received between the scheduling of the transmission and the actual transmission of the TMMBN message. The TMMBN message indicates the bounding tuples and their owners at the time of transmitting the message. The bounding tuples included SHALL be the set arrived at through application of the applicable algorithm of section 3.5.4.2 or an equivalent, applied to the previous bounding set, if any, and tuples received in TMMBR messages since the last TMMBN was transmitted.
TMMBNはSHALLを通信させます。トランスミッションには、FCIエントリーがこのメディア送付者を特定しているTMMBRメッセージのレセプションの後に予定されてください。 aはTMMBN SHALLを選抜するだけです。送ってください、トランスミッションのスケジューリングとTMMBNメッセージの実際の伝達の間に1つ以上のTMMBRメッセージを受け取っても。 メッセージを送る時点で、TMMBNメッセージはバウンドしているtuplesと彼らの所有者を示します。 バウンドしているtuplesはセクション3.5.4の適切なアルゴリズムの適用で到着したセットがもしあれば設定された前の制限に適用された.2か同等物であったならSHALLを含んでいました、そして、最後のTMMBNが伝えられたので、tuplesはTMMBRメッセージで受信されました。
The reception of a TMMBR message SHALL still result in the transmission of a TMMBN message even if, after application of the algorithm, the newly reported TMMBR tuple is not accepted into the bounding set. In such a case, the bounding tuples and their owners are not changed, unless the TMMBR was from an owner of a tuple within the previously calculated bounding set. This procedure allows session participants that did not see the last TMMBN message to get a correct view of this media sender's state.
新たに報告されたTMMBR tupleがアルゴリズムの適用の後に制限セットに受け入れられないでもSHALLがまだTMMBNメッセージの伝達をもたらしているというTMMBRメッセージのレセプション。 このような場合には、バウンドしているtuplesと彼らの所有者は変えられません、TMMBRが以前に計算された制限セットの中でtupleの所有者から来ていなかったなら。 この手順はこのメディア送付者の状態の正当な見解を得る最後のTMMBNメッセージを見なかったセッション関係者を許容します。
Wenger, et al. Standards Track [Page 40] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[40ページ]。
As indicated in section 4.2.1.2, when a media sender determines that an "owner" of a bounding tuple has left the session, then that tuple is removed from the bounding set, and the media sender SHALL send a TMMBN message indicating the remaining bounding tuples. If there are no remaining bounding tuples, a TMMBN without any FCI SHALL be sent to indicate this. Without a remaining bounding tuple, the maximum media bit rate and maximum packet rate negotiated in session signaling, if any, apply.
.2、メディア送付者が、いつ制限tupleの「所有者」がセッションを残して、その時tupleが制限セットから取り外されると決心するか、そして、およびメディア送付者SHALLが残っている制限tuplesを示すTMMBNメッセージを送るセクション4.2.1にみられるように。 いいえ、残りのバウンドしているtuples、少しもFCI SHALLのないTMMBNあれば。これを示させます。 残っている制限tupleがなければ、セッションシグナリングでもしあれば交渉された最大のメディアビット伝送速度と最大のパケットレートは適用されます。
Note: if any media receivers remain in the session, this last will
be a temporary situation. The empty TMMBN will cause every
remaining media receiver to determine that its limitation belongs
in the bounding set and send a TMMBR in consequence.
以下に注意してください。 何かメディア受信機がセッションのときに残っていると、これは最後に一時的な状況になるでしょう。 空のTMMBNは、あらゆる残っているメディア受信機が制限セットには制限があることを決定して、その結果、TMMBRを送ることを引き起こすでしょう。
In unicast scenarios (i.e., where a single sender talks to a single receiver), the aforementioned algorithm to determine ownership degenerates to the media receiver becoming the "owner" of the one bounding tuple as soon as the media receiver has issued the first TMMBR message.
ユニキャストシナリオ(すなわち、独身の送付者はそこで単一の受信機と話す)では、所有権を決定する前述のアルゴリズムはメディア受信機が最初のTMMBRメッセージを発行するとすぐに、1制限tupleの「所有者」になるメディア受信機に退化しています。
4.2.2.3. Timing Rules
4.2.2.3. タイミング規則
The TMMBN acknowledgement SHOULD be sent as soon as allowed by the applied timing rules for the session. Immediate or early feedback mode SHOULD be used for these messages.
TMMBN承認SHOULD、できるだけ早くセッションのための適用されたタイミング規則で、送ってください。 即座の、または、早めのフィードバックモードSHOULD、これらのメッセージには、使用されてください。
4.2.2.4. Handling by Translators and Mixers
4.2.2.4. 翻訳者とミキサーによる取り扱い
As discussed in section 4.2.1.4, mixers or translators may need to issue TMMBN messages as responses to TMMBR messages for SSRCs handled by them.
セクション4.2で.1人の.4、ミキサーまたは翻訳者について議論するので、彼らによって扱われたSSRCsへのTMMBRメッセージへの応答としてTMMBNにメッセージを発行するのが必要であるかもしれません。
4.3. Payload-Specific Feedback Messages
4.3. 有効搭載量特有のフィードバックメッセージ
As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific FB messages are identified by the RTCP packet type value PSFB (206).
RFC4585[RFC4585]のセクション6.1によって指定されるように、有効搭載量特有のFBメッセージはRTCPパケットタイプ値のPSFB(206)によって特定されます。
AVPF [RFC4585] defines three payload-specific feedback messages and one application layer feedback message. This memo specifies four additional payload-specific feedback messages. All are identified by means of the FMT parameter as follows:
AVPF[RFC4585]は3つのペイロード特有のフィードバックメッセージと1つの応用層フィードバックメッセージを定義します。 このメモは4つの追加ペイロード特有のフィードバックメッセージを指定します。 すべてが以下のFMTパラメタによって特定されます:
Wenger, et al. Standards Track [Page 41] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[41ページ]。
Assigned in [RFC4585]:
[RFC4585]で割り当てられる:
1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
15: Application layer FB message
31: reserved for future expansion of the number space
1: 損失指示(PLI)2について描写してください: 無くなっている指示(SLI)3を切ってください: 参照絵の選択指示(RPSI)15: 応用層FBメッセージ31: 数のスペースの今後の拡大のために、予約されます。
Assigned in this memo:
このメモで割り当てられる:
4: Full Intra Request (FIR) Command
5: Temporal-Spatial Trade-off Request (TSTR)
6: Temporal-Spatial Trade-off Notification (TSTN)
7: Video Back Channel Message (VBCM)
4: 完全なイントラ要求(モミ)命令5: 時、空間的なトレードオフ要求(TSTR)6: 時、空間的なトレードオフ通知(TSTN)7: ビデオの逆チャンネルメッセージ(VBCM)
Unassigned:
割り当てられない:
0: unassigned
8-14: unassigned
16-30: unassigned
0: 8-14に割り当てられません: 16-30に割り当てられません: 割り当てられません。
The following subsections define the new FCI formats for the payload-specific feedback messages.
以下の小区分はペイロード特有のフィードバックメッセージのための新しいFCI書式を定義します。
4.3.1. Full Intra Request (FIR)
4.3.1. 完全なイントラ要求(モミ)
The FIR message is identified by RTCP packet type value PT=PSFB and FMT=4.
FIRメッセージはRTCPパケットタイプのPSFBと太平洋標準時の値=FMT=4によって特定されます。
The FCI field MUST contain one or more FIR entries. Each entry applies to a different media sender, identified by its SSRC.
FCI分野は1つ以上のFIRエントリーを含まなければなりません。 各エントリーはSSRCによって特定された異なったメディア送付者に適用されます。
4.3.1.1. Message Format
4.3.1.1. メッセージ・フォーマット
The Feedback Control Information (FCI) for the Full Intra Request consists of one or more FCI entries, the content of which is depicted in Figure 4. The length of the FIR feedback message MUST be set to 2+2*N, where N is the number of FCI entries.
Full Intra RequestのためのFeedback Control情報(FCI)は1つ以上のFCIエントリーから成ります。その内容は図4に表現されます。 2+2*NにFIRフィードバックメッセージの長さを設定しなければなりません。そこでは、Nが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr。 | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of an FCI Entry in the FIR Message
図4--モミメッセージにおけるFCIエントリーの構文
Wenger, et al. Standards Track [Page 42] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[42ページ]。
SSRC (32 bits): The SSRC value of the media sender that is
requested to send a decoder refresh point.
SSRC(32ビット): デコーダを送るよう要求されているメディア送付者のSSRC値はポイントをリフレッシュします。
Seq nr. (8 bits): Command sequence number. The sequence number
space is unique for each pairing of the SSRC of command
source and the SSRC of the command target. The sequence
number SHALL be increased by 1 modulo 256 for each new
command. A repetition SHALL NOT increase the sequence
number. The initial value is arbitrary.
Seq nr。 (8ビット): 系列番号を命令してください。 コマンドソースのSSRCとコマンド目標のSSRCの各組み合わせに、一連番号スペースはユニークです。 1つ増加してください。一連番号SHALL、それぞれの新しいコマンドのための法256。 反復SHALL NOTは一連番号を増加させます。 初期の値は任意です。
Reserved (24 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception.
予約(24ビット): すべてのビットSHALL、いてください。送付者とSHALLによって0に設定されて、レセプションで無視されてください。
The semantics of this feedback message is independent of the RTP payload type.
このフィードバックメッセージの意味論はRTPペイロードタイプから独立しています。
4.3.1.2. Semantics
4.3.1.2. 意味論
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the FIR command applies are in the corresponding FCI entries. A FIR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は、要求の源、使用されない「メディア・ソースのSSRC」、およびSHALLが0に用意ができているのを示します。 FIRコマンドが適用されるメディア送付者のSSRCsが対応するFCIエントリーにあります。 目標メディア送付者あたり1つのFCIエントリーを使用して、FIRメッセージはマルチメディア送付者に要求を含むかもしれません。
Upon reception of FIR, the encoder MUST send a decoder refresh point (see section 2.2) as soon as possible.
FIRのレセプションでは、エンコーダはできるだけ早く、ポイント(セクション2.2を見る)をデコーダがリフレッシュするaに送らなければなりません。
The sender MUST consider congestion control as outlined in section 5, which MAY restrict its ability to send a decoder refresh point quickly.
送付者は、デコーダを送る性能を制限するかもしれないセクション5で概説されている輻輳制御がすぐにポイントをリフレッシュすると考えなければなりません。
FIR SHALL NOT be sent as a reaction to picture losses -- it is RECOMMENDED to use PLI [RFC4585] instead. FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users.
FIR SHALL NOT、反応として、絵の損失に送ってください--それは代わりに、PLI[RFC4585]を使用するRECOMMENDEDです。 FIR SHOULD、ポイントがユーザにとって、使用不可能なビデオをするデコーダを送らないのがリフレッシュする状況だけで、使用されてください。
A typical example where sending FIR is appropriate is when, in a multipoint conference, a new user joins the session and no regular decoder refresh point interval is established. Another example would be a video switching MCU that changes streams. Here, normally, the MCU issues a FIR to the new sender so to force it to emit a decoder refresh point. The decoder refresh point normally includes a Freeze Picture Release (defined outside this specification), which re-starts the rendering process of the receivers. Both techniques mentioned are commonly used in MCU-based multipoint conferences.
送付FIRによる適切であるのが、マルチポイント会議の新しいユーザがいつセッションに参加するか、そして、どんな通常のデコーダもポイント間隔をリフレッシュしないということであるということである典型的な例は確立されます。 別の例は流れを変えるMCUを切り換えるビデオでしょう。通常、ここで、MCUは新しい送付者にFIRを発行します、したがって、デコーダを放たせるのがポイントをリフレッシュします。 デコーダはリフレッシュします。通常、ポイントはFreeze Picture Release(この仕様の外で定義されます)(受信機の表現の過程を再開するもの)を含んでいます。 言及された両方のテクニックはMCUを拠点とするマルチポイント会議に一般的に使用されます。
Wenger, et al. Standards Track [Page 43] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[43ページ]。
Other RTP payload specifications such as RFC 2032 [RFC2032] already define a feedback mechanism 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 of receiving and reacting to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
RFC2032など[RFC2032]の他のRTPペイロード仕様はあるコーデックのために既にフィードバック・メカニズムを定義します。 両方の計画を支持するアプリケーションはフィードバックを送るときこの仕様に基づき定義されたフィードバック・メカニズムを使用しなければなりません。 後方の互換性理由、そのようなまた、受信できてフィードバックに反応しているアプリケーションSHOULDにおいて、これが定義されるならそれぞれのRTPペイロード形式で定義された計画がそのペイロード形式が必要です。
4.3.1.3. Timing Rules
4.3.1.3. タイミング規則
The timing follows the rules outlined in section 3 of [RFC4585]. FIR commands MAY be used with early or immediate feedback. The FIR feedback message MAY be repeated. If using immediate feedback mode, the repetition SHOULD wait at least one RTT before being sent. In early or regular RTCP mode, the repetition is sent in the next regular RTCP packet.
タイミングは[RFC4585]のセクション3で概説された規則に従います。 FIRコマンドは早いか即座のフィードバックで使用されるかもしれません。 FIRフィードバックメッセージは繰り返されるかもしれません。 即座のフィードバックモードを使用するなら、送る前に反復SHOULDは少なくとも1RTTを待っています。 早いか通常のRTCPモードで、次のレギュラーのRTCPパケットで反復を送ります。
4.3.1.4. Handling of FIR Message in Mixers and Translators
4.3.1.4. ミキサーと翻訳者のモミメッセージの取り扱い
A media translator or a mixer performing media encoding of the content for which the session participant has issued a FIR is responsible for acting upon it. A mixer acting upon a FIR SHOULD NOT forward the message unaltered; instead, it SHOULD issue a FIR itself.
セッション関係者がFIRを発行した内容のメディアコード化を実行するメディア翻訳者かミキサーがそれに作用するのに原因となります。 FIR SHOULD NOTフォワードにメッセージを活動させるミキサーは非変更されました。 代わりにそれ、SHOULDはFIR自身を発行します。
4.3.1.5. Remarks
4.3.1.5. 注意
Currently, video appears to be the only useful application for FIR, as it appears to be the only RTP payload widely deployed that relies heavily on media prediction across RTP packet boundaries. However, use of FIR could also reasonably be envisioned for other media types that share essential properties with compressed video, namely, cross-frame prediction (whatever a frame may be for that media type). One possible example may be the dynamic updates of MPEG-4 scene descriptions. It is suggested that payload formats for such media types refer to FIR and other message types defined in this specification and in AVPF [RFC4585], instead of creating similar mechanisms in the payload specifications. The payload specifications may have to explain how the payload-specific terminologies map to the video-centric terminology used herein.
現在、ビデオはFIRが唯一の役に立つアプリケーションであるように見えます、それがRTPパケット境界の向こう側に大いにメディア予測に依存するのが広く配備された唯一のRTPペイロードであるように見えるとき。 しかしながら、また、圧縮されたビデオすなわち、交差しているフレームの予測(フレームはそのメディアタイプのためのことなら何でもであるかもしれない)と不可欠の特性を共有する他のメディアタイプのために合理的にFIRの使用を思い描くことができました。 1つの可能な例がMPEG-4つの場面記述のダイナミックな最新版であるかもしれません。 そのようなメディアタイプのためのペイロード形式がFIRとこの仕様とAVPF[RFC4585]で定義された他のメッセージタイプについて言及することが提案されます、ペイロード仕様で同様のメカニズムを作成することの代わりに。 ペイロード仕様で、ペイロード特有の用語がどうここに使用される用語をビデオ中心に写像するかがわからなければならないかもしれません。
In conjunction with video codecs, FIR messages typically trigger the sending of full intra or IDR pictures. Both are several times larger than 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 significant multiple 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
ビデオコーデックに関連して、FIRメッセージは通常完全なイントラかIDRの絵の発信の引き金となります。 何度か両方がそうです。予測されるより大きい(間の)絵。 それらのサイズはそれらが発生する時から独立しています。 ほとんどの環境で、特に帯域幅で限られたリンクを使うとき、イントラの絵の使用は典型的なフレーム持続時間のかなりの倍数である許容遅れを含意します。 例: 送付フレームレートは10fpsです、そして、イントラの絵は10倍大きいと思われます。
Wenger, et al. Standards Track [Page 44] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[44ページ]。
inter picture, then a full second of latency has to be accepted. In such an environment, there is no need for a particularly short delay in sending the FIR message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [RFC4585] should not have an overly negative impact on the system performance.
絵を埋葬してください、そして、次に、潜在のまるまる1秒を受け入れなければなりません。 そのような環境には、FIRメッセージを送る特に少しな遅れの必要は全くありません。 したがって、[RFC4585]に従ってRTCPタイミング規則で許容された次の可能な時間帯を待っていると、ひどく否定的な影響力はシステム性能に持たれるべきではありません。
Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application viewpoint, but is problematic from a congestion control point of view. "As soon as possible" as mentioned above appears to be a reasonable compromise.
デコーダの発信を完成するための最大の遅れがポイントをリフレッシュするのを強制するのは、アプリケーション観点から望ましいでしょうが、混雑制御点から問題が多いです。 合理的な妥協は「できるだけ早く、」言及されるように上にあるように見えます。
In environments where the sender has no control over the codec (e.g., when streaming pre-recorded and pre-coded content), the reaction to this command cannot be specified. One suitable reaction of a sender would be to skip forward in the video bit stream to the next decoder refresh point. In other scenarios, it may be preferable not to react to the command at all, e.g., when streaming to a large multicast group. Other reactions may also be possible. When deciding on a strategy, a sender could take into account factors such as the size of the receiving group, the "importance" of the sender of the FIR message (however "importance" may be defined in this specific application), the frequency of decoder refresh points in the content, and so on. However, a session that predominantly handles pre-coded content is not expected to use FIR at all.
送付者がコーデックを管理しない(例えば、ストリーミングは、いつ内容をあらかじめ記録して、あらかじめコード化しましたか)環境で、このコマンドへの反応を指定できません。 送付者の1回の適当な反応は次のデコーダへのビデオビットストリームのスキップフォワードにポイントをリフレッシュすることでしょう。 例えば、大きいマルチキャストグループに流れるとき、他のシナリオでは、全くコマンドに反応しないのは望ましいかもしれません。 また、他の反応も可能であるかもしれません。 受信グループのサイズ、FIRメッセージ(しかしながら、「重要性」はこの特定のアプリケーションで定義されるかもしれない)の送付者の「重要性」などのようにデコーダの頻度を因数分解する戦略、送付者が、考慮に入れることができた決めるのがいつリフレッシュするかは内容、などに指します。 しかしながら、あらかじめコード化された内容を支配的に扱うセッションが全くFIRを使用しないと予想されます。
The relationship between the Picture Loss Indication and FIR is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a Picture Loss Indication informs the decoder about the loss of a picture and hence the likelihood of misalignment of the reference pictures between the encoder and decoder. Such a scenario is normally related to losses in an ongoing connection. In point-to-point scenarios, and without the presence of advanced error resilience tools, one possible option for an encoder consists in sending a decoder refresh point. However, there are other options. One example is that the media sender ignores the PLI, because the embedded stream redundancy is likely to clean up the reproduced picture within a reasonable amount of time. The FIR, in contrast, leaves a (real-time) encoder no choice but to send a decoder refresh point. It does not allow the encoder to take into account any considerations such as the ones mentioned above.
Picture Loss IndicationとFIRとの関係は以下の通りです。 .1セクション6.3AVPF[RFC4585]で議論するように、Picture Loss Indicationは絵の損失の周りのデコーダとしたがって、エンコーダとデコーダの間の参照の絵の調整不良の見込みを知らせます。 通常、そのようなシナリオは進行中の接続における損失に関連します。 指すポイントのシナリオであり、弾力ツールであり高度な誤りの存在がなければ、エンコーダのための1つの可能なオプションが、デコーダを送りながら、存します。ポイントをリフレッシュしてください。 しかしながら、別の選択肢があります。 1つの例はメディア送付者がPLIを無視するということです、埋め込まれた流れの冗長が妥当な時間以内に再生している絵をきれいにしそうであるので。 FIRは対照的に、(リアルタイムで)のエンコーダに選択を全く残しませんが、デコーダを送るには、ポイントをリフレッシュしてください。 それで、エンコーダは前記のようにものなどのどんな問題も考慮に入れることができません。
4.3.2. Temporal-Spatial Trade-off Request (TSTR)
4.3.2. 時、空間的なトレードオフ要求(TSTR)
The TSTR feedback message is identified by RTCP packet type value PT=PSFB and FMT=5.
TSTRフィードバックメッセージはRTCPパケットタイプのPSFBと太平洋標準時の値=FMT=5によって特定されます。
The FCI field MUST contain one or more TSTR FCI entries.
FCI分野は1つ以上のTSTR FCIエントリーを含まなければなりません。
Wenger, et al. Standards Track [Page 45] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[45ページ]。
4.3.2.1. Message Format
4.3.2.1. メッセージ・フォーマット
The content of the FCI entry for the Temporal-Spatial Trade-off Request is depicted in Figure 5. The length of the feedback message MUST be set to 2+2*N, where N is the number of FCI entries included.
Temporal空間的な下にTrade RequestのためのFCIエントリーの内容は図5に表現されます。 2+2*Nにフィードバックメッセージの長さを設定しなければなりません。そこでは、エントリーを含んでいて、Nが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr。 | 予約されます。| インデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Syntax of an FCI Entry in the TSTR Message
図5--TSTRメッセージにおけるFCIエントリーの構文
SSRC (32 bits): The SSRC of the media sender that is requested to
apply the trade-off value given in Index.
SSRC(32ビット): Indexで与えられたトレードオフ値を適用するよう要求されているメディア送付者のSSRC。
Seq nr. (8 bits): Request sequence number. The sequence number
space is unique for pairing of the SSRC of request source
and the SSRC of the request target. The sequence number
SHALL be increased by 1 modulo 256 for each new command.
A repetition SHALL NOT increase the sequence number. The
initial value is arbitrary.
Seq nr。 (8ビット): 一連番号を要求してください。 要求ソースのSSRCの組み合わせと要求目標のSSRCに、一連番号スペースはユニークです。 1つ増加してください。一連番号SHALL、それぞれの新しいコマンドのための法256。 反復SHALL NOTは一連番号を増加させます。 初期の値は任意です。
Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception.
予約(19ビット): すべてのビットSHALL、いてください。送付者とSHALLによって0に設定されて、レセプションで無視されてください。
Index (5 bits): An integer value between 0 and 31 that indicates
the relative trade-off that is requested. An index value
of 0 indicates the highest possible spatial quality, while
31 indicates the highest possible temporal resolution.
索引をつけてください(5ビット): 0と31の間の要求されている相対的なトレードオフを示す整数値。 0のインデックス値は可能な限り高い空間的な品質を示しますが、31は可能な限り高い時の解像度を示します。
4.3.2.2. Semantics
4.3.2.2. 意味論
A decoder can suggest a temporal-spatial trade-off level by sending a TSTR message to an encoder. If the encoder is capable of adjusting its temporal-spatial trade-off, it SHOULD take into account the received TSTR message for future coding of pictures. A value of 0 suggests a high spatial quality and a value of 31 suggests a high frame rate. The progression of values from 0 to 31 indicates monotonically a desire for higher frame rate. The index values do not correspond to precise values of spatial quality or frame rate.
デコーダは、TSTRメッセージをエンコーダに送ることによって、時、空間的なトレードオフレベルを示すことができます。 エンコーダは時、空間的なトレードオフを調整できます、それ。SHOULDは絵の未来のコード化への受信されたTSTRメッセージを考慮に入れます。 0の値は、高い空間的な品質と31の値が高いフレームレートに示されるのを示します。 0〜31までの値の進行は、より高いフレームレートに関する願望を単調に示します。 インデックス値は空間的な品質かフレームレートの正確な値と食い違っています。
Wenger, et al. Standards Track [Page 46] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[46ページ]。
The reaction to the reception of more than one TSTR message by a media sender from different media receivers is left open to the implementation. The selected trade-off SHALL be communicated to the media receivers by means of the TSTN message.
異なったメディア受信機からのメディア送付者による1つ以上のTSTRメッセージのレセプションへの反応は実現に開かれているままにされます。 選択されたトレードオフSHALL、TSTNメッセージによってメディア受信機とコミュニケートしてください。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the TSTR applies are in the corresponding FCI entries.
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は、要求の源、使用されない「メディア・ソースのSSRC」、およびSHALLが0に用意ができているのを示します。 TSTRが適用するメディア送付者のSSRCsが対応するFCIエントリーにあります。
A TSTR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
目標メディア送付者あたり1つのFCIエントリーを使用して、TSTRメッセージはマルチメディア送付者に要求を含むかもしれません。
4.3.2.3. Timing Rules
4.3.2.3. タイミング規則
The timing follows the rules outlined in section 3 of [RFC4585]. This request message is not time critical and SHOULD be sent using regular RTCP timing. Only if it is known that the user interface requires quick feedback, the message MAY be sent with early or immediate feedback timing.
タイミングは[RFC4585]のセクション3で概説された規則に従います。 メッセージが時間批判的でないというこの要求とSHOULD、通常のRTCPタイミングを使用させてください。 ユーザーインタフェースが迅速なフィードバックを必要とするのを知っている場合にだけ、早いか即座のフィードバックタイミングと共にメッセージを送るかもしれません。
4.3.2.4. Handling of Message in Mixers and Translators
4.3.2.4. ミキサーと翻訳者のメッセージの取り扱い
A mixer or media translator that encodes content sent to the session participant issuing the TSTR SHALL consider the request to determine if it can fulfill it by changing its own encoding parameters. A media translator unable to fulfill the request MAY forward the request unaltered towards the media sender. A mixer encoding for multiple session participants will need to consider the joint needs of these participants before generating a TSTR on its own behalf towards the media sender. See also the discussion in section 3.5.2.
TSTR SHALLを発行するセッション関係者に送られた内容をコード化するミキサーかメディア翻訳者がそれ自身がパラメタをコード化するのを変えることによってそれがそれを実現させることができるかどうか決定するという要求を考えます。 要求を実現させることができないメディア翻訳者はメディア送付者に向かって非変更された要求を転送するかもしれません。 複数のセッションのために関係者をコード化するミキサーは、それ自身に代わってメディア送付者に向かってTSTRを発生させる前にこれらの関係者の共同必要性を考える必要があるでしょう。 また、セクション3.5.2における議論を見てください。
4.3.2.5. Remarks
4.3.2.5. 注意
The term "spatial quality" does not necessarily refer to the resolution as measured by the number of pixels the reconstructed video is using. In fact, in most scenarios the video resolution stays constant during the lifetime of a session. However, all video compression standards have means to adjust the spatial quality at a given resolution, often influenced by the Quantizer Parameter or QP. A numerically low QP results in a good reconstructed picture quality, whereas a numerically high QP yields a coarse picture. The typical reaction of an encoder to this request is to change its rate control parameters to use a lower frame rate and a numerically lower (on average) QP, or vice versa. The precise mapping of Index value to
「空間的な品質」という用語は必ず再建されたビデオが使用しているピクセル数によって測定される解決について言及するというわけではありません。 事実上、ほとんどのシナリオでは、ビデオ解決はセッションの生涯一定の状態で残っています。 しかしながら、すべての画像圧縮規格に、しばしばQuantizer ParameterかQPによって影響を及ぼされた与えられた解決のときに空間的な品質を調整する手段があります。 数の上で低いQPは良い再建された画質をもたらしますが、数の上で高いQPは粗い絵をもたらします。 この要求へのエンコーダの典型的な反応が低いフレームレートと数の上で下側(平均的である)のQPを使用するためにレート管理パラメータを変えることであるか逆もまた同様です。 Index価値の正確なマッピング
Wenger, et al. Standards Track [Page 47] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[47ページ]。
frame rate and QP is intentionally left open here, as it depends on factors such as the compression standard employed, spatial resolution, content, bit rate, and so on.
フレームレートとQPは故意にここから開いた状態で外されます、圧縮の標準の採用していて、空間的な解決、内容、ビット伝送速度などなどの要素によるとき。
4.3.3. Temporal-Spatial Trade-off Notification (TSTN)
4.3.3. 時、空間的なトレードオフ通知(TSTN)
The TSTN message is identified by RTCP packet type value PT=PSFB and FMT=6.
TSTNメッセージはRTCPパケットタイプのPSFBと太平洋標準時の値=FMT=6によって特定されます。
The FCI field SHALL contain one or more TSTN FCI entries.
FCI分野SHALLは1つ以上のTSTN FCIエントリーを含んでいます。
4.3.3.1. Message Format
4.3.3.1. メッセージ・フォーマット
The content of an FCI entry for the Temporal-Spatial Trade-off Notification is depicted in Figure 6. The length of the TSTN message MUST be set to 2+2*N, where N is the number of FCI entries.
Temporal空間的な下にTrade NotificationのためのFCIエントリーの内容は図6に表現されます。 2+2*NにTSTNメッセージの長さを設定しなければなりません。そこでは、Nが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr。 | 予約されます。| インデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax of the TSTN
図6--TSTNの構文
SSRC (32 bits): The SSRC of the source of the TSTR that resulted in
this Notification.
SSRC(32ビット): このNotificationをもたらしたTSTRの源のSSRC。
Seq nr. (8 bits): The sequence number value from the TSTR that is
being acknowledged.
Seq nr。 (8ビット): 承認されているTSTRからの一連番号値。
Reserved (19 bits): All bits SHALL be set to 0 by the sender and
SHALL be ignored on reception.
予約(19ビット): すべてのビットSHALL、いてください。送付者とSHALLによって0に設定されて、レセプションで無視されてください。
Index (5 bits): The trade-off value the media sender is using
henceforth.
索引をつけてください(5ビット): メディア送付者が今後は使用するトレードオフ値。
Informative note: The returned trade-off value (Index) may differ
from the requested one, for example, in cases where a media
encoder cannot tune its trade-off, or when pre-recorded content is
used.
有益な注意: メディアエンコーダがトレードオフを調整できないか、またはあらかじめ記録された内容が使用されているとき、例えば、返されたトレードオフ値(インデックス)は場合において要求されたものと異なるかもしれません。
Wenger, et al. Standards Track [Page 48] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[48ページ]。
4.3.3.2. Semantics
4.3.3.2. 意味論
This feedback message is used to acknowledge the reception of a TSTR. For each TSTR received targeted at the session participant, a TSTN FCI entry SHALL be sent in a TSTN feedback message. A single TSTN message MAY acknowledge multiple requests using multiple FCI entries. The index value included SHALL be the same in all FCI entries of the TSTN message. Including a FCI for each requestor allows each requesting entity to determine that the media sender received the request. The Notification SHALL also be sent in response to TSTR repetitions received. If the request receiver has received TSTR with several different sequence numbers from a single requestor, it SHALL only respond to the request with the highest (modulo 256) sequence number. Note that the highest sequence number may be a smaller integer value due to the wrapping of the field. Appendix A.1 of [RFC3550] has an algorithm for keeping track of the highest received sequence number for RTP packets; it could be adapted for this usage.
このフィードバックメッセージは、TSTRのレセプションを承認するのに使用されます。 セッション関係者、TSTN FCIエントリーSHALLで狙った状態で受け取られた各TSTRに関しては、TSTNフィードバックメッセージで送ってください。 複数のFCIエントリーを使用して、ただ一つのTSTNメッセージは複数の要求を承諾するかもしれません。 インデックス値はすべてのFCIの同じくらいがTSTNメッセージのエントリーであったならSHALLを含んでいました。 各要請者のためのFCIを含んでいるのは、メディア送付者が要求を受け取ったことを決定するようそれぞれ実体に要求するのを許容します。 Notification SHALL、また、受けられたTSTR反復に対応して、送ってください。 受信機は要求であるならいくつかの独身の要請者と異なった一連番号でTSTRを受けました、それ。SHALLは最も高いことで(法256)一連番号を要求に反応させるだけです。 分野のラッピングのため最も高い一連番号が、より小さい整数値であるかもしれないことに注意してください。 [RFC3550]の付録A.1には、RTPパケットのために最も高い容認された一連番号の動向をおさえるためのアルゴリズムがあります。 この用法のためにそれを適合させることができました。
The TSTN SHALL include the Temporal-Spatial Trade-off index that will be used as a result of the request. This is not necessarily the same index as requested, as the media sender may need to aggregate requests from several requesting session participants. It may also have some other policies or rules that limit the selection.
TSTN SHALLは要求の結果、使用されるTemporal空間的な下にTradeインデックスを含んでいます。 これは要求された通り必ず同じインデックスではありません、メディア送付者が、数人の要求しているセッション関係者からの要求に集める必要があるとき。 また、それには、選択を制限するある他の方針か規則があるかもしれません。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the Notification, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the requesting entities to which the Notification applies are in the corresponding FCI entries.
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は、Notificationの源、使用されない「メディア・ソースのSSRC」、およびSHALLが0に用意ができているのを示します。 Notificationが適用する要求実体のSSRCsが対応するFCIエントリーにあります。
4.3.3.3. Timing Rules
4.3.3.3. タイミング規則
The timing follows the rules outlined in section 3 of [RFC4585]. This acknowledgement message is not extremely time critical and SHOULD be sent using regular RTCP timing.
タイミングは[RFC4585]のセクション3で概説された規則に従います。 メッセージが時間非常に批判的でないというこの承認とSHOULD、通常のRTCPタイミングを使用させてください。
4.3.3.4. Handling of TSTN in Mixers and Translators
4.3.3.4. ミキサーと翻訳者のTSTNの取り扱い
A mixer or translator that acts upon a TSTR SHALL also send the corresponding TSTN. In cases where it needs to forward a TSTR itself, the notification message MAY need to be delayed until the TSTR has been responded to.
またTSTR SHALLの行為が対応するTSTNを送るミキサーか翻訳者。 それがTSTR自身を進める必要がある場合では、通知メッセージは、TSTRに応じるまで遅らせられる必要があるかもしれません。
4.3.3.5. Remarks
4.3.3.5. 注意
None.
なし。
Wenger, et al. Standards Track [Page 49] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[49ページ]。
4.3.4. H.271 Video Back Channel Message (VBCM)
4.3.4. H.271のビデオの逆チャンネルメッセージ(VBCM)
The VBCM is identified by RTCP packet type value PT=PSFB and FMT=7.
VBCMはRTCPパケットタイプのPSFBと太平洋標準時の値=FMT=7によって特定されます。
The FCI field MUST contain one or more VBCM FCI entries.
FCI分野は1つ以上のVBCM FCIエントリーを含まなければなりません。
4.3.4.1. Message Format
4.3.4.1. メッセージ・フォーマット
The syntax of an FCI entry within the VBCM indication is depicted in Figure 7.
VBCM指示の中の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr。 |0| 有効搭載量タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VBCM八重奏ストリング… | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Syntax of an FCI Entry in the VBCM
図7--VBCMのFCIエントリーの構文
SSRC (32 bits): The SSRC value of the media sender that is requested
to instruct its encoder to react to the VBCM.
SSRC(32ビット): VBCMに反応するようエンコーダに命令するよう要求されているメディア送付者のSSRC値。
Seq nr. (8 bits): Command sequence number. The sequence number space
is unique for pairing of the SSRC of the command source and
the SSRC of the command target. The sequence number SHALL be
increased by 1 modulo 256 for each new command. A repetition
SHALL NOT increase the sequence number. The initial value is
arbitrary.
Seq nr。 (8ビット): 系列番号を命令してください。 コマンドソースのSSRCの組み合わせとコマンド目標のSSRCに、一連番号スペースはユニークです。 1つ増加してください。一連番号SHALL、それぞれの新しいコマンドのための法256。 反復SHALL NOTは一連番号を増加させます。 初期の値は任意です。
0: Must be set to 0 by the sender and should not be acted upon by the
message receiver.
0: 送付者が0に設定しなければならなくて、メッセージ受信機は作用するべきではありません。
Payload Type (7 bits): The RTP payload type for which the VBCM bit
stream must be interpreted.
有効搭載量Type(7ビット): VBCMビットストリームを解釈しなければならないRTPペイロードタイプ。
Length (16 bits): The length of the VBCM octet string in octets
exclusive of any padding octets.
長さ(16ビット): どんな詰め物八重奏も排他的な八重奏における、VBCM八重奏ストリングの長さ。
VBCM Octet String (variable length): This is the octet string
generated by the decoder carrying a specific feedback sub-
message.
VBCM Octet String(可変長): これは特定のフィードバックサブメッセージを伝えるデコーダで発生する八重奏ストリングです。
Padding (variable length): Bits set to 0 to make up a 32-bit
boundary.
詰め物(可変長): ビットは、32ビットの境界を作るために0にセットしました。
Wenger, et al. Standards Track [Page 50] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[50ページ]。
4.3.4.2. Semantics
4.3.4.2. 意味論
The "payload" of the VBCM indication carries different types of codec-specific, feedback information. The type of feedback information can be classified as a 'status report' (such as an indication that a bit stream was received without errors, or that a partial or complete picture or block was lost) or 'update requests' (such as complete refresh of the bit stream).
VBCM指示の「ペイロード」は異なったタイプのコーデック特有のフィードバック情報を運びます。 '現状報告'(少し、誤りなしで小川を受け取ったか、または部分的であるか完全な絵かブロックを失ったという指示などの)か'更新要求'としてフィードバック情報のタイプを分類できます(完全であるように、ビットストリームをリフレッシュしてください)。
Note: There are possible overlaps between the VBCM sub-
messages and CCM/AVPF feedback messages, such as FIR. Please
see section 3.5.3 for further discussion.
以下に注意してください。 FIRなどのVBCMサブメッセージとCCM/AVPFフィードバックメッセージの間には、可能なオーバラップがあります。 さらなる議論に関してセクション3.5.3を見てください。
The different types of feedback sub-messages carried in the VBCM are indicated by the "payloadType" as defined in [H.271]. These sub- message types are reproduced below for convenience. "payloadType", in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271 message and should not be confused with an RTP payload type.
VBCMで伝えられる異なったタイプに関するフィードバックサブメッセージは[H.271]で定義されるように"payloadType"によって示されます。 これらのサブメッセージタイプは便宜のために以下で再生します。 ITU-T Recの"payloadType"。 H.271用語は、H.271メッセージのサブタイプについて言及して、RTPペイロードタイプにおいて、混乱しているべきではありません。
Payload Message Content
Type
---------------------------------------------------------------------
0 One or more pictures without detected bit stream error
mismatch
1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially
lost
3 CRC for one parameter set
4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely
refresh the video bit stream as if no prior bit stream data
had been received
> 5 Reserved for future use by ITU-T
有効搭載量メッセージ内容タイプ--------------------------------------------------------------------- 0 送付者がまるでどんな先のビットストリームデータもITU-Tによる今後の使用のための容認された>5Reservedでないかのようにビデオビットストリームを完全にリフレッシュするべきであるのを示しながら、検出されたビットストリームの誤りのミスマッチの1Oneの絵のない完全か部分的にそうである1枚以上の絵が、1枚の絵のブロックの2Aセットを完全になくしたか、またはあるタイプ5A「リセット」のすべてのパラメタセットのための4CRCが要求する1つのパラメタセットのための3CRCを部分的になくしました。
Table 2: H.271 message types ("payloadTypes")
テーブル2: H.271メッセージタイプ("payloadTypes")
The bit string or the "payload" of a VBCM is of variable length and is self-contained and coded in a variable-length, binary format. The media sender necessarily has to be able to parse this optimized binary format to make use of VBCMs.
VBCMのビット列か「ペイロード」が、可変長があって、自己充足的でa可変長でコード化されています、バイナリフォーマット。 メディア送付者は、VBCMsを利用するために必ずこの最適化されたバイナリフォーマットを分析できなければなりません。
Each of the different types of sub-messages (indicated by payloadType) may have different semantics depending on the codec used.
それぞれに関する異なったタイプに関するサブメッセージ(payloadTypeによって示される)で、コーデックの上で異なった意味論依存を使用するかもしれません。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source"
フィードバックメッセージ([RFC4585]のセクション6.1で定義されるように)のための一般的なパケットのヘッダーの中では、「パケット送付者のSSRC」分野は要求の源、および「メディア・ソースのSSRC」を示します。
Wenger, et al. Standards Track [Page 51] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[51ページ]。
is not used and SHALL be set to 0. The SSRCs of the media senders to which the VBCM applies are in the corresponding FCI entries. The sender of the VBCM MAY send H.271 messages to multiple media senders and MAY send more than one H.271 message to the same media sender within the same VBCM.
使用されていない、SHALL、0に設定されてください。 VBCMが適用するメディア送付者のSSRCsが対応するFCIエントリーにあります。 VBCM MAYの送付者は、マルチメディア送付者へのメッセージをH.271に送って、同じVBCMの中で1つ以上のH.271メッセージを同じメディア送付者に送るかもしれません。
4.3.4.3. Timing Rules
4.3.4.3. タイミング規則
The timing follows the rules outlined in section 3 of [RFC4585]. The different sub-message types may have different properties in regards to the timing of messages that should be used. If several different types are included in the same feedback packet, then the requirements for the sub-message type with the most stringent requirements should be followed.
タイミングは[RFC4585]のセクション3で概説された規則に従います。 異なったサブメッセージタイプには、使用されるべきであるメッセージのタイミングに関して異なった特性があるかもしれません。 いくつかの異なったタイプが同じフィードバックパケットに含まれているなら、最も厳しい要件があるサブメッセージタイプのための要件は続かれるべきです。
4.3.4.4. Handling of Message in Mixers or Translators
4.3.4.4. ミキサーか翻訳者のメッセージの取り扱い
The handling of a VBCM in a mixer or translator is sub-message type dependent.
ミキサーか翻訳者のVBCMの取り扱いはサブメッセージタイプ扶養家族です。
4.3.4.5. Remarks
4.3.4.5. 注意
Please see section 3.5.3 for a discussion of the usage of H.271 messages and messages defined in AVPF [RFC4585] and this memo with similar functionality.
同様の機能性でAVPF[RFC4585]とこのメモで定義されたH.271メッセージとメッセージの用法の議論に関してセクション3.5.3を見てください。
Note: There has been some discussion whether the RTP payload type
field in this message is needed. It will be needed if there is
potentially more than one VBCM-capable RTP payload type in the same
session, and the semantics of a given VBCM changes between payload
types. For example, the picture identification mechanism in
messages of H.271 type 0 is fundamentally different between H.263
and H.264 (although both use the same syntax). Therefore, the
payload field is justified here. There was a further comment that
for TSTR and FIR such a need does not exist, because the semantics
of TSTR and FIR are either loosely enough defined, or generic
enough, to apply to all video payloads currently in
existence/envisioned.
以下に注意してください。 このメッセージのRTPペイロードタイプ分野が必要であるか否かに関係なく、何らかの議論がありました。 同じセッションに1つ以上のVBCM有能なRTPペイロードタイプが潜在的にあると、それが必要でしょう、そして、与えられたVBCMの意味論はペイロードタイプの間で変化します。 例えば、H.271タイプ0に関するメッセージの絵の識別メカニズムはH.263とH.264の間で基本的に異なっています(両方が同じ構文を使用しますが)。 したがって、ペイロード分野はここで正当化されます。 TSTRとFIRに関して、そのような必要性が存在していないというさらなるコメントがありました、TSTRとFIRの意味論が現在現存するすべてのビデオペイロードに思い描かれた/は適用できるくらい十分緩く定義されているか、または一般的であるので。
5. Congestion Control
5. 輻輳制御
The correct application of the AVPF [RFC4585] timing rules prevents the network from being flooded by feedback messages. Hence, assuming a correct implementation and configuration, the RTCP channel cannot break its bit rate commitment and introduce congestion.
AVPF[RFC4585]タイミング規則の正しい適用は水につかるのからのフィードバックメッセージによるネットワークを防ぎます。 したがって、正しい実現と構成を仮定する場合、RTCPチャンネルは、ビット伝送速度委任を破って、混雑を導入できません。
The reception of some of the feedback messages modifies the behaviour of the media senders or, more specifically, the media encoders.
フィードバックメッセージのいくつかのレセプションはメディア送付者か、より明確にメディアエンコーダのふるまいを変更します。
Wenger, et al. Standards Track [Page 52] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[52ページ]。
Thus, modified behaviour MUST respect the bandwidth limits that the application of congestion control provides. For example, when a media sender is reacting to a FIR, the unusually high number of packets that form the decoder refresh point have to be paced in compliance with the congestion control algorithm, even if the user experience suffers from a slowly transmitted decoder refresh point.
したがって、変更されたふるまいは輻輳制御の応用が提供する帯域幅限界を尊敬しなければなりません。 メディア送付者が反応しているとき、例えば、FIR、異常に大きい数のパケットに、デコーダがリフレッシュするフォームが指すのは輻輳制御アルゴリズムに従って歩調を合わせられなければなりません、経験がゆっくり伝えられたデコーダから受けるユーザがポイントをリフレッシュしても。
A change of the Temporary Maximum Media Stream Bit Rate value can only mitigate congestion, but not cause congestion as long as congestion control is also employed. An increase of the value by a request REQUIRES the media sender to use congestion control when increasing its transmission rate to that value. A reduction of the value results in a reduced transmission bit rate, thus reducing the risk for congestion.
また、輻輳制御が使われる限り、Temporary MaximumメディアStream Bit Rate価値の変化は原因混雑ではなく、混雑を緩和できるだけです。 その値に通信速度を増加させるとき輻輳制御を使用するメディア送付者の要求REQUIRESによる価値の増加。 価値の減少は減少しているトランスミッションビット伝送速度をもたらして、その結果、混雑のために危険を減少させます。
6. Security Considerations
6. セキュリティ問題
The defined messages have certain properties that have security implications. These must be addressed and taken into account by users of this protocol.
定義されたメッセージには、セキュリティ意味を持っているある特性があります。 このプロトコルのユーザは、これらを記述されて、考慮に入れなければなりません。
The defined setup signaling mechanism is sensitive to modification attacks that can result in session creation with sub-optimal configuration, and, in the worst case, session rejection. To prevent this type of attack, authentication and integrity protection of the setup signaling is required.
定義されたセットアップシグナル伝達機構はサブ最適の構成でセッション創造をもたらすことができる変更攻撃、および最悪の場合にはセッション拒絶に敏感です。 セットアップのこのタイプの攻撃、認証、および保全保護が合図するのを防ぐのが必要です。
Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:
この仕様に基づき定義されたタイプのだまされたか、または陰湿に作成されたフィードバックメッセージは以下の意味を持つことができます:
a. severely reduced media bit rate due to false TMMBR messages
that sets the maximum to a very low value;
a. 誤ったTMMBRメッセージによる非常に低い値に最大を設定する厳しく減少しているメディアビット伝送速度。
b. assignment of the ownership of a bounding tuple to the wrong
participant within a TMMBN message, potentially causing
unnecessary oscillation in the bounding set as the mistakenly
identified owner reports a change in its tuple and the true
owner possibly holds back on changes until a correct TMMBN
message reaches the participants;
b. TMMBNメッセージの中の間違った関係者への制限tupleの所有権の課題、誤って特定された所有者がtupleと真正な持ち主における変化を報告するので、制限セットで潜在的に不要な振動を引き起こすと、正しいTMMBNメッセージが関係者に届くまで、変化はことによると差し控えられます。
c. sending TSTRs that result in a video quality different from
the user's desire, rendering the session less useful;
c. ユーザの願望と異なったビデオ画質をもたらして、セッションをより役に立たないようにしてください、それをTSTRsに送ります。
d. sending multiple FIR commands to reduce the frame rate, and
make the video jerky, due to the frequent usage of decoder
refresh points.
d. フレームレートを低下させて、デコーダの頻繁な使用法への痙攣的で、当然のビデオにポイントをリフレッシュさせる複数のFIRコマンドを送ります。
Wenger, et al. Standards Track [Page 53] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[53ページ]。
To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP [SRTP] and AVPF into SAVPF [SAVPF]. In the mixer cases, separate security contexts and filtering can be applied between the mixer and the participants, thus protecting other users on the mixer from a misbehaving participant.
これらの攻撃を防ぐために、フィードバックメッセージの認証と保全保護を適用する必要があります。 Secure RTP[SRTP]とAVPFをSAVPF[SAVPF]に結合するRTPプロフィールを使用することで現在のRTPセッションへの外部の脅威に対してこれを達成できます。 ミキサー場合では、ミキサーと関係者の間で別々のセキュリティ関係とフィルタリングを適用できます、その結果、ミキサーの上にふらちな事をしている関係者から他のユーザを保護します。
7. SDP Definitions
7. SDP定義
Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp- fb, that may be used to negotiate the capability to handle specific AVPF commands and indications, such as Reference Picture Selection, Picture Loss Indication, etc. The ABNF for rtcp-fb is described in section 4.2 of [RFC4585]. In this section, we extend the rtcp-fb attribute to include the commands and indications that are described for codec control in the present document. We also discuss the Offer/Answer implications for the codec control commands and indications.
[RFC4585]のセクション4は新しいSDP[RFC4566]属性、特定のAVPFコマンドと指摘を扱う能力を交渉するのに使用されるかもしれないrtcp- fbを定義します、Reference Picture Selection、Picture Loss Indicationなどのように rtcp-fbのためのABNFは[RFC4585]のセクション4.2で説明されます。 このセクションでは、私たちは、現在のドキュメントにおけるコーデックコントロールのために説明されるコマンドと指摘を含むようにrtcp-fb属性を広げます。 また、私たちはコーデック制御コマンドと指摘のためにOffer/答え含意について議論します。
7.1. Extension of the rtcp-fb Attribute
7.1. rtcp-fb Attributeの拡大
As described in AVPF [RFC4585], the rtcp-fb attribute indicates the capability of using RTCP feedback. AVPF specifies that the rtcp-fb attribute must only be used as a media level attribute and must not be provided at session level. All the rules described in [RFC4585] for rtcp-fb attribute relating to payload type and to multiple rtcp- fb attributes in a session description also apply to the new feedback messages defined in this memo.
AVPF[RFC4585]で説明されるように、rtcp-fb属性はRTCPフィードバックを使用する能力を示します。 AVPFは、メディアレベルを結果と考えて、セッションレベルで提供してはいけないときrtcp-fb属性を使用するだけでよいと指定します。 また、rtcp-fb属性関係のためのペイロードタイプと、そして、複数のrtcp- fb属性へのセッション記述における[RFC4585]で説明されたすべての規則がこのメモで定義された新しいフィードバックメッセージに適用されます。
The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is
[RFC4585]で定義されるrtcp-fbのためのABNF[RFC4234]はそうです。
"a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
「a=rtcp-fb:」 「rtcp-fb-Pt SP rtcp-fb-val CRLF」
where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type of the feedback message such as ack, nack, trr-int, and rtcp-fb-id. For example, to indicate the support of feedback of Picture Loss Indication, the sender declares the following in SDP
rtcp-fb-Ptがペイロードであるところでは、タイプしてください。そうすれば、rtcp-fb-valはackや、nackや、trr-intや、rtcp-fb-イドなどのフィードバックメッセージのタイプを定義します。 例えば、Picture Loss Indicationのフィードバックのサポートを示すために、送付者はSDPで以下を宣言します。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli
IN IP4 host.example.com m=オーディオの49170RTP/AVPF98フィードバックt=0 0cがあるv=0 o=alice3203093520 3203093520IN IP4 host.example.com s=メディア=a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98nack pli
Wenger, et al. Standards Track [Page 54] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[54ページ]。
In this document, we define a new feedback value "ccm", which indicates the support of codec control using RTCP feedback messages. The "ccm" feedback value SHOULD be used with parameters that indicate the specific codec control commands supported. In this document, we define four such parameters, namely:
本書では、私たちは新しいフィードバック値の「立方センチメートル」を定義します。(それは、RTCPフィードバックメッセージを使用することでコーデックコントロールのサポートを示します)。 「立方センチメートル」フィードバックはSHOULDを評価します。制御コマンドが支持した特定のコーデックを示すパラメタと共に使用されてください。 本書では、私たちがそのような4つのパラメタを定義する、すなわち:
o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub-parameter to indicate the session maximum packet
rate (measured in packets per second) to be used. If not
included, this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN).
o "vbcm" indicates support of H.271 Video Back Channel Messages
(VBCMs). It has zero or more subparameters identifying the
supported H.271 "payloadType" values.
o 「モミ」はFull Intra Request(FIR)のサポートを示します。o"tmmbr"はTemporary MaximumメディアStream Bit Rate Request/通知(TMMBR/TMMBN)のサポートを示します。 それには、使用されるために、セッションの最大のパケット率(1秒あたりのパケットでは、測定される)を示す任意のサブパラメタがあります。 含まれていないなら、これは無限でデフォルトとします。o"tstr"はTemporal空間的な下にTrade Request/通知(TSTR/TSTN)のサポートを示します。o"vbcm"はH.271 Video Back Channel Messages(VBCMs)のサポートを示します。 それで、ゼロか、より多くの「副-パラメタ」が支持されたH.271"payloadType"値を特定します。
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a placeholder called rtcp-fb-id to define new feedback types. "ccm" is defined as a new feedback type in this document, and the ABNF for the parameters for ccm is defined here (please refer to section 4.2 of [RFC4585] for complete ABNF syntax).
[RFC4585]で定義されたrtcp-fb-valのためのABNFに、新しいフィードバックタイプを定義するためにrtcp-fb-イドと呼ばれるプレースホルダがあります。 「立方センチメートル」は本書では新しいフィードバックタイプと定義されます、そして、立方センチメートルのためのパラメタのためのABNFはここで定義されます(完全なABNF構文について[RFC4585]のセクション4.2を参照してください)。
rtcp-fb-val =/ "ccm" rtcp-fb-ccm-param
rtcp-fb-val=/「立方センチメートル」rtcp-fb立方センチメートルparam
rtcp-fb-ccm-param = SP "fir" ; Full Intra Request
/ SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate
/ SP "tstr" ; Temporal-Spatial Trade-Off
/ SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
/ SP token [SP byte-string]
; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT
rtcp-fb立方センチメートルparamはSP「モミ」と等しいです。 完全なイントラ要求/SP"tmmbr"[SP「smaxpr=」MaxPacketRateValue]。 一時的な最大メディアSPビット伝送速度/"tstr"。 時、空間的なSPトレードオフ/"vbcm"*(SP subMessageType)。 H.271 VBCMs / SP象徴[SPバイトストリング]。 [RFC4585]>MaxPacketRateValue=1*15DIGITのセクション4.2で定義される将来の指摘subMessageType=1*8DIGITバイトコマンド/ストリング=<のために
7.2. Offer-Answer
7.2. 申し出答え
The Offer/Answer [RFC3264] implications for codec control protocol feedback messages are similar to those described in [RFC4585]. The offerer MAY indicate the capability to support selected codec commands and indications. The answerer MUST remove all CCM parameters corresponding to the CCMs that it does not wish to support in this particular media session (for example, because it does not implement the message in question, or because its application logic suggests that support of the message adds no value). The answerer MUST NOT add new ccm parameters in addition to what has been offered.
コーデック制御プロトコルフィードバックメッセージのためのOffer/答え[RFC3264]含意は[RFC4585]で説明されたものと同様です。 申出人は選択されたコーデックコマンドと指摘をサポートする能力を示すかもしれません。 answererはそれがこの特定のメディアセッションのときに支持したがっていないCCMsに対応するすべてのCCMパラメタを取り除かなければなりません(例えば問題のメッセージを実行しないか、またはアプリケーション論理が、メッセージのサポートが価値を全く高めないのを示すので)。 answererは提供されたものに加えた新しい立方センチメートルパラメタを加えてはいけません。
Wenger, et al. Standards Track [Page 55] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[55ページ]。
The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used.
答えはメディアセッションのために拘束力があります、そして、申出人とanswererの両方が両側が支持されるとして明らかに示したこと以外のどんなフィードバックメッセージも使用してはいけません。 言い換えれば、申し出と答えからのCCMパラメタの共同部分集合だけを使用してもよいです。
Note that including a CCM parameter in an offer or answer indicates that the party (offerer or answerer) is at least capable of receiving the corresponding CCM(s) and act upon them. In cases when the reception of a negotiated CCM mandates the party to respond with another CCM, it must also have that capability. Although it is not mandated to initiate CCMs of any negotiated type, it is generally expected that a party will initiate CCMs when appropriate.
申し出か答えにCCMパラメタを含んでいるのが、パーティー(申出人かanswerer)が対応するCCM(s)と行為を彼らに少なくとも受け取ることができるのを示すことに注意してください。 交渉されたCCM命令のレセプションであることの場合では、別のCCMと共に反応させるパーティーであり、また、それはその能力を持たなければなりません。 それはどんな交渉されたタイプのCCMsも開始するために強制されませんが、一般に、適切であるときに、パーティーがCCMsを開始すると予想されます。
The session maximum packet rate parameter part of the TMMBR indication is declarative, and the highest value from offer and answer SHALL be used. If the session maximum packet rate parameter is not present in an offer, it SHALL NOT be included by the answerer.
TMMBR指示のセッション最大のパケットレートパラメタ部分は、叙述的であって、最も高い値です。申し出と答えSHALLから、使用されます。 レートパラメタはセッションの最大のパケットであるなら申し出で存在していなくて、それはSHALL NOTです。answererによって含まれています。
7.3. Examples
7.3. 例
Example 1: The following SDP describes a point-to-point video call with H.263, with the originator of the call declaring its capability to support the FIR and TSTR/TSTN codec control messages. The SDP is carried in a high-level signaling protocol like SIP.
例1: 以下のSDPはH.263との二地点間ビデオ通話について説明します、呼び出しの創始者が、FIRを支持する能力とTSTR/TSTNコーデックコントロールがメッセージであると宣言していて。 SDPはSIPのようなハイレベルのシグナリングプロトコルで運ばれます。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
ポイントからポイントへのv=0 o=alice3203093520 3203093520IN IP4 host.example.com s=呼び出しcがIN IP4と等しい、192.0、.2、.124m、=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ51372RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルtstr a=rtcp-fb: 98立方センチメートルモミと等しいです。
In the above example, when the sender receives a TSTR message from the remote party it is capable of adjusting the trade-off as indicated in the RTCP TSTN feedback message.
送付者がリモートパーティーからTSTRメッセージを受け取るとき、上記の例では、それはRTCP TSTNフィードバックメッセージにみられるようにトレードオフを調整できます。
Example 2: The following SDP describes a SIP end point joining a video mixer that is hosting a multiparty video conferencing session. The participant supports only the FIR (Full Intra Request) codec control command and it declares it in its session description.
例2: 以下のSDPは「マルチ-パーティー」ビデオ会議セッションを主催しているビデオミキサーを接合するSIPエンドポイントについて説明します。 関係者はFIR(完全なIntra Request)コーデック制御コマンドだけをサポートします、そして、それはセッション記述でそれを宣言します。
Wenger, et al. Standards Track [Page 56] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[56ページ]。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir
v=0 o=alice3203093520 3203093520IN IP4 host.example.com s=Multiparty Video Call cがIN IP4と等しい、192.0、.2、.124m、=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ51372RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルモミと等しいです。
When the video MCU decides to route the video of this participant, it sends an RTCP FIR feedback message. Upon receiving this feedback message, the end point is required to generate a full intra request.
ビデオMCUが、この関係者のビデオを発送すると決めると、それはRTCP FIRフィードバックメッセージを送ります。 このフィードバックメッセージを受け取ると、エンドポイントが、完全なイントラ要求を発生させるのに必要です。
Example 3: The following example describes the Offer/Answer implications for the codec control messages. The offerer wishes to support "tstr", "fir" and "tmmbr". The offered SDP is
例3: 以下の例はコーデックコントロールメッセージのためにOffer/答え含意について説明します。 申出人は"tstr"、「モミ」、および"tmmbr"を支持したがっています。 提供されたSDPはそうです。
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
-------------申し出/答え>申し出v=0 o=alice3203093520 3203093520IN IP4 host.example.com s=cがIN IP4と等しい、192.0、.2、.124m、=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ51372RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルtstr a=rtcp-fb: 98立方センチメートルモミa=rtcp-fbと等しいです: *立方センチメートルtmmbr smaxpr=120
The answerer wishes to support only the FIR and TSTR/TSTN messages and the answerer SDP is
answererはFIRとTSTR/TSTNメッセージだけを支持したがっています、そして、answerer SDPは支持です。
<---------------- Answer
<。---------------- 答え
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
v=0 o=alice3203093520 3203093524IN IP4 otherhost.example.com s=申し出/答えcがIN IP4と等しい、192.0、.2、.37m、=オーディオの47190RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ53273RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルtstr a=rtcp-fb: 98立方センチメートルモミと等しいです。
Wenger, et al. Standards Track [Page 57] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[57ページ]。
Example 4: The following example describes the Offer/Answer implications for H.271 Video Back Channel Messages (VBCMs). The offerer wishes to support VBCM and the sub-messages of payloadType 1 (one or more pictures that are entirely or partially lost) and 2 (a set of blocks of one picture that are entirely or partially lost).
例4: 以下の例はH.271 Video Back Channel Messages(VBCMs)のためにOffer/答え含意について説明します。 申出人はVBCMとpayloadType1(完全か部分的に失われている1枚以上の絵)と2(完全か部分的に失われている1枚の絵のブロックのセット)に関するサブメッセージを支持したがっています。
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2
-------------申し出/答え>申し出v=0 o=alice3203093520 3203093520IN IP4 host.example.com s=cがIN IP4と等しい、192.0、.2、.124m、=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ51372RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルvbcm1 2と等しいです。
The answerer only wishes to support sub-messages of type 1 only
answererはタイプ1だけに関するサブメッセージを支持するだけでありたいです。
<---------------- Answer
<。---------------- 答え
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1
v=0 o=alice3203093520 3203093524IN IP4 otherhost.example.com s=申し出/答えcがIN IP4と等しい、192.0、.2、.37m、=オーディオの47190RTP/AVP0a=rtpmap: 0PCMU/8000mはビデオ53273RTP/AVPF98a=rtpmap: 98H263-1998/90000 a=rtcp-fb: 98立方センチメートルvbcm1と等しいです。
So, in the above example, only VBCM indications comprised of "payloadType" 1 will be supported.
それで、上記の例では、"payloadType"1から成るVBCM指摘だけが支持されるでしょう。
8. IANA Considerations
8. IANA問題
The new value "ccm" has been registered with IANA in the "rtcp-fb" Attribute Values registry located at the time of publication at: http://www.iana.org/assignments/sdp-parameters
"rtcp-fb"Attribute Values登録に以下に新しい値の「立方センチメートル」を公表時点で見つけられた状態でIANAに登録してあります。 http://www.iana.org/assignments/sdp-parameters
Value name: ccm
Long Name: Codec Control Commands and Indications
Reference: RFC 5104
名前を評価してください: 立方センチメートルLong Name: コーデック制御コマンドと指摘参照: RFC5104
A new registry "Codec Control Messages" has been created to hold "ccm" parameters located at time of publication at: http://www.iana.org/assignments/sdp-parameters
以下で「立方センチメートル」パラメタが公表の時に見つけられているままにするために新しい登録「コーデックコントロールメッセージ」を作成してあります。 http://www.iana.org/assignments/sdp-parameters
Wenger, et al. Standards Track [Page 58] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[58ページ]。
New registration in this registry follows the "Specification required" policy as defined by [RFC2434]. In addition, they are required to indicate any additional RTCP feedback types, such as "nack" and "ack".
[RFC2434]によって定義されるようにこの登録の新規登録は「仕様が必要である」という方針に従います。 さらに、彼らは"nack"や"ack"などのどんな追加RTCPフィードバックタイプも示さなければなりません。
The initial content of the registry is the following values:
登録の初期の内容は以下の値です:
Value name: fir
Long name: Full Intra Request Command
Usable with: ccm
Reference: RFC 5104
名前を評価してください: モミLongは以下を命名します。 以下がある完全なIntra Request Command Usable 立方センチメートルReference: RFC5104
Value name: tmmbr
Long name: Temporary Maximum Media Stream Bit Rate
Usable with: ccm
Reference: RFC 5104
名前を評価してください: tmmbr Longは以下を命名します。 以下がある一時的なMaximumメディアStream Bit Rate Usable 立方センチメートルReference: RFC5104
Value name: tstr
Long name: Temporal Spatial Trade Off
Usable with: ccm
Reference: RFC 5104
名前を評価してください: tstr Longは以下を命名します。 以下がある時のSpatial Trade Off Usable 立方センチメートルReference: RFC5104
Value name: vbcm
Long name: H.271 video back channel messages
Usable with: ccm
Reference: RFC 5104
名前を評価してください: vbcm Longは以下を命名します。 以下があるH.271のビデオの戻っているチャンネルメッセージUsable 立方センチメートルReference: RFC5104
The following values have been registered as FMT values in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/rtp-parameters
以下の値はFMT値として公表時点で見つけられた「RTPFB有効搭載量タイプのためのFMT値」登録に以下に示されました。 http://www.iana.org/assignments/rtp-parameters
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved 2 [RFC5104]
TMMBR Temporary Maximum Media Stream Bit 3 [RFC5104]
Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFC5104]
Rate Notification
RTPFB範囲Name Long Name Value Reference-------------- --------------------------------- ----- --------- 予約された2[RFC5104]の一時的な最大のメディア流れのビット3TMMBR[RFC5104]は、要求のTMMBNの一時的な最大のメディアが流れのビット4[RFC5104]レート通知書であると評定します。
The following values have been registered as FMT values in the "FMT Values for PSFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/rtp-parameters
以下の値はFMT値として公表時点で見つけられた「PSFB有効搭載量タイプのためのFMT値」登録に以下に示されました。 http://www.iana.org/assignments/rtp-parameters
Wenger, et al. Standards Track [Page 59] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[59ページ]。
PSFB range Name Long Name Value Reference -------------- --------------------------------- ----- --------- FIR Full Intra Request Command 4 [RFC5104] TSTR Temporal-Spatial Trade-off Request 5 [RFC5104] TSTN Temporal-Spatial Trade-off Notification 6 [RFC5104] VBCM Video Back Channel Message 7 [RFC5104]
PSFB範囲Name Long Name Value Reference-------------- --------------------------------- ----- --------- モミの完全なイントラ要求命令4[RFC5104]のTSTRの時、空間的なトレードオフ要求5[RFC5104]のTSTNの時、空間的なトレードオフ通知6[RFC5104]のVBCMのビデオの逆チャンネルメッセージ7[RFC5104]
9. Contributors
9. 貢献者
Tom Taylor has made a very significant contribution to this specification, for which the authors are very grateful, by helping rewrite the specification. Especially the parts regarding the algorithm for determining bounding sets for TMMBR have benefited.
トム・テイラーは作者が非常に感謝しているこの仕様への非常に重要な貢献をしました、仕様を書き直すのを助けることによって。 特に制限がTMMBRのためにセットすることを決定するためのアルゴリズムに関する部品は利益を得ました。
10. Acknowledgements
10. 承認
The authors would like to thank Andrea Basso, Orit Levin, and Nermeen Ismail for their work on the requirement and discussion document [Basso].
作者は要件と議論ドキュメント[低音部]への彼らの作業についてアンドレアBasso、Oritレヴィン、およびNermeenイスマイルに感謝したがっています。
Versions of this memo were reviewed and extensively commented on by Roni Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Guido Franceschini, and others. The authors appreciate these reviews.
このメモのバージョンは、見直されて、ロニEven、コリン・パーキンス、ランデルJesup、キース・ランツ、Harikishan Desineni、グイド・フランチェスキーニ、および他のものによって手広く批評されました。 作者はこれらのレビューを鑑賞します。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
Rey, "Extended RTP Profile for Real-Time Transport
Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC
4585, July 2006.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、バーマイスター、C.、およびJ.レイは「リアルタイムの輸送制御プロトコル(RTCP)ベースのフィードバック(RTP/AVPF)のためにRTPプロフィールを広げました」、RFC4585、2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Wenger, et al. Standards Track [Page 60] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[60ページ]。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
11.2. Informative References
11.2. 有益な参照
[Basso] Basso, A., Levin, O., and N. Ismail, "Requirements for
transport of video control commands", Work in Progress,
October 2004.
[低音部]低音部、A.、レヴィン、O.、およびN.イスマイル、「ビデオ制御コマンドの輸送のための要件」、Progress、2004年10月のWork。
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T
Recommendation and Final Draft International Standard of
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and
ITU-T VCEG, JVT-G050, March 2003.
共同ビデオ仕様のITU-Tの[AVC]共同ビデオチーム、ISO/IEC JTC1、草稿ITU-T推薦、および最終的な国際規格案(ITU-T Rec。 H.264| ISO/IEC14496-10AVC), 2003年3月のISO/IEC MPEGとITU-T VCEG、JVT-G050の共同ビデオチーム(JVT)。
[H245] ITU-T Rec. H.245, "Control protocol for multimedia
communication", May 2006.
[H245]ITU-T Rec。 H.245、「マルチメディア通信のための制御プロトコル」、2006年5月。
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient
Video Coding by Dynamic Replacing of Reference Pictures",
in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996.
ProcのS.Fukunaga、[NEWPRED]T.中井とH.井上、「参照の絵のダイナミックな取り替えによる誤りの立ち直りの早いビデオ符号化。」 Globcom96年、vol.3、ページ 1503 - 1508, 1996.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[SRTP] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for
H.261 Video Streams", RFC 2032, October 1996.
[RFC2032] TurlettiとT.とC.Huitema、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
[SAVPF] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", Work in Progress,
November 2007.
[SAVPF] 「拡張安全なRTPはRTCPベースのフィードバックのために(RTP/SAVPF)の輪郭を描く」というオット、J.、およびE.カラーラは進歩、2007年11月に働いています。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June
2003.
[RFC3525] 木立とC.とPantaleoとM.とアンダーソン、T.とT.テイラー、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、2003年6月。」
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[H.271] ITU-T Rec. H.271, "Video Back Channel Messages", June
2006.
[H.271]ITU-T Rec。 H.271、「ビデオの逆チャンネルメッセージ」、2006年6月。
Wenger, et al. Standards Track [Page 61] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[61ページ]。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", RFC
3890, September 2004.
[RFC3890] Westerlund、M.、「セッション記述プロトコル(SDP)のための輸送の独立している帯域幅修飾語」、RFC3890、2004年9月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC2198] 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.
[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006.
[RFC4587]、同等である、R.、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC4587、8月2006日
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5117]WesterlundとM.とS.ウェンガー、「RTP Topologies」、RFC5117 2008年1月。
[XML-MC] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", Work in Progress, November 2007.
[XML-M.C.]レヴィン、R.、P.Hagendorf、「メディアのためのXML図式は制御すること」が進歩、2007年11月に扱いさえするO.。
Wenger, et al. Standards Track [Page 62] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[62ページ]。
Authors' Addresses
作者のアドレス
Stephan Wenger Nokia Corporation 975, Page Mill Road, Palo Alto,CA 94304 USA
シュテファンウェンガーノキア社975、ページ工場道路、パロアルト、カリフォルニア94304米国
Phone: +1-650-862-7368 EMail: stewe@stewe.org
以下に電話をしてください。 +1-650-862-7368 メールしてください: stewe@stewe.org
Umesh Chandra Nokia Research Center 975, Page Mill Road, Palo Alto,CA 94304 USA
Umeshチャンドラノキアリサーチセンター975、ページ工場道路、パロアルト、カリフォルニア94304米国
Phone: +1-650-796-7502 Email: Umesh.1.Chandra@nokia.com
以下に電話をしてください。 +1-650-796-7502 メールしてください: Umesh.1.Chandra@nokia.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
マグヌスWesterlundエリクソン研究エリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 7190000 EMail: magnus.westerlund@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: magnus.westerlund@ericsson.com
Bo Burman Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
ボー・ビルマのエリクソン研究エリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 7190000 EMail: bo.burman@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: bo.burman@ericsson.com
Wenger, et al. Standards Track [Page 63] RFC 5104 Codec Control Messages in AVPF February 2008
ウェンガー、他 規格は2008年2月にAVPFのRFC5104コーデックコントロールメッセージを追跡します[63ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Wenger, et al. Standards Track [Page 64]
ウェンガー、他 標準化過程[64ページ]
一覧
スポンサーリンク
