Internet Engineering Task Force (IETF)                            J. Ott
Request for Comments: 5760                              Aalto University
Category: Standards Track                                J. Chesterfield
ISSN: 2070-1721                                  University of Cambridge
                                                             E. Schooler
                                                                   Intel
                                                           February 2010
        
               RTP Control Protocol (RTCP) Extensions for
         Single-Source Multicast Sessions with Unicast Feedback
        

Abstract

抽象

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism.

この文書では、マルチキャスト送信元にユニキャストフィードバックを使用するようにリアルタイムトランスポート制御プロトコル(RTCP)に拡張子を指定します。提案された拡張は、多対多のグループ通信の伝統的なモデルが利用可能かどうかの所望のいずれかではないソース固有マルチキャスト(SSM)通信としてシングルソースマルチキャストセッションのために有用です。また、送信者制御の要約レポートメカニズムから恩恵を受ける可能性のあるすべてのグループに適用することができます。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5760.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5760で取得することができます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Conventions and Acronyms ........................................4
   3. Definitions .....................................................5
   4. Basic Operation .................................................6
   5. Packet Types ...................................................10
   6. Simple Feedback Model ..........................................11
   7. Distribution Source Feedback Summary Model .....................13
   8. Mixer/Translator Issues ........................................36
   9. Transmission Interval Calculation ..............................37
   10. SDP Extensions ................................................39
   11. Security Considerations .......................................41
   12. Backwards Compatibility .......................................51
   13. IANA Considerations ...........................................51
   14. References ....................................................53
   Appendix A. Examples for Sender-Side Configurations ...............57
   Appendix B. Distribution Report Processing at the Receiver ........60
        
1. Introduction
1. はじめに

The Real-time Transport Protocol (RTP) [1] provides a real-time transport mechanism suitable for unicast or multicast communication between multimedia applications. Typical uses of RTP are for real-time or near real-time group communication of audio and video data streams. An important component of the RTP protocol is the control channel, defined as the RTP Control Protocol (RTCP). RTCP involves the periodic transmission of control packets between group members, enabling group size estimation and the distribution and calculation of session-specific information such as packet loss and round-trip time to other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic to establish network conditions and to diagnose faults based on receiver locations.

リアルタイムトランスポートプロトコル(RTP)[1]マルチメディア・アプリケーションとの間のユニキャストまたはマルチキャスト通信に適したリアルタイム・トランスポート機構を提供します。 RTPの典型的な用途は、リアルタイムまたはオーディオおよびビデオデータストリームのリアルタイムなグループ通信の近くにあります。 RTPプロトコルの重要な構成要素は、RTP制御プロトコル(RTCP)として定義される制御チャネルです。 RTCPは、グループサイズ推定およびそのような他のホストにパケット損失と往復時間などのセッション固有の情報の分布および計算を可能にする、グループメンバ間の制御パケットの周期的送信を含みます。セッションのための制御チャネルを提供するという付加的な利点は、サードパーティのセッションモニタは、ネットワークの状態を確立し、受信機の位置に基づいて障害を診断するために、トラフィックを聞くことができるということです。

RTP was designed to operate in either a unicast or multicast mode. In multicast mode, it assumes an Any Source Multicast (ASM) group model, where both one-to-many and many-to-many communication are supported via a common group address in the range 224.0.0.0 through 239.255.255.255. To enable Internet-wide multicast communication, intra-domain routing protocols (those that operate only within a single administrative domain, e.g., the Distance Vector Multicast Routing Protocol (DVMRP) [16] and Protocol Independent Multicast (PIM) [17][18]) are used in combination with inter-domain routing protocols (those that operate across administrative domain borders, e.g., Multicast BGP (MBGP) [19] and the Multicast Source Discovery Protocol (MSDP) [20]). Such routing protocols enable a host to join a single multicast group address and send data to or receive data from all members in the group with no prior knowledge of the membership. However, there is a great deal of complexity involved at the routing level to support such a multicast service in the network.

RTPは、ユニキャストまたはマルチキャストモードのいずれかで動作するように設計されました。マルチキャストモードでは、両方の一対多および多対多の通信が239.255.255.255までの範囲の224.0.0.0に共通のグループアドレスを介して支持されている任意のソースマルチキャスト(ASM)グループのモデルを想定しています。インターネット規模のマルチキャスト通信、ドメイン内ルーティングプロトコル(単一の管理ドメイン内で動作するものを有効にするには、例えば、距離ベクトルマルチキャストルーティングプロトコル(DVMRP)[16]及びプロトコル独立マルチキャスト(PIM)[17] [18 ])は、ドメイン間ルーティングプロトコルと組み合わせて使用​​される(管理ドメイン境界を横切って動作するもの、例えば、マルチキャストBGP(MBGP)[19]とマルチキャストソース発見プロトコル(MSDP)[20])。そのようなルーティングプロトコルは、単一のマルチキャストグループアドレスに参加し、会員の事前知識をグループ内のすべてのメンバーからのデータにデータを送受信するホストを可能にします。しかし、ネットワークに、このようなマルチキャストサービスをサポートするために、ルーティングレベルで関与複雑さを大いにあります。

Many-to-many communication is not always available or desired by all group applications. For example, with Source-Specific Multicast (SSM) [8][9] and satellite communication, the multicast distribution channel only supports source-to-receiver traffic. In other cases, such as large ASM groups with a single active data source and many passive receivers, it is sub-optimal to create a full routing-level mesh of multicast sources just for the distribution of RTCP control packets. Thus, an alternative solution is preferable.

多対多通信が利用可能であるか、またはすべてのグループアプリケーションによって希望常にではありません。例えば、ソース固有マルチキャスト(SSM)と[8] [9]、衛星通信、マルチキャスト配信チャネルは、ソースから受信トラフィックをサポートします。そのような単一のアクティブなデータ・ソースと多くのパッシブ受信機と大ASM基のような他のケースでは、それだけRTCP制御パケットの配信のためにマルチキャストソースの完全なルーティングレベルのメッシュを作成するために、準最適です。従って、別の解決策が好ましいです。

Although a one-to-many multicast topology may simplify routing and may be a closer approximation to the requirements of certain RTP applications, unidirectional communication makes it impossible for receivers in the group to share RTCP feedback information with other group members. In this document, we specify a solution to that problem. We introduce unicast feedback as a new method to distribute

一対多マルチキャストトポロジは、ルーティングを単純化することができ、特定のRTPアプリケーションの要件に近い近似値であってもよいが、単方向通信は不可能グループ内の受信機は、他のグループメンバーとRTCPフィードバック情報を共有することができます。この文書では、我々はその問題の解決策を指定します。私たちは、配布するための新しい方法として、ユニキャストフィードバックを導入します

RTCP control information amongst all session members. This method is designed to operate under any group communication model, ASM or SSM. The RTP data stream protocol itself is unaltered.

RTCPすべてのセッションメンバー間で情報を制御します。この方法は、任意のグループ通信モデル、ASMまたはSSMの下で動作するように設計されています。 RTPデータストリームプロトコル自体は不変です。

Scenarios under which the unicast feedback method can provide benefit include but are not limited to:

ユニキャストフィードバック方法が利点を提供することができる下のシナリオが含まれるがこれらに限定されません。

a) SSM groups with a single sender.

a)は、単一の送信者とSSMグループ。

The proposed extensions allow SSM groups that do not have many-to-many communication capability to receive RTP data streams and to continue to participate in the RTP control protocol (RTCP) by using multicast in the source-to-receiver direction and unicast to send receiver feedback to the source on the standard RTCP port.

提案された拡張機能は、SSMグループはRTPデータストリームを受信し、送信するためにソース - 受信方向及びユニキャスト、マルチキャストを使用して、RTP制御プロトコル(RTCP)に参加し続けること多対多の通信能力を持たない可能標準RTCPポート上のソースにフィードバックを受信機。

b) One-to-many broadcast networks.

b)は一対多ブロードキャストネットワーク。

Unicast feedback may also be beneficial to one-to-many broadcast networks, such as a satellite network with a terrestrial low-bandwidth return channel or a broadband cable link. Unlike the SSM network, these networks may have the ability for a receiver to multicast return data to the group. However, a unicast feedback mechanism may be preferable for routing simplicity.

ユニキャストフィードバックはまた、地上の低帯域幅リターンチャネルまたはブロードバンド・ケーブル・リンクを有する衛星ネットワークのような一対多ブロードキャストネットワーク、に有益であり得ます。 SSMネットワークとは異なり、これらのネットワークは、グループへのマルチキャスト戻りデータに対して受信機の能力を有していてもよいです。しかしながら、ユニキャストフィードバック機構は、簡単にルーティングすることが好ましいかもしれません。

c) ASM with a single sender.

単一の送信者とc)のASM。

A unicast feedback approach can be used by an ASM application with a single sender to reduce the load on the multicast routing infrastructure that does not scale as efficiently as unicast routing does. Because this is no more efficient than a standard multicast group RTP communication scenario, it is not expected to replace the traditional mechanism.

ユニキャストフィードバックアプローチは、同じ効率でユニキャストルーティングを行うようにスケールしないマルチキャストルーティングインフラの負荷を軽減するために、単一の送信者とASMアプリケーションで使用することができます。これは、標準のマルチキャストグループのRTP通信のシナリオよりも、より効率的ではありませんので、伝統的なメカニズムを交換することが期待されていません。

The modifications proposed in this document are intended to supplement the existing RTCP feedback mechanisms described in Section 6 of [1].

この文書で提案されている修飾は、[1]のセクション6に記載既存のRTCPフィードバックメカニズムを補完することを意図しています。

2. Conventions and Acronyms
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 [13].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [13]に記載されているように解釈されます。

The following acronyms are used throughout this document:

以下の頭字語は、本書で使用されています。

ASM Any Source Multicast SSM Source-Specific Multicast

ASMどれソースマルチキャストSSMソース固有マルチキャスト

3. Definitions
3.定義

Distribution Source: In an SSM context, only one entity distributes RTP data and redistributes RTCP information to all receivers. This entity is called the Distribution Source. It is also responsible for forwarding RTCP feedback to the Media Senders and thus creates a virtual multicast environment in which RTP and RTCP can be applied.

配布ソース:SSMのコンテキストでは、1つのエンティティのみがRTPデータを配信し、すべての受信機にRTCP情報を再分配します。このエンティティは、配布ソースと呼ばれています。また、メディアの送信者へのRTCPフィードバックを転送する責任があるので、RTPとRTCPを適用することができる仮想マルチキャスト環境を作成します。

Note that heterogeneous networks consisting of ASM multiple-sender groups, unicast-only clients, and/or SSM single-sender receiver groups MAY be connected via translators or mixers to create a single-source group (see Section 8 for details).

(詳細については、セクション8を参照)ASM多重送信者グループ、ユニキャストのみのクライアント、及び/又はSSM単一センダレシーバ基からなる異種ネットワークは、単一のソースグループを作成する翻訳者またはミキサーを介して接続されてもよいことに留意されたいです。

Media Sender: A Media Sender is an entity that originates RTP packets for a particular media session. In RFC 3550, a Media Sender is simply called a source. However, as the RTCP SSM system architecture includes a Distribution Source, to avoid confusion, in this document a media source is commonly referred to as a Media Sender. There may often be a single Media Sender that is co-located with the Distribution Source. But although there MUST be only one Distribution Source, there MAY be multiple Media Senders on whose behalf the Distribution Source forwards RTP and RTCP packets.

メディア送信者:メディアの送信者は、特定のメディアセッションのためのRTPパケットを発信するエンティティです。 RFC 3550では、メディアの送信者は、単にソースと呼ばれています。しかし、RTCP SSMシステムアーキテクチャとして、このドキュメントでメディアソースは、一般的にメディア送信者と呼ばれ、混乱を避けるために、配布ソースを含んでいます。多くの場合、ディストリビューションソースと同じ場所に配置された単一のメディア送信者があるかもしれません。唯一の配布ソースがなければならないがしかし、その代理として配布ソースがRTPおよびRTCPパケットを転送するには、複数のメディア差出人があるかもしれません。

RTP and RTCP Channels: The data distributed from the source to the receivers is referred to as the RTP channel and the control information as the RTCP channel. With standard RTP/RTCP, these channels typically share the same multicast address but are differentiated via port numbers as specified in [1]. In an SSM context, the RTP channel is multicast from the Distribution Source to the receivers. In contrast, the RTCP or feedback channel is actually the collection of unicast channels between the receivers and the Distribution Source via the Feedback Target(s). Thus, bidirectional communication is accomplished by using SSM in the direction from Distribution Source to the receivers and using the unicast feedback channel in the direction from receivers to Distribution Source. As discussed in the next section, the nature of the channels between the Distribution Source and the Media Sender(s) may vary.

RTPとRTCPチャネル:受信機にソースから配信されるデータは、RTPチャネルとRTCPチャネルと制御情報と呼ぶことにします。標準RTP / RTCPを用いて、これらのチャネルは、典型的には、同じマルチキャストアドレスを共有するが、[1]で指定されたポート番号を介して区別されます。 SSMの文脈において、RTPチャネルが受信機に配信元からマルチキャストされます。対照的に、RTCP又はフィードバックチャネルは、実際にはフィードバック目標(複数可)を介して受信し、配信元との間のユニキャストチャネルの集合です。従って、双方向通信は、配信元から受信機への方向にSSMを使用し、受信機から配信元の方向にユニキャストフィードバックチャネルを使用することによって達成されます。次のセクションで論じたように、配信元とメディア送信者(S)との間のチャネルの性質が変化してもよいです。

(Unicast RTCP) Feedback Target: The Feedback Target is a logical function to which RTCP unicast feedback traffic is addressed. The functions of the Feedback Target and the Distribution Source MAY be co-located or integrated in the same entity. In this case, for a session defined as having a Distribution Source A, on ports n for the RTP channel and k for the RTCP channel, the unicast RTCP Feedback Target is identified by an IP address of Distribution Source A on port k, unless otherwise stated in the session description. See Section 10 for details on how the address is specified. The Feedback Target MAY also be implemented in one or more entities different from the Distribution Source, and different RTP receivers MAY use different Feedback Target instances, e.g., for aggregation purposes. In this case, the Feedback Target instance(s) MUST convey the feedback received from the RTP receivers to the Distribution Source using the RTCP mechanisms specified in this document. If disjoint, the Feedback Target instances MAY be organized in arbitrary topological structures: in parallel, hierarchical, or chained. But the Feedback Target instance(s) and Distribution Source MUST share, e.g., through configuration, enough information to be able to provide coherent RTCP information to the RTP receivers based upon the RTCP feedback collected by the Feedback Target instance(s) -- as would be done if both functions were part of the same entity.

(ユニキャストRTCP)フィードバック目標:フィードバック目標は、RTCPフィードバックユニキャストトラフィックがアドレス指定された論理的機能です。フィードバック目標と配布ソースの機能は同じ場所に配置または同じエンティティに統合することができます。この場合には、配布元Aを有するものとして定義されたセッションのために、ポート上のn RTCPチャネル用のRTPチャネルとkについて、ユニキャストRTCPフィードバックターゲットポートkに配信元AのIPアドレスによって識別され、そうでない場合を除きセッションの説明で述べました。アドレスが指定されている方法の詳細については、セクション10を参照してください。フィードバック目標はまた、配布元とは異なる一の以上のエンティティに実装されてもよく、異なるRTP受信機は、凝集のために、例えば、異なるフィードバック目標インスタンスを使用することができます。この場合、フィードバックターゲット・インスタンス(複数可)は、この文書で指定されたRTCPメカニズムを使用して、配信元にRTP受信機から受信したフィードバックを伝えなければなりません。互いに素ならば、フィードバック目標インスタンスは、任意のトポロジカルな構造に編成することができる:、並列階層的な、またはチェーンで。 - しかし、フィードバック目標インスタンス(複数可)と配布ソースを共有する必要があり、例えば、構成によって、十分な情報がフィードバックターゲット・インスタンス(複数可)によって収集さRTCPのフィードバックに基づいてRTP受信機へのコヒーレントRTCP情報を提供することができるようにします両方の機能は、同じエンティティの一部であった場合に行われることになります。

In order for unicast feedback to work, each receiver MUST direct its RTCP reports to a single specific Feedback Target instance.

ユニキャストフィードバックが機能するためには、各受信機は、単一の特定のフィードバックターゲット・インスタンスへのRTCP報告を指示しなければなりません。

SSRC: Synchronization source as defined in [1]. This 32-bit value uniquely identifies each member in a session.

SSRC:[1]で定義されるように同期ソース。この32ビット値は、一意のセッション内の各メンバーを識別する。

Report blocks: Report block is the standard terminology for an RTCP reception report. RTCP [1] encourages the stacking of multiple report blocks in Sender Report (SR) and Receiver Report (RR) packets. As a result, a variable-size feedback packet may be created by one source that reports on multiple other sources in the group. The summarized reporting scheme builds upon this model through the inclusion of multiple summary report blocks in one packet. However, stacking of reports from multiple receivers is not permitted in the Simple Feedback Model (see Section 6).

レポートブロック:レポートのブロックがRTCP受信レポートの標準的な用語です。 RTCPは、[1]送信者レポート(SR)と受信レポート(RR)パケット内の複数のレポートブロックの積み重ねを奨励しています。その結果、可変サイズのフィードバックパケットは、グループ内の複数の他のソースに報告つのソースによって生成することができます。要約報告スキームは、1つのパケット内の複数のサマリレポートブロックを含めることによって、このモデル上に構築されています。しかし、複数の受信機からの報告の積み重ねが、単純なフィードバックモデルでは許可されていない(第6節を参照してください)。

4. Basic Operation
4.基本操作

As indicated by the definitions of the preceding section, one or more Media Senders send RTP packets to the Distribution Source. The Distribution Source relays the RTP packets to the receivers using a source-specific multicast arrangement. In the reverse direction, the receivers transmit RTCP packets via unicast to one or more instances of the Feedback Target. The Feedback Target sends either the original RTCP reports (the Simple Feedback Model) or summaries of these reports (the Summary Feedback Model) to the Distribution

前のセクションの定義によって示されるように、1つまたは複数のメディア送信者は、配信元にRTPパケットを送信します。配布ソースはソース固有のマルチキャスト構成を用いて受信機にRTPパケットを中継します。逆方向では、受信機がフィードバック目標の1つまたは複数のインスタンスへのユニキャストを介してRTCPパケットを送信します。フィードバック目標は、配布元のRTCPレポート(単純なフィードバックモデル)、またはこれらの報告書の要約(サマリーフィードバックモデル)のいずれかを送信します

Source. The Distribution Source in turn relays the RTCP reports and/or summaries to the Media Senders. The Distribution Source also transmits the RTCP Sender Reports and Receiver Reports or summaries back to the receivers, using source-specific multicast.

ソース。順番に配布ソースは、メディア送信者にRTCPのレポートおよび/または要約を中継します。配信元は、ソース固有マルチキャストを使用して、戻って受信機にRTCPセンダレポートとレシーバレポート又は要約を送信します。

When the Feedback Target(s) are co-located (or integrated) with the Distribution Source, redistribution of original or summarized RTCP reports is trivial. When the Feedback Target(s) are physically and/or topologically distinct from the Distribution Source, each Feedback Target either relays the RTCP packets to the Distribution Source or summarizes the reports and forwards an RTCP summary report to the Distribution Source. Coordination between multiple Feedback Targets is beyond the scope of this specification.

フィードバックターゲット(複数可)同じ場所に配置(または一体化)されている場合の配信元と、オリジナルまたは要約RTCPレポートの再配布は自明です。フィードバックターゲット(s)が配布ソースからの物理的および/または位相幾何学的に区別され、それぞれのフィードバック目標は、ディストリビューション・ソースにRTCPパケットを中継やレポートをまとめ、配布ソースにRTCP要約レポートを転送するのどちらか。複数のフィードバックターゲット間の調整は、この仕様の範囲を超えています。

The Distribution Source MUST be able to communicate with all group members in order for either mechanism to work. The general architecture is displayed below in Figure 1. There may be a single Media Sender or multiple Media Senders (Media Sender i, 1<=i<=M) on whose behalf the Distribution Source disseminates RTP and RTCP packets. The base case, which is expected to be the most common case, is that the Distribution Source is co-located with a particular Media Sender. A basic assumption is that communication is multicast (either SSM or ASM) in the direction of the Distribution Source to the receivers (R(j), 1<=j<=N) and unicast in the direction of the receivers to the Distribution Source.

配布ソースは、仕事へのいずれかのメカニズムのために、すべてのグループメンバーと通信できる必要があります。一般的なアーキテクチャは、単一のメディア送信者または複数のメディア送信者が存在してもよい。図1に下に表示されている(メディアSenderはI、1 <= I <= M)、その代わり配信元は、RTP及びRTCPパケットを広めるに。最も一般的なケースであると期待される基本ケースは、配布元が特定のメディア送信者と同じ場所に配置されていることです。基本的な仮定は、通信が受信機に配信元の方向にマルチキャスト(SSMまたはASMのいずれか)であることである(R(j)は、1 <= jの<= N)と配信元へ受信機の方向にユニキャスト。

Communication between Media Sender(s) and the Distribution Source may be performed in numerous ways:

メディア送信者(S)と配布ソースの間の通信は、さまざまな方法で行うことができます。

i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast.

私。ユニキャストのみ:メディア送信者(複数可)の配信元にユニキャストでRTPとRTCPを送信し、ユニキャストRTCPを受け取ることができます。

ii. Any Source Multicast (ASM): The Media Sender(s) and the Distribution Source MAY be in the same ASM group, and RTP and RTCP packets are exchanged via multicast.

II。任意のソースマルチキャスト(ASM):メディア送信者(S)と配布ソースは同じASMグループであってもよく、およびRTPとRTCPパケットはマルチキャストを介して交換されています。

iii. Source-Specific Multicast (SSM): The Media Sender(s) and the Distribution Source MAY be in an SSM group with the source being the Distribution Source. RTP and RTCP packets from the Media Senders are sent via unicast to the Distribution Source, while RTCP packets from the Distribution Source are sent via multicast to the Media Senders.

III。ソース固有マルチキャスト(SSM):メディア送信者(S)と配信元のソースは、配布元であるとSSM基であってもよいです。配布ソースからRTCPパケットはメディア送信者へのマルチキャストを介して送信されている間、メディアの送信者からのRTPとRTCPパケットは、配布元へのユニキャストを介して送信されます。

        Note that this SSM group MAY be identical to the SSM group used
        for RTP/RTCP delivery from the Distribution Source to the
        receivers or it MAY be a different one.
        

Note that Figure 1 below shows a logical diagram and, therefore, no details about the above options for the communication between Media Sender(s), Distribution Source, Feedback Target(s), and receivers are provided.

以下従って、メディア送信者(複数可)、配信元、フィードバック目標(複数可)、及び受信機間の通信のために上記のオプションについての詳細は提供されない、論理図を示している。図1に注意してください。

Configuration information needs to be supplied so that (among other reasons):

構成情報は、(他の理由の中で)ように供給する必要があります。

o Media Sender(s) know the transport address of the Distribution Source or the transport address of the (ASM or SSM) multicast group used for the contribution link;

Oメディア送信者(複数可)配布ソースまたは(ASMまたはSSM)の貢献のリンクに使用されるマルチキャストグループのトランスポートアドレスのトランスポートアドレスを知っています。

o the Distribution Source knows either the unicast transport address(es) or the (ASM or SSM) multicast transport address(es) to reach the Media Sender(s);

Oの配信元は、ユニキャストトランスポートアドレス(複数可)または(ASMまたはSSM)マルチキャストトランスポートアドレス(複数可)メディア送信者(複数可)を到達するためのいずれかを知っています。

o receivers know the addresses of their respectively responsible Feedback Targets; and

O受信機は、彼らのそれぞれの責任フィードバックターゲットのアドレスを知っています。そして

o the Feedback Targets know the transport address of the Distribution Source.

oをフィードバックターゲットは配布ソースのトランスポートアドレスを知っています。

The precise setup and configuration of the Media Senders and their interaction with the Distribution Source is beyond the scope of this document (appropriate Session Description Protocol (SDP) descriptions MAY be used for this purpose), which only specifies how the various components interact within an RTP session. Informative examples for different configurations of the Media Sources and the Distribution Source are given in Appendix A.

ディストリビューション・ソースとの正確なセットアップとメディア送信者の設定およびそれらの相互作用は、様々なコンポーネントが内部にどのように相互作用するかを指定します(説明はこの目的で使用することができる適切なセッション記述プロトコル(SDP))は、この文書の範囲を超えていますRTPセッション。メディアソースと配布ソースの異なる構成のための参考例は、付録Aに与えられています

Future specifications may be defined to address these aspects.

将来の仕様は、これらの側面に対処するように定義することができます。

                                        Source-specific
         +--------+       +-----+          Multicast
         |Media   |       |     |     +----------------> R(1)
         |Sender 1|<----->| D S |     |                    |
         +--------+       | I O |  +--+                    |
                          | S U |  |  |                    |
         +--------+       | T R |  |  +-----------> R(2)   |
         |Media   |<----->| R C |->+  +---- :         |    |
         |Sender 2|       | I E |  |  +------> R(n-1) |    |
         +--------+       | B   |  |  |          |    |    |
             :            | U   |  +--+--> R(n)  |    |    |
             :            | T +-|          |     |    |    |
                          | I | |<---------+     |    |    |
         +--------+       | O |F|<---------------+    |    |
         |Media   |       | N |T|<--------------------+    |
         |Sender M|<----->|   | |<-------------------------+
         +--------+       +-----+            Unicast
        

FT = Feedback Target Transport from the Feedback Target to the Distribution Source is via unicast or multicast RTCP if they are not co-located.

フィードバック目標からFT =フィードバックターゲット交通の配信元に、彼らは同じ場所に配置されていない場合、ユニキャストまたはマルチキャストRTCPを経由しています。

Figure 1: System Architecture

図1:システムアーキテクチャ

The first method proposed to support unicast RTCP feedback, the 'Simple Feedback Model', is a basic reflection mechanism whereby all Receiver RTCP packets are unicast to the Feedback Target, which relays them unmodified to the Distribution Source. Subsequently, these packets are forwarded by the Distribution Source to all receivers on the multicast RTCP channel. The advantage of using this method is that an existing receiver implementation requires little modification in order to use it. Instead of sending reports to a multicast address, a receiver uses a unicast address yet still receives forwarded RTCP traffic on the multicast control channel. This method also has the advantage of being backwards compatible with standard RTP/RTCP implementations. The Simple Feedback Model is specified in Section 6.

第1の方法は、ユニキャストRTCPフィードバックをサポートするために提案されている、「単純なフィードバックモデル」は、すべての受信RTCPパケットが配信元に、それらは非修飾リレーフィードバック目標へのユニキャストであることにより、基本的な反射機構です。その後、これらのパケットはマルチキャストRTCPチャネル上のすべての受信機に配布ソースによって転送されます。この方法を使用することの利点は、既存の受信機の実装は、それを使用するために少し変更を必要とすることです。代わりに、マルチキャストアドレスにレポートを送信すると、受信機は、まだ、まだユニキャストアドレスを使用して、マルチキャスト制御チャネル上で転送RTCPトラフィックを受信します。この方法は、標準RTP / RTCPの実装との後方互換性であるという利点を有します。単純なモデルの感想は、第6節で指定されています。

The second method, the 'Distribution Source Feedback Summary Model', is a summarized reporting scheme that provides savings in bandwidth by consolidating Receiver Reports at the Distribution Source, optionally with help from the Feedback Target(s), into summary packets that are then distributed to all the receivers. The Distribution Source Feedback Summary Model is specified in Section 7.

第二の方法、「配布ソースフィードバックの概要モデルは、」、レシーバーを統合することにより、帯域幅の節約を提供してまとめた報告スキームは、配布元で、必要に応じてフィードバック目標(S)からの助けを借りて、その後、分散されているサマリパケットに報告されすべての受信機へ。配布ソースフィードバックの概要モデルは、セクション7で指定されています。

The advantage of the latter scheme is apparent for large group sessions where the basic reflection mechanism outlined above generates a large amount of packet forwarding when it replicates all the information to all the receivers. Clearly, this technique requires that all session members understand the new summarized packet format outlined in Section 7.1. Additionally, the summarized scheme provides an optional mechanism to send distribution information or histograms about the feedback data reported by the whole group. Potential uses for the compilation of distribution information are addressed in Section 7.4.

後者の方式の利点は、すべての受信機にすべての情報を複製する際に上記で概説した基本的な反射機構は、パケット転送を大量に生成する大規模なグループセッションのために明らかです。明らかに、この技術は、すべてのセッションメンバーは、7.1節で概説した新しい要約パケットフォーマットを理解することが必要です。また、要約スキームは、全体グループによって報告されたフィードバックデータに関する配信情報やヒストグラムを送信する任意のメカニズムを提供します。配信情報の編集のための潜在的な用途は、セクション7.4で扱われています。

To differentiate between the two reporting methods, a new SDP identifier is created and discussed in Section 10. The reporting method MUST be decided prior to the start of the session. A Distribution Source MUST NOT change the method during a session.

2つの報告方法を区別するために、新しいSDP識別子が作成され、第10の報告方法に記載されている前のセッションの開始を決定しなければなりません。配布ソースは、セッション中にメソッドを変更してはなりません。

In a session using SSM, the network SHOULD prevent any multicast data from the receiver being distributed further than the first hop router. Additionally, any data heard from a non-unicast-capable receiver by other hosts on the same subnet SHOULD be filtered out by the host IP stack so that it does not cause problems with respect to the calculation of the receiver RTCP bandwidth share.

SSMを使用してセッションでは、ネットワークは、受信機からの任意のマルチキャストデータは、最初のホップルータよりも分散されるのを防ぐべきです。それは受信機RTCP帯域幅共有の計算に関して問題が発生しないように加えて、同じサブネット上の他のホストによって非ユニキャスト可能なレシーバから聞いた任意のデータは、ホストIPスタックによって除外されるべきです。

5. Packet Types
5.パケットタイプ

The RTCP packet types defined in [1], [26], and [15] are:

[1]で定義されたRTCPパケットタイプ、[26]及び[15]です。

   Type       Description                  Payload number
   -------------------------------------------------------
   SR         Sender Report                200
   RR         Receiver Report              201
   SDES       Source Description           202
   BYE        Goodbye                      203
   APP        Application-Defined          204
   RTPFB      Generic RTP feedback         205
   PSFB       Payload-specific feedback    206
   XR         RTCP Extension               207
        

This document defines one further RTCP packet format:

この文書では、一つのさらなるRTCPパケットのフォーマットを定義します。

   Type       Description                    Payload number
   ---------------------------------------------------------
   RSI        Receiver Summary Information   209
        

Within the Receiver Summary Information packet, there are various types of information that may be reported and encapsulated in optional sub-report blocks:

レシーバ要約情報パケット内で、任意のサブレポートブロックに報告し、カプセル化され得る様々なタイプの情報があります。

   Name              Long Name                                 Value
   ------------------------------------------------------------------
   IPv4 Address     IPv4 Feedback Target Address                 0
   IPv6 Address     IPv6 Feedback Target Address                 1
   DNS Name         DNS name indicating Feedback Target Address  2
   Reserved         Reserved for Assignment by Standards Action  3
   Loss             Loss distribution                            4
   Jitter           Jitter distribution                          5
   RTT              Round-trip time distribution                 6
   Cumulative loss  Cumulative loss distribution                 7
   Collisions       SSRC collision list                          8
   Reserved         Reserved for Assignment by Standards Action  9
   Stats            General statistics                          10
   RTCP BW          RTCP bandwidth indication                   11
   Group Info       RTCP group and average packet size          12
   -                Unassigned                            13 - 255
        

As with standard RTP/RTCP, the various reports MAY be combined into a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets continue to be sent at a rate that is inversely proportional to the group size in order to scale the amount of traffic generated.

標準RTP / RTCPと同様に、様々なレポートは、パスMTUを超えてはならない単一のRTCPパケットに組み合わせることができます。パケットが生成されるトラフィックの量をスケーリングするために、グループサイズに反比例する速度で送信され続けます。

6. Simple Feedback Model
6.シンプルなモデルの感想
6.1. Packet Formats
6.1. パケットフォーマット

The Simple Feedback Model uses the same packet types as traditional RTCP feedback described in [1]. Receivers still generate Receiver Reports with information on the quality of the stream received from the Distribution Source. The Distribution Source still MUST create Sender Reports that include timestamp information for stream synchronization and round-trip time calculation. Both Media Senders and receivers are required to send SDES packets as outlined in [1]. The rules for generating BYE and APP packets as outlined in [1] also apply.

単純なフィードバックモデル[1]に記載の従来のRTCPフィードバックと同じパケットタイプを使用します。レシーバは、まだ配布ソースから受信したストリームの品質に関する情報をレシーバレポートを生成します。配布ソースはまだストリーム同期と往復時間計算のためのタイムスタンプ情報が含まれ、送信者レポートを作成する必要があります。メディアの送信側と受信側の両方が、[1]に概説されているようSDESパケットを送信するために必要とされます。概説されるようにBYEとAPPパケットを生成するための規則は、[1]にも当てはまります。

6.2. Distribution Source Behavior
6.2. 配布元挙動

For the Simple Feedback Model, the Distribution Source MUST provide a basic packet-reflection mechanism. It is the default behavior for any Distribution Source and is the minimum requirement for acting as a Distribution Source to a group of receivers using unicast RTCP feedback.

単純なモデルの感想については、配布ソースは、基本的なパケット反射機構を提供しなければなりません。これは、任意のディストリビューション・ソースのデフォルトの動作で、ユニキャストRTCPのフィードバックを使用した受信機のグループに配布ソースとして機能するための最小要件です。

The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port. All valid unicast RTCP packets received on this port MUST be forwarded by the Distribution Source to the group on the multicast RTCP channel. The Distribution

配布ソース(ユニキャストフィードバック目標は)RTCPポートに送信されたユニキャストRTCPデータをリッスンする必要があります。 RTCPパケットがこのポートで受信したすべての有効なユニキャスト、マルチキャストのRTCPチャネル上のグループに配布ソースによって転送されなければなりません。配布

Source MUST NOT stack report blocks received from different receivers into one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually.

ソースは、グループへの再送信のために1つのパケットに別の受信機から受信したレポートブロックを積み重ねてはなりません。各受信機からのすべてのRTCPパケットを個別に反映されなければなりません。

If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets received from the receivers to the Media Sender(s). If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet originated by one Media Sender to all other Media Senders.

メディア送信者(単数または複数)がRTCPパケット反射のSSMグループの一部でない場合、配信元はまた、RTCPパケットを転送しなければならないメディア送信者(複数可)に受信機から受信しました。そこに複数のメディアSenderがあり、これらのメディアの送信者は配布ソースと相互にASMを介して通信していない場合は、配布ソースは、他のすべてのメディアの送信者への1つのメディア送信者が発信した各RTCPパケットを転送する必要があります。

The Distribution Source MUST forward RTCP packets originating from the Media Sender(s) to the receivers.

配布ソースは、受信機へのメディア送信者(複数可)から発信RTCPパケットを転送する必要があります。

The reflected or forwarded RTCP traffic SHOULD NOT be counted as its own traffic in the transmission interval calculation by the Distribution Source. In other words, the Distribution Source SHOULD NOT consider reflected packets as part of its own control data bandwidth allowance. However, reflected packets MUST be processed by the Distribution Source and the average RTCP packet size, RTCP transmission rate, and RTCP statistics MUST be calculated. The algorithm for computing the allowance is explained in Section 9.

反射又は転送されたRTCPトラフィックが配信元によって送信間隔の計算にそれ自身のトラフィックとしてカウントされるべきではありません。言い換えれば、配布ソースには、独自の制御データ帯域幅手当の一部として反映パケットを考慮すべきではありません。しかし、反射されたパケットは、配信元と平均RTCPパケットサイズ、RTCP送信レートによって処理されなければならない、とRTCP統計を計算しなければなりません。手当を計算するためのアルゴリズムは、9章で説明されています。

6.3. Disjoint Distribution Source and Feedback Target(s)
6.3. ばらばらの配布元とフィードバック目標(S)

If the Feedback Target function is disjoint from the Distribution Source, the Feedback Target(s) MUST forward all RTCP packets from the receivers or another Feedback Target -- directly or indirectly -- to the Distribution Source.

フィードバック目標関数は、配信元から互いに素である場合、フィードバックターゲット(複数可)受信機または他のフィードバック目標からのすべてのRTCPパケットを転送しなければならない - 直接的または間接的に - 配信元へ。

6.4. Receiver Behavior
6.4. レシーバーの動作

Receivers MUST listen on the RTP channel for data and on the RTCP channel for control. Each receiver MUST calculate its share of the control bandwidth R/n, in accordance with the profile in use, so that a fraction of the RTCP bandwidth, R, allocated to receivers is divided equally between the number of unique receiver SSRCs in the session, n. R may be rtcp_bw * 0.75 or rtcp_bw * 0.5 (depending on the ratio of senders to receivers as per [1]) or may be set explicitly by means of an SDP attribute [10]. See Section 9 for further information on the calculation of the bandwidth allowance. When a receiver is eligible to transmit, it MUST send a unicast Receiver Report packet to the Feedback Target following the rules defined in Section 9.

レシーバは、データ用と制御用RTCPチャネル上のRTPチャネルをリッスンしなければなりません。各受信機は、使用中のプロファイルに従って、RTCP帯域幅の割合となるよう、制御帯域R / Nのシェアを計算する必要があり、受信機に割り当てRは、セッションに均等にユニーク受信SSRCsの数との間に分割されますn個。 Rは、([1]の通りの受信機に送信者の比率に応じて)* 0.75 rtcp_bw * 0.5 rtcp_bwてもよく、または[10] SDP属性を用いて明示的に設定することができます。帯域幅手当の計算の詳細については、セクション9を参照してください。受信機が送信する資格がある場合は、第9章で定義された規則に従ってフィードバック目標にユニキャストレシーバレポートパケットを送らなければなりません。

When a receiver observes either RTP packets or RTCP Sender Reports from a Media Sender with an SSRC that collides with its own chosen SSRC, it MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing and before sending any (further) RTCP feedback messages.

受信機は、自身の選択されたSSRCと衝突SSRCとメディア送信元からRTPパケットまたはRTCP送信者レポートのいずれかを観察するとき、それはの手順に従って、自身のSSRCを変更しなければならない[1]。受信機はすぐに気付いた後、任意の(さらに)RTCPフィードバックメッセージを送信する前に行う必要があります。

If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. Even if such out-of-band information is available, a receiver MUST obey the above collision-resolution mechanisms.

受信機はメディアセッションで使用されるメディアの送信者SSRC(複数可)についての利用可能帯域外の情報を持っている場合、それは自分自身のために同じSSRCを使用してはなりません。そのようなアウト・オブ・バンド情報が利用可能であっても、受信機は、前記衝突解決メカニズムに従わなければなりません。

Further mechanisms defined in [1] apply for resolving SSRC collisions between receivers.

で定義された更なるメカニズムは、[1]の受信機との間のSSRC衝突を解決するために適用します。

6.5. Media Sender Behavior
6.5. メディア送信者行動

Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (forwarded by the Distribution Source if needed). Processing and general operation follows [1].

メディア送信者は、受信機によって送信されたRTCPレポートのユニキャストまたはマルチキャストトランスポートアドレスをリッスン(と配布ソースによって転送)または(必要に応じて配布ソースによって転送)他のメディアの送信者。処理及び一般的な動作は以下の[1]。

A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision-resolution actions as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately.

5 * 1.5によって、メディア送信者が[1]の通り、自身の衝突解決アクションを遅延させることができるされていない別のエンティティとのSSRC衝突を観察メディア送信者、* Tdを、Tdを受信するために、決定論的な計算されたレポートインターバルであると競合がまだ存在するかどうかを確認します。他のメディアの送信者とのSSRC衝突がすぐに作用しなければなりません。

Note: This gives precedence to Media Senders and places the burden of collision resolution on the RTP receivers.

注意:これは、メディアの送信者に優先権を与え、RTP受信機に衝突解決の負担を配置します。

Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC aggressively or unnecessarily.

送信者SSRC情報は、SDPメディア記述の手段によって、例えば、アウト・オブ・バンド通信することができます。したがって、送信者は、積極的または不必要に自分自身のSSRCを変更しないでください。

7. Distribution Source Feedback Summary Model
7.配布ソースフィードバックの概要モデル

In the Distribution Source Feedback Summary Model, the Distribution Source is required to summarize the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The Distribution Source Feedback Summary Model introduces a new report block format, the Receiver Summary Information (RSI) report, and a number of optional sub-report block formats, which are enumerated in Section 7.1. As described in Section 7.3, individual instances of the Feedback Target may provide preliminary summarization to reduce the processing load at the Distribution Source.

配布ソースフィードバックの概要モデルでは、配布ソースは、受信機によって生成されたすべてのレシーバレポートから受信した情報を要約し、要約レポートに情報を配置するために必要とされます。配布ソースフィードバックの概要モデルは、新しいレポートブロック形式を導入し、レシーバーのサマリー情報(RSI)の報告、および7.1節に列挙されているオプションのサブレポートブロック形式の数。セクション7.3で説明したように、フィードバック目標の個々のインスタンスは、配信元での処理負荷を軽減する予備的要約を提供することができます。

Sub-reports appended to the RSI report block provide more detailed information on the overall session characteristics reported by all receivers and can also convey important information such as the feedback address and reporting bandwidth. Which sub-reports are mandatory and which ones are optional is defined below.

RSIレポートブロックに追加サブレポートは、すべての受信機によって報告された全体的なセッション特性に関するより詳細な情報を提供し、また、そのようなフィードバックアドレスおよびレポート、帯域幅などの重要な情報を伝えることができます。これは、サブレポートが必須で、どれが以下に定義されるオプションです。

From an RTP perspective, the Distribution Source is an RTP receiver, generating its own Receiver Reports and sending them to the receiver group and to the Media Senders. In the Distribution Source Feedback Summary Model, an RSI report block MUST be appended to all RRs the Distribution Source generates.

RTPの観点から、配布ソースには、独自のレシーバレポートを生成し、受信グループにメディア送信者に送信し、RTP受信機です。配布ソースフィードバックの概要モデルでは、RSIのレポートブロックは、配布ソースが生成するすべてのRRに追加されなければなりません。

In addition, the Distribution Source MUST forward the RTCP SR reports and SDES packets of Media Senders without alteration. If the Distribution Source is actually a Media Sender, even if it is the only session sender, it MUST generate its own Sender Report (SR) packets for its role as a Media Sender and its Receiver Reports in its role as the Distribution Source.

また、配布ソースをそのままメディア送信者のRTCPのSRレポートとSDESパケットを転送する必要があります。配布ソースが実際にメディアの送信者である場合は、それが唯一のセッションの送信者であったとしても、それがメディアの送信者と配布ソースとしての役割でそのレシーバレポートとしての役割のために、独自の送信者レポート(SR)パケットを生成しなければなりません。

The Distribution Source MUST use its own SSRC value for transmitting summarization information and MUST perform proper SSRC collision detection and resolution.

配布ソースは要約情報を送信するために、独自のSSRC値を使用しなければならないし、適切なSSRC衝突検出および解決を実行しなければなりません。

The Distribution Source MUST send at least one Receiver Summary Information packet for each reporting interval. The Distribution Source MAY additionally stack sub-report blocks after the RSI packet. If it does so, each sub-report block MUST correspond to the RSI packet and constitutes an enhancement to the basic summary information required by the receivers to calculate their reporting time interval. For this reason, additional sub-report blocks are not required but recommended. The compound RTCP packets containing the RSI packet and the optional corresponding sub-report blocks MUST be formed according to the rules defined in [1] for receiver-issued packets, e.g., they MUST begin with an RR packet, contain at least an SDES packet with a CNAME, and MAY contain further RTCP packets and SDES items.

配布ソースは、各報告期間のために、少なくとも1つの受信機概要情報パケットを送らなければなりません。配布ソースはさらにRSIパケットの後にサブレポートブロックを積み重ねてもよい(MAY)。そうでない場合は、各サブレポートブロックは、RSIのパケットに対応し、それらのレポート時間間隔を計算するために受信機によって必要とされる基本的な要約情報にエンハンスメントを構成しなければなりません。このため、追加のサブレポートブロックが必要ですが、推奨されていません。 RSIパケットおよびオプションの対応するサブレポートブロックを含む複合RTCPパケットは、で定義されたルールに従って形成されなければならない[1]受信発行パケット、例えば、それらは、RRパケットで始まる必要があり、少なくともSDESパケットを含みますCNAMEで、さらにRTCPパケットとSDES項目を含むかもしれません。

Every RSI packet MUST contain either a Group and Average Packet Size sub-report or an RTCP Bandwidth sub-report for bandwidth indications to the receivers.

すべてのRSIパケットは、グループと平均パケットサイズのサブレポートまたは受信機への帯域幅の適応のためのRTCP帯域幅のサブレポートのいずれかを含まなければなりません。

7.1. Packet Formats
7.1. パケットフォーマット

All numeric values comprising multiple (usually two or four) octets MUST be encoded in network byte order.

複数(通常2つまたは4つの)オクテットを含むすべての数値は、ネットワークバイト順に符号化されなければなりません。

7.1.1. RSI: Receiver Summary Information Packet
7.1.1. RSI:レシーバの概要情報パケット

The RSI report block has a fixed header size followed by a variable length report:

RSIレポートブロックは、可変長レポートに続く固定ヘッダのサイズを有します。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|reserved |   PT=RSI=209  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SSRC                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Summarized SSRC                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP Timestamp (most significant word)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP Timestamp (least significant word)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       Sub-report blocks                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The RSI packet includes the following fields:

RSIパケットは、次のフィールドが含まれます。

Length: 16 bits As defined in [1], the length of the RTCP packet in 32-bit words minus one, including the header and any padding.

長さ:[1]で定義された16ビットと、ヘッダおよびパディングを含む32ビットワードから1を引いたもの、でRTCPパケットの長さ。

SSRC: 32 bits The SSRC of the Distribution Source.

SSRC:32ビット配布ソースのSSRC。

Summarized SSRC: 32 bits The SSRC (of the Media Sender) of which this report contains a summary.

このレポートは、要約を含む32ビット(メディア送信元の)SSRC:SSRCをまとめます。

Timestamp: 64 bits Indicates the wallclock time when this report was sent. Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [1]. The wallclock time MAY (but need not) be NTP-synchronized but it MUST provide a consistent behavior in the advancement of time (similar to NTP). The full-resolution NTP timestamp is used, which is a 64-bit, unsigned, fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is similar to RTCP Sender Reports (Section 6.4.1 of [1]). The timestamp value is used to enable detection of duplicate packets, reordering, and to provide a chronological profile of the feedback reports.

タイムスタンプ:64ビットは、この報告書が送信された壁時計の時刻を示します。ウォールクロック時間(絶対日時)[1] 1900年1月1日に0HのUTCに対する相対秒であるネットワークタイムプロトコル(NTP)のタイムスタンプ形式を使用して表されています。壁時計の時間は(必ずしも必要ではないが)NTPは、同期させることができるが、それは、時間(NTPに類似)の進歩で一貫性のある動作を提供しなければなりません。最初の32ビットの整数部と最後の32ビットに小数部分を有する64ビットの符号なしの固定小数点数であるNTPタイムスタンプが使用され、フル解像度、。このフォーマットは、RTCP送信者レポート([1]のセクション6.4.1)と同様です。タイムスタンプ値は、重複パケットの検出を可能に並べ替え、およびフィードバック・レポートの時系列プロファイルを提供するために使用されます。

7.1.2. Sub-Report Block Types
7.1.2. サブレポートのブロックタイプ

For RSI reports, this document also introduces a sub-report block format specific to the RSI packet. The sub-report blocks are appended to the RSI packet using the following generic format. All sub-report blocks MUST be 32-bit aligned.

RSIのレポートの場合、この文書はまた、RSIパケットに特定のサブレポートブロックのフォーマットを紹介します。サブレポートのブロックは、次の一般的な形式を使用して、RSIのパケットに付加されています。すべてのサブレポートブロックは、32ビット整列させる必要があります。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SRBT      |    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      SRBT-specific data       +
   |                                                               |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

SRBT: 8 bits Sub-Report Block Type. The sub-report block type identifier. The values for the sub-report block types are defined in Section 5.

SRBT:8ビットサブレポートのブロックタイプ。サブレポートブロックタイプ識別子。サブレポートのブロックタイプの値は、セクション5で定義されています。

Length: 8 bits The length of the sub-report in 32-bit words.

長さ:8ビット、32ビットワード内のサブレポートの長さ。

SRBT-specific data: <length * 4 - 2> octets This field may contain type-specific information based upon the SRBT value.

SRBT固有のデータ:<4×長さ - 2>オクテットこのフィールドはSRBT値に基づいてタイプに固有の情報が含まれていてもよいです。

7.1.3. Generic Sub-Report Block Fields
7.1.3. 一般的なサブレポート・ブロックのフィールド

For the sub-report blocks that convey distributions of values (Loss, Jitter, RTT, Cumulative Loss), a flexible 'data bucket'-style report is used. This format divides the data set into variable-size buckets that are interpreted according to the guide fields at the head of the report block.

値(損失、ジッタ、RTT、累積損失)の分布を伝えるサブレポートブロックに対して、柔軟な「データbucket'スタイルのレポートが使用されています。このフォーマットは、レポート・ブロックの先頭のガイドフィールドに従って解釈される可変サイズのバケットにデータセットを分割します。

    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
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |     SRBT      |    Length     |        NDB            |   MF  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Minimum Distribution Value                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Maximum Distribution Value                  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                      Distribution Buckets                     |
   |                             ...                               |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        

The SRBT and length fields are calculated as explained in Section 7.1.2.

セクション7.1.2で説明したようにSRBTと長さフィールドが計算されます。

Number of distribution buckets (NDB): 12 bits The number of distribution buckets of data. The size of each bucket can be calculated using the formula ((length * 4) - 12) * 8 / NDB number of bits. The calculation is based on the length of the whole sub-report block in octets (length * 4) minus the header of 12 octets. Providing 12 bits for the NDB field enables bucket sizes as small as 2 bits for a full-length packet of MTU 1500 bytes. The bucket size in bits must always be divisible by 2 to ensure proper byte alignment. A bucket size of 2 bits is fairly restrictive, however, and it is expected that larger bucket sizes will be more practical for most distributions.

12ビットデータの分布バケットの数:分布バケット(NDB)の数。ビット×8 / NDB番号 - 各バケットのサイズは、式(12(長さ* 4))を用いて算出することができます。計算は、オクテット単位で全体のサブレポートブロックの長さ(長さ* 4)マイナス12オクテットのヘッダに基づいています。 NDBフィールドの12ビットを提供するバケットがMTU 1500バイトの全長パケットの2ビットほどの小さいサイズが可能になります。ビット単位のバケットサイズは、常に適切なバイトアライメントを確実にするために2で割り切れなければなりません。 2ビットのバケットサイズは、しかし、かなり限定的であり、より大きなバケットサイズはほとんどのディストリビューションのためのより実用的であることが期待されます。

Multiplicative Factor (MF): 4 bits 2^MF indicates the multiplicative factor to be applied to each distribution bucket value. Possible values of MF are 0 - 15, creating a range of values from MF = 1, 2, 4 ... 32768. Appendix B gives an example of the use of the multiplicative factor; it is meant to provide more "bits" without having them -- the bucket values get scaled up by the MF.

乗法因子(MF):4ビットの2 ^ MFは、乗法因子が各分配バケット値に適用されるかを示します。 MFの可能な値は0である - MF = 1、2、4の値の範囲を作成し、15 ... 32768付録Bは、乗法因子の使用の例を与えます。それらを持つことなく、より「ビット」を提供するためのものです - バケット値はMFでスケールアップされます。

Length: 8 bits The length field tells the receiver the full length of the sub-report block in 32-bit words (i.e., length * 4 bytes) and enables the receiver to identify the bucket size. For example, given no MTU restrictions, the data portion of a distribution packet may be only as large as 1008 bytes (255 * 4 - 12), providing up to 4032 data buckets of length 2 bits, or 2016 data buckets of length 4 bits, etc.

長さ:8ビットの長さフィールドは32ビットワード(すなわち、長さ×4バイト)で受信機にサブレポートブロックの全長に指示し、バケットサイズを識別するために受信機を可能にします。長さ2ビットの4032のデータバケット、または長さの2016データバケット4ビットまで提供する、 - 例えば、どのMTU制限与えられていない、配信パケットのデータ部1008バイト(12 255 * 4)のようなだけの大きさであってもよいですなど

Minimum distribution value (min): 32 bits The minimum distribution value, in combination with the maximum distribution value, indicates the range covered by the data bucket values.

最小分散値(分):32ビット最小分布値は、最大分散値と組み合わせて、データバケット値によってカバーされる範囲を示しています。

Maximum distribution value (max): 32 bits The maximum distribution value, in combination with the minimum distribution value, indicates the range covered by the data bucket values. The significance and range of the distribution values is defined in the individual subsections for each distribution type (DT).

最大分散値(MAX):32ビット最大分布値は、最小分散値と組み合わせて、データバケット値によってカバーされる範囲を示しています。分散値の意義及び範囲は、各配信タイプ(DT)のための個々のサブセクションで定義されています。

Distribution buckets: each bucket is ((length * 4) - 12) * 8 / NDB bits The size and number of buckets is calculated as outlined above based upon the value of NDB and the length of the packet. The values for distribution buckets are equally distributed; according to the following formula, distribution bucket x (with 0 <= x < NDB) covers the value range:

分配バケット各バケットは、((長さ* 4) - 12)* 8 / NDBがNDBの値とパケットの長さに基づいて、上記で概説したようにバケットのサイズ及び数を算出するビット。配布バケットの値が均等に分布しています。次式に従って、配信バケットX(0 <= xの<NDB)は、値の範囲をカバーします。

x = 0; [min, min + (max - min) / NDB] x > 0; [min + (x) * (max - min) / NDB, min + (x + 1) * (max - min) / NDB]

X = 0。 [分、最小+(最大 - 最小)/ NDB] X> 0。 [分+(X)*(最大 - 最小)/ NDB、分+(X + 1)*(最大 - 最小)/ NDB]

Interpretation of the minimum, maximum, and distribution values in the sub-report block is sub-report-specific and is addressed individually in the sections below. The size of the sub-report block is variable, as indicated by the packet length field.

サブレポートブロックにおいて最小値、最大値、および分散値の解釈は、サブレポート固有であり、以下のセクションで個々にアドレスされます。パケット長フィールドによって示されるように、サブレポートブロックのサイズは、可変です。

Note that, for any bucket-based reporting, if the Distribution Source and the Feedback Target(s) are disjoint entities, out-of-band agreement on the bucket-reporting granularity is recommended to allow the Distribution Source to forward accurate information in these kinds of reports to the receivers.

配布ソースとフィードバックがターゲット(s)は互いに素のエンティティであれば任意のバケットベースのレポートのために、バケツ報告粒度のアウトオブバンド合意が配布元がこれらの中で正確な情報を転送できるようにするために推奨される、ということに注意してください受信機へのレポートの種類。

7.1.4. Loss Sub-Report Block
7.1.4. 損失サブレポート・ブロック

The Loss sub-report block allows a receiver to determine how its own reception quality relates to the other recipients. A receiver may use this information, e.g., to drop out of a session (instead of sending lots of error repair feedback) if it finds itself isolated at the lower end of the reception quality scale.

損失サブレポートブロックは、受信機が、自身の受信品質が他の受信者に関連する方法を決定することを可能にします。受信機は、それ自体が受信品質スケールの下端に単離された見つかった場合(代わりに、エラー修復のフィードバックの多くを送信する)セッションからドロップするように、例えば、この情報を使用することができます。

The Loss sub-report block indicates the distribution of losses as reported by the receivers to the Distribution Source. Values are expressed as a fixed-point number with the binary point at the left edge of the field similar to the "fraction lost" field in SR and RR packets, as defined in [1]. The Loss sub-report block type (SRBT) is 4.

配布ソースに受信機によって報告されたように損失サブレポートブロックは、損失の分布を示しています。値は、のようなフィールドの左端にバイナリポイントと固定小数点数として表現されている[1]で定義されるように、SRとRRパケットのフィールドを「画分失いました」。損失サブレポートブロックタイプ(SRBT)は4です。

Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum.

255最小分散値が常に最大値未満でなければならない - 同様に、最大分散値フィールドの有効な結果が1である254 - 最小分散値フィールドの有効な結果は0です。

For examples on processing summarized loss report sub-blocks, see Appendix B.

要約損失報告サブブロックの処理の例については、付録Bを参照してください。

7.1.5. Jitter Sub-Report Block
7.1.5. ジッタサブレポート・ブロック

A Jitter sub-report block indicates the distribution of the estimated statistical variation of the RTP data packet inter-arrival time reported by the receivers to the Distribution Source. This allows receivers both to place their own observed jitter values in context with the rest of the group and to approximate dynamic parameters for playout buffers. See [1] for details on the calculation of the values and the relevance of the jitter results. Jitter values are measured in timestamp units with the rate used by the Media Sender and expressed as unsigned integers. The minimum distribution value MUST always be less than the maximum. The Jitter sub-report block type (SRBT) is 5.

ジッタサブレポートブロックは、配布ソースに受信機によって報告されたRTPデータパケットの内部到着時間の推定統計的変動の分布を示しています。これは、受信機は、両方のグループの残りの部分に関連して、独自の観測されたジッタ値を配置すると、プレイアウトバッファの動的パラメータを近似することができます。値の計算とジッタ結果の関連性の詳細については、[1]参照。ジッタ値は、メディア送信者によって使用されるレートとタイムスタンプ単位で測定され、符号なし整数として表現されます。最小分布値は常に最大値未満でなければなりません。ジッタサブレポートブロックタイプ(SRBT)は5です。

Since timestamp units are payload-type specific, the relevance of a jitter value is impacted by any change in the payload type during a session. Therefore, a Distribution Source MUST NOT report jitter distribution values for at least 2 reporting intervals after a payload type change occurs.

タイムスタンプユニットがペイロード型特異的であるため、ジッタ値の関連性は、セッション中にペイロードタイプの変化によって影響されます。ペイロードタイプの変更が発生した後そのため、配布ソースには、少なくとも2の報告間隔でジッタ分布値を報告してはなりません。

7.1.6. Round-Trip Time Sub-Report Block
7.1.6. 往復時間サブレポートブロック

A Round-Trip Time sub-report indicates the distribution of round-trip times from the Distribution Source to the receivers, providing receivers with a global view of the range of values in the group. The Distribution Source is capable of calculating the round-trip time to any other member since it forwards all the SR packets from the Media Sender(s) to the group. If the Distribution Source is not itself a Media Sender, it can calculate the round-trip time from itself to any of the receivers by maintaining a record of the SR sender timestamp and the current time as measured from its own system clock. The Distribution Source consequently calculates the round-trip time from the Receiver Report by identifying the corresponding SR timestamp and subtracting the RR advertised holding time as reported by the receiver from its own time difference measurement, as calculated by the time the RR packet is received and the recorded time the SR was sent.

ラウンドトリップタイムのサブレポートは、グループ内の値の範囲をグローバルな視野で受信機を提供し、受信機への配布ソースからの往復時間の分布を示しています。配布ソースは、それがグループにメディア送信者(複数可)からのすべてのSRパケットを転送するため、他のメンバーへの往復時間を算出することが可能です。配布ソースのメディア送信者自身でない場合は、SRの送信元のタイムスタンプを記録し、独自のシステム・クロックから測定されるように、現在の時刻を維持することによって、自分自身からの受信機のいずれかに往復時間を計算することができます。配信元は、結果的にRRパケットが受信される時間によって計算され、それ自身の時間差測定から受信機によって報告される保持時間とアドバタイズ対応SRタイムスタンプを識別し、RRを減算することによって受信レポートから往復時間を算出します記録時間は、SRが送信されました。

The Distribution Source has the option of distributing these round-trip time estimations to the whole group, uses of which are described in Section 7.4. The round-trip time is expressed in units of 1/65536 seconds and indicates an absolute value. This is calculated by the Distribution Source, based on the Receiver Report responses declaring the time difference since an original Sender Report and on the holding time at the receiver. The minimum distribution value MUST always be less than the maximum. The Round-Trip Time sub-report block type (SRBT) is 6.

配布ソースがグループ全体にこれらの往復時間の推定を配布するオプションがあり、その使用は、7.4節で説明されています。往復時間は1/65536秒の単位で表さ絶対値を示しています。これは、元の送信者の報告書以来と受信機での保持時間の時間差を宣言受信レポートの応答に基づいて、配布ソースで計算されます。最小分布値は常に最大値未満でなければなりません。ラウンドトリップタイムのサブレポートブロックタイプ(SRBT)は6です。

Note that if the Distribution Source and the Feedback Target functions are disjoint, it is only possible for the Distribution Source to determine RTT if all the Feedback Targets forward all RTCP reports from the receivers immediately (i.e., do not perform any preliminary summarization) and include at least the RR packet.

配布ソースおよびフィードバック目標関数が互いに素である場合、すべてのRTCPはすぐに受信機からの報告(すなわち、任意の予備的な集約を実行しない)とが含ま前方すべてのフィードバック目標ならば、それはRTTを決定するために、配布ソースに対してのみ可能であることに注意してくださいRRパケット少なくとも。

7.1.7. Cumulative Loss Sub-Report Block
7.1.7. 累積損失サブレポートブロック

The cumulative loss field in a Receiver Report [1], in contrast to the fraction lost field, is intended to provide some historical perspective on the session performance, i.e., the total number of lost packets since the receiver joined the session. The cumulative loss value provides a longer-term average by summing over a larger sample set (typically the whole session). The Distribution Source MAY record the values as reported by the receiver group and report a distribution of values. Values are expressed as a fixed-point number with the binary point at the left edge of the field, in the same manner as the Loss sub-report block. Since the individual Receiver Reports give the cumulative number of packets lost but not the cumulative number sent, which is required as a denominator to calculate the long-term fraction lost, the Distribution Source MUST maintain a record of the cumulative number lost and extended highest sequence number received, as reported by each receiver at some point in the past. Ideally, the recorded values are from the first report received. Subsequent calculations are then based on (<the new cumulative loss value> - <the recorded value>) / (<new extended highest sequence number> - <recorded sequence number>).

レシーバレポート[1]における累積損失フィールドは、画分失われたフィールドとは対照的に、セッションのパフォーマンス、すなわち、受信機はセッションに参加しましたので、失われたパケットの合計数にいくつかの歴史的な視点を提供することを目的とします。累積損失値は、より大きなサンプルセット(典型的には、全体のセッション)上で加算することにより長期的な平均を提供します。配布ソースは受信グループにより報告された値を記録し、値の分布を報告することがあります。値は損失サブレポートブロックと同様に、フィールドの左端にバイナリ点を有する固定小数点数として表されます。個々のレシーバレポートが失われ、長期的な割合を計算する分母として必要とされる累積損失したパケットの数ではなく、送信された累積数を与えるので、配布ソースは累積数失い、拡張された最大シーケンスの記録を維持しなければなりません過去のある時点で、各受信機によって報告されているように番号が、受信しました。理想的には、記録された値は、受信した最初のレポートからです。次の計算は、次に基づいている(<新たな累積損失値> - <記録値>)/(<新しい拡張最高シーケンス番号> - <記録されたシーケンス番号>)。

Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. The Cumulative Loss sub-report block type (SRBT) is 7.

255最小分散値が常に最大値未満でなければならない - 同様に、最大分散値フィールドの有効な結果が1である254 - 最小分散値フィールドの有効な結果は0です。累積損失サブレポートブロックタイプ(SRBT)は7です。

7.1.8. Feedback Target Address Sub-Report Block
7.1.8. フィードバック目標住所サブレポート・ブロック

The Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. If a block of this type is included, receivers MUST override any static SDP address information for the session with the Feedback Target address provided in this sub-report block.

フィードバック目標アドレスブロックは、受信機の代替ユニキャストRTCPフィードバックアドレスをシグナリングする配信元のための動的機構を提供します。この種のブロックが含まれている場合、受信機はこのサブレポートブロックに設けられたフィードバック目標アドレスを持つセッションのための任意の静的SDPアドレス情報をオーバーライドする必要があります。

If a Feedback Target Address sub-report block is used, it MUST be included in every RTCP packet originated by the Distribution Source to ensure that all receivers understand the information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late session arrivals.

フィードバック目標住所サブレポートブロックを使用する場合は、すべての受信機が情報を理解していることを保証するために、配布ソースによって発信すべてのRTCPパケットに含まれなければなりません。このように、受信機の動作はしても、パケットロス時や後半のセッション到着があるの顔に一貫している必要があります。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRBT={0,1,2}  |     Length    |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            Address                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

SRBT: 8 bits The type of sub-report block that corresponds to the type of address is as follows:

SRBT:8ビットアドレスのタイプに対応するサブレポートブロックの種類は以下の通りです。

         0: IPv4 address
         1: IPv6 address
         2: DNS name
        

Length: 8 bits The length of the sub-report block in 32-bit words. For an IPv4 address, this should be 2 (i.e., total length = 4 + 4 = 2 * 4 octets). For an IPv6 address, this should be 5. For a DNS name, the length field indicates the number of 32-bit words making up the string plus 1 byte and any additional padding required to reach the next word boundary.

長さ:8ビット、32ビットワード内のサブレポートブロックの長さ。 IPv4アドレスの場合、これは2(すなわち、全長= 4 + 4 = 2つの* 4オクテット)であるべきです。 IPv6アドレスの場合、これはDNS名5.である必要があり、長さフィールドは、文字列、プラス1つのバイトと次の単語境界に到達するために必要な追加のパディングを構成する32ビット・ワードの数を示します。

Port: 2 octets The port number to which receivers send feedback reports. A port number of 0 is invalid and MUST NOT be used.

ポート:2つのオクテットの受信機は、フィードバックレポートを送信するポート番号。 0のポート番号が無効であり、使用してはいけません。

Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) The address to which receivers send feedback reports. For IPv4 and IPv6, fixed-length address fields are used. A DNS name is an arbitrary-length string that is padded with null bytes to the next 32-bit boundary. The string MAY contain Internationalizing Domain Names in Applications (IDNA) domain names and MUST be UTF-8 encoded [11].

住所:4つのオクテット(IPv4)の、16個のオクテット(IPv6)の、あるいはnオクテット(DNS名)アドレスは受信機がフィードバックレポートを送信します。 IPv4とIPv6のために、固定長のアドレスフィールドが使用されています。 DNS名は、次の32ビット境界にヌルバイトでパディングされ、任意の長さの文字列です。文字列は、アプリケーション(IDNA)ドメイン名に国際化ドメイン名を含んでいてもよく、UTF-8エンコードされた[11]でなければなりません。

A Feedback Target Address block for a certain address type (i.e., with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once within a packet. Numerical Feedback Target Address blocks for IPv4 and IPv6 MAY both be present. If so, the resulting transport addresses MUST point to the same logical entity.

特定のアドレスの種類のフィードバック目標アドレスブロック(すなわち、0の特定のSRBTと、1、又は2)パケット内で複数回発生してはいけません。 IPv4とIPv6の数値フィードバック目標アドレスブロックは両方存在しているかもしれません。その場合、結果のトランスポート・アドレスは、同じ論理エンティティを指す必要があります。

If a Feedback Target address block with an SRBT indicating a DNS name is present, there SHOULD NOT be any other numerical Feedback Target Address blocks present.

DNS名を示すSRBTとフィードバック目標アドレスブロックが存在する場合、他の数値フィードバック目標アドレスブロックが存在すべきではありません。

The Feedback Target Address presents a significant security risk if accepted from unauthenticated RTCP packets. See Sections 11.3 and 11.4 for further discussion.

認証されていないRTCPパケットから受け入れた場合のフィードバック先アドレスは、重大なセキュリティ上のリスクを提示します。セクション11.3とさらなる議論のために11.4を参照してください。

7.1.9. Collision Sub-Report Block
7.1.9. 衝突サブレポート・ブロック

The Collision SSRC sub-report provides the Distribution Source with a mechanism to report SSRC collisions amongst the group. In the event that a non-unique SSRC is discovered based on the tuple [SSRC, CNAME], the collision is reported in this block and the affected nodes must reselect their respective SSRC identifiers.

衝突SSRCサブレポートは、グループ間でSSRC衝突を報告するメカニズムを持つディストリビューションソースを提供します。非固有のSSRCをタプル[SSRC、CNAME]に基づいて発見された場合に、衝突がこのブロックで報告され、影響を受けたノードは、それぞれのSSRC識別子を再選択しなければなりません。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SRBT=8    |    Length     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                         Collision SSRC                        :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Collision SSRC: n * 32 bits This field contains a list of SSRCs that are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC; however, since receivers in an SSM session using the Distribution Source Feedback Summary Model no longer have a global view of the session, the collision algorithm is handled by the Distribution Source. SSRCs that collide are listed in the packet. Each Collision SSRC is reported only once for each collision detection. If more Collision SSRCs need to be reported than fit into an MTU, the reporting is done in a round robin fashion so that all Collision SSRCs have been reported once before the second round of reporting starts. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC, if the collision pertains to them.

衝突SSRC:N * 32ビットをこのフィールドには、グループ内で重複しているSSRCsのリストを含みます。通常、これは、同じSSRCを検出したときにホストによって処理されます。もはや配布ソースフィードバックの概要モデルを使用してSSMセッションで受信機がセッションのグローバルな視野を持っているのでしかし、衝突アルゴリズムは、配布ソースによって処理されます。衝突SSRCsは、パケット内に記載されています。各衝突SSRCは一度だけ、各衝突検出のために報告されます。より多くの衝突SSRCsは、MTUにフィットよりも報告する必要がある場合は、すべての衝突SSRCsが開始を報告する第二ラウンドの前に一度報告されているように、報告は、ラウンドロビン方式で行われます。衝突は、それらに関係する場合は、パケットを受信すると、受信機(複数可)、衝突を検出し、別のSSRCを選択する必要があります。

The Collision sub-report block type (SRBT) is 8.

衝突サブレポートブロックタイプ(SRBT)は8です。

Collision detection is only possible at the Distribution Source. If the Distribution Source and Feedback Target functions are disjoint and collision reporting across RTP receiver SSRCs shall be provided, the Feedback Targets(s) MUST forward the RTCP reports from the RTP receivers, including at least the RR and the SDES packets to the Distribution Source.

衝突検出は、配布元でのみ可能です。配信元とフィードバック目標関数は互いに素であり、RTP受信SSRCs横切っ報告衝突が提供されなければならない場合、フィードバック標的(単数または複数)は配信元に少なくともRRとSDESパケットを含む、RTCPは、RTP受信機からの報告転送しなければなりません。

In system settings in which, by explicit configuration or implementation, RTP receivers are not going to act as Media Senders in a session (e.g., for various types of television broadcasting), SSRC collision detection MAY be omitted for RTP receivers. In system settings in which an RTP receiver MAY become a Media Sender (e.g., any conversational application), SSRC collision detection MUST be provided for RTP receivers.

、明示的な構成や実装によって、RTP受信機は、(テレビ放送の様々なタイプのために、例えば)のセッションでメディア差出人として機能するつもりはないされているシステム設定では、SSRC衝突検出は、RTP受信機のために省略されるかもしれません。 RTP受信機がメディア送信元になる可能性のあるシステム設定(例えば、任意の会話型アプリケーション)において、SSRC衝突検出は、RTP受信機のために提供されなければなりません。

Note: The purpose of SSRC collision reporting is to ensure unique identification of RTCP entities. This is of particular relevance for Media Senders so that an RTP receiver can properly associate each of the multiple incoming media streams (via the Distribution Source) with the correct sender. Collision resolution for Media Senders is not affected by the Distribution Source's collision reporting because all SR reports are always forwarded among the senders and to all receivers. Collision resolution for RTP receivers is of particular relevance for those receivers capable of becoming a Media Sender. RTP receivers that will, by configuration or implementation choice, not act as a sender in a particular RTP session, do not necessarily need to be aware of collisions as long as the those entities receiving and processing RTCP feedback messages from the receivers are capable of disambiguating the various RTCP receivers (e.g., by CNAME).

注意:SSRC衝突報告の目的は、RTCPエンティティの一意の識別を確実にするためです。 RTP受信機が正しく正しい送信者(配信元を介して)複数の入力メディアストリームの各々を関連付けることができるように、これは、メディア送信者のために特に重要です。すべてのSRレポートは常に送信者の間で、すべての受信者に転送されるため、メディアの送信者のための衝突解決は、配信元の衝突の報告に影響されません。 RTP受信機のための衝突解決は、メディア送信者となり得るものの受信機のために特に適切です。それらのエンティティが受信し、受信機からの処理RTCPフィードバックメッセージは、曖昧さをなくすことができるよう、構成や実装の選択によって、特定のRTPセッションでは、送信者として機能しませんRTP受信機は、必ずしも限り衝突を意識する必要はありません様々なRTCP受信機(例えば、CNAMEによります)。

Note also that RTP receivers should be able to deal with the changing SSRCs of a Media Sender (like any RTP receiver has to do.) and, if possible, be prepared to continuously render a media stream nevertheless.

注また、そのRTP受信機は、(任意のRTP受信機が関係しているように。)メディア送信者の変更SSRCsに対処することができるはずと、可能な場合は、連続してそれにもかかわらず、メディアストリームをレンダリングするために準備すること。

7.1.10. General Statistics Sub-Report Block
7.1.10. 一般的な統計サブレポート・ブロック

The General Statistics sub-report block is used if specifying buckets is deemed too complex. With the General Statistics sub-report block, only aggregated values are reported back. The rules for the generation of these values are provided in point b of Section 7.2.1.

バケットを指定すると、複雑すぎると判断される場合の一般的な統計サブレポートのブロックが使用されています。一般的な統計サブレポートブロックでは、唯一の集計値が戻って報告されています。これらの値の生成のための規則は、セクション7.2.1のb点に設けられています。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=10    |    Length     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MFL      |                    HCNL                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Median inter-arrival jitter                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Median fraction lost (MFL): 8 bits The median fraction lost indicated by Receiver Reports forwarded to this Distribution Source, expressed as a fixed-point number with the binary point at the left edge of the field. A value of all '1's indicates that the MFL value is not provided.

メジアン画分は(MFL)を失った:この配信元に転送レシーバレポートで示す8ビットのメジアン割合が失われたが、フィールドの左端にバイナリポイントと固定小数点数として表されます。すべての「1 'の値は、MFL値が提供されていないことを示しています。

Highest cumulative number of packets lost (HCNL): 24 bits Highest 'cumulative number of packets lost' value out of the most recent RTCP RR packets from any of the receivers. A value of all '1's indicates that the HCNL value is not provided.

24ビット最高の受信機のいずれかから最も最近のRTCP RRパケットのタイムアウト値を「パケットの累積数が失わ」:パケットの最大累積数(HCNL)を失いました。すべての「1 'の値がHCNL値が提供されていないことを示しています。

Median inter-arrival jitter: 32 bits Median 'inter-arrival jitter' value out of the most recent RTCP RR packets from the receiver set. A value of all '1's indicates that this value is not provided.

メディアン到着間ジッタ:受信機のセットからの最も最近のRTCP RRパケットのうち32ビットの中央値「到着間ジッタ」値。すべての「1 'の値は、この値が提供されていないことを示しています。

The General Statistics sub-report block type (SRBT) is 10.

一般的な統計サブレポートのブロックタイプ(SRBT)が10です。

Note that, in case the Distribution Source and the Feedback Target functions are disjoint, it is only possible for the Distribution Source to determine the median of the inter-arrival jitter if all the Feedback Targets forward all RTCP reports from the receivers immediately and include at least the RR packet.

ケースには配布ソースおよびフィードバック目標関数は互いに素で前方すべてのフィードバック目標は、すべてのRTCPはすぐに受信機からの報告とに含まれている場合、到着間ジッタの中央値を決定するために配布ソースに対してのみ可能である、ということに注意してください少なくともRRパケット。

7.1.11. RTCP Bandwidth Indication Sub-Report Block
7.1.11. RTCP帯域幅の表示サブレポートブロック

This sub-report block is used to inform the Media Senders and receivers about either the maximum RTCP bandwidth that is supposed to be used by each Media Sender or the maximum bandwidth allowance to be used by each receiver. The value is applied universally to all Media Senders or all receivers. Each receiver MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. Conversely, each Media Sender MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself.

このサブレポートブロックは、各メディアの送信者または各受信機によって使用される最大帯域幅の余裕によって使用されることになっている最大RTCP帯域幅のいずれかに関するメディア送信側と受信側に通知するために使用されます。値は、すべてのメディアの送信者またはすべての受信機に普遍的に適用されます。各受信機は、それ自体によって送信されたRTCPパケットの平均サイズ上のRTCP送信間隔算出の基礎としなければなりません。逆に、各メディアの送信者は、自身が送信されたRTCPパケットの平均サイズ上のRTCP送信間隔算出の基礎としなければなりません。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=11    |     Length    |S|R|         Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTCP Bandwidth                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Sender (S): 1 bit The contained bandwidth value applies to each Media Sender.

送信者(S):1ビットに含まれる帯域幅の値は、各メディアの送信者に適用されます。

Receivers (R): 1 bit The contained bandwidth value applies to each RTP receiver.

受信器(R)に含まれる帯域幅の値は、各RTP受信機に適用される1ビット。

Reserved: 14 bits MUST be set to zero upon transmission and ignored upon reception.

予約:14ビットは、送信時にゼロに設定し、受信時に無視しなければなりません。

RTCP Bandwidth: 32 bits If the S bit is set to 1, this field indicates the maximum bandwidth allocated to each individual Media Sender. This also informs the receivers about the RTCP report frequency to expect from the senders. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536.

RTCP帯域幅:Sビットが1に設定されている32ビットの場合、このフィールドは、個々のメディア送信元に割り当てられた最大帯域幅を示しています。また、これは送信者から期待するRTCPレポートの頻度についての受信機に通知します。これは、第2および第3のバイトの間でバイナリポイントと固定小数点値です。値が範囲内の値が0 <= BW <65536で、毎秒キロビットで受信当たり帯域幅割り当てを表します。

If the R bit is set to 1, this field indicates the maximum bandwidth allocated per receiver for sending RTCP data relating to the session. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536. Each receiver MUST use this value for its bandwidth allowance.

Rビットが1に設定されている場合、このフィールドは、セッションに関連するRTCPデータを送信するための受信機ごとに割り当てられた最大帯域幅を示しています。これは、第2および第3のバイトの間でバイナリポイントと固定小数点値です。値が範囲内の値が0 <= BW <65536各受信機は、その帯域幅の余裕のためにこの値を使用しなければならないと、毎秒キロビットで受信当たり帯域幅割り当てを表します。

This report block SHOULD only be used when the Group and Average Packet Size sub-report block is NOT included. The RTCP Bandwidth Indication sub-report block type (SRBT) is 11.

グループと平均パケットサイズのサブレポートブロックが含まれていない場合は、このレポートブロックにのみ使用してください。 RTCP帯域幅表示サブレポートブロックタイプ(SRBT)は11です。

7.1.12. RTCP Group and Average Packet Size Sub-Report Block
7.1.12. RTCPグループと平均パケットサイズのサブレポートブロック

This sub-report block is used to inform the Media Senders and receivers about the size of the group (used for calculating feedback bandwidth allocation) and the average packet size of the group. This sub-report MUST always be present, appended to every RSI packet, unless an RTCP Bandwidth Indication sub-report block is included (in which case it MAY, but need not, be present).

このサブレポートブロックは、グループの平均パケットサイズ(フィードバック帯域幅割り当てを計算するために使用される)グループの大きさに関するメディア送信側と受信側に通知するために使用されます。 RTCP帯域幅表示サブレポートブロックが含まれていない限り、このサブレポートは常に(それが、そうである必要はない。その場合に、存在する)、すべてのRSIパケットに付加され、存在していなければなりません。

Note: The RTCP Bandwidth Indication sub-report block allows the Distribution Source to hide the actual group size from the receivers while still avoiding feedback implosion.

注意:RTCP帯域幅表示のサブレポートブロックは、まだフィードバック爆縮を回避しながら、配布元が受信機からの実際のグループサイズを非表示にすることができます。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=12    |    Length     |     Average Packet Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Receiver Group Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Group size: 32 bits This field provides the Distribution Source's view of the number of receivers in a session. Note that the number of Media Senders is not explicitly reported since it can be derived by observing the RTCP SR packets forwarded by the Distribution Source. The group size is calculated according to the rules outlined in [1]. When this sub-report block is included, this field MUST always be present.

グループサイズ:32ビットこのフィールドは、セッション内の受信機の数の配布ソースのビューを提供します。それは配布ソースによって転送RTCP SRパケットを観察することによって求めることができるので、メディア送信者の数が明示的に報告されていないことに注意してください。グループサイズは、[1]に概説されたルールに従って計算されます。このサブレポートブロックが含まれている場合、このフィールドは常に存在しなければなりません。

Average RTCP packet size: 16 bits This field provides the Distribution Source's view of the average RTCP packet size as locally calculated, following the rules defined in [1]. The value is an unsigned integer, counting octets. When this sub-report block is included, this field MUST always be present.

平均RTCPパケットサイズ:16ビットこのフィールドはとして局所的に[1]で定義された規則に従って、計算された平均RTCPパケットサイズの配信元のビューを提供します。値は、オクテットカウント、符号なし整数です。このサブレポートブロックが含まれている場合、このフィールドは常に存在しなければなりません。

The Group and Average Packet Size sub-report block type (SRBT) is 12.

グループと平均パケットサイズのサブレポートブロックタイプ(SRBT)は12です。

7.2. Distribution Source Behavior
7.2. 配布元挙動

In the Distribution Source Feedback Summary Model, the Distribution Source (the unicast Feedback Target) MUST listen for unicast RTCP packets sent to the RTCP port. All RTCP packets received on this port MUST be processed by the Distribution Source, as described below. The processing MUST take place per Media Sender SSRC for which Receiver Reports are received.

配布ソースフィードバックの概要モデルでは、配布ソース(ユニキャストフィードバック目標は)RTCPポートに送信されたユニキャストRTCPパケットをリッスンする必要があります。後述のように、このポートで受信したすべてのRTCPパケットは、配布ソースによって処理しなければなりません。処理は、レシーバレポートが受信されるメディアの送信者SSRCごとに行わなければなりません。

The Distribution Source acts like a regular RTCP receiver. In particular, it receives an RTP stream from each RTP Media Sender(s) and MUST calculate the proper reception statistics for these RTP streams. It MUST transmit the resulting information as report blocks contained in each RTCP packet it sends (in an RR packet).

配布ソースは、通常のRTCP受信機のような役割を果たします。特に、各RTPメディア送信者(複数可)からRTPストリームを受信し、これらのRTPストリームのために適切な受信統計値を計算しなければなりません。それは(RRパケットに)送信する各RTCPパケットに含まれるレポートブロックとして得られた情報を送信しなければなりません。

Note: This information may help to determine the transmission characteristics of the feed path from the RTP sender to the Distribution Source (if these are separate entities).

注:この情報は、(これらは別々のエンティティである場合)、配布元にRTP送信側から搬送路の伝送特性を決定するのに役立ち得ます。

The Distribution Source is responsible for accepting RTCP packets from the receivers and for interpreting and storing per-receiver information, as defined in [1]. The importance of providing these

配信元は、で定義されるように、受信機からのRTCPパケットを受け入れるためと解釈しごとの受信情報を格納する責任がある[1]。これらを提供することの重要性

functions is apparent when creating the RSI and sub-report block reports since incorrect information can have serious implications. Section 11 addresses the security risks in detail.

誤った情報が深刻な影響を持つことができるので、RSIとサブレポートのブロックのレポートを作成する際の機能は明らかです。第11節は、詳細なセキュリティリスクに対応しています。

As defined in [1], all RTCP reports from the Distribution Source MUST start with an RR report, followed by any relevant SDES fields. Then the Distribution Source MUST append an RSI header and sub-reports containing any summarization-specific data. In addition, either the Group and Average Packet Size sub-report or the Receiver RTCP Bandwidth sub-report block MUST be appended to the RSI header.

で定義されているように、[1]、配布ソースからのすべてのRTCPレポートは、関連するすべてのSDESフィールドに続くRRレポート、で開始する必要があります。次に、配信元は、RSIヘッダと任意要約固有のデータを含むサブレポートを追加しなければなりません。また、グループと平均パケットサイズのサブレポートまたはReceiver RTCP帯域幅のサブレポートブロックのいずれかがRSIヘッダに付加されなければなりません。

A Distribution Source has the option of masking the group size by including only an RTCP Bandwidth sub-report. If both sub-reports are included, the receiver is expected to give precedence to the information contained in the Receiver RTCP Bandwidth sub-report.

配布ソースのみRTCP帯域幅のサブレポートを含むことにより、グループサイズをマスキングするオプションがあります。両方のサブレポートが含まれている場合は、受信機は、受信側RTCP帯域幅のサブレポートに含まれる情報に優先権を与えることが期待されます。

The Receiver RTCP Bandwidth sub-report block provides the Distribution Source with the capability to control the amount of feedback from the receivers, and the bandwidth value MAY be increased or decreased based upon the requirements of the Distribution Source. Regardless of the value selected by the Distribution Source for the Receiver RTCP Bandwidth sub-report block, the Distribution Source MUST continue to forward Sender Reports and RSI packets at the rate allowed by the total RTCP bandwidth allocation. See Section 9 for further details about the frequency of reports.

レシーバRTCP帯域幅のサブレポートブロックが受信機からのフィードバックの量を制御する機能を備えた配信元を提供し、帯域幅の値を増加させることができる、または配信元の要件に基づいて減少します。かかわらず、受信側RTCP帯域幅のサブレポートのブロックのための配信元で選択された値の、配布ソースは、全RTCP帯域幅割り当てによって許可されたレートで送信者レポートとRSIパケットを転送し続けなければなりません。レポートの頻度についての詳細は、セクション9を参照してください。

A Distribution Source MAY start out reporting group size and switch to Receiver RTCP Bandwidth reporting later on and vice versa. If the Distribution Source does so, it SHOULD ensure that the correspondingly indicated values for the Receiver RTCP Bandwidth sub-report roughly match, i.e., are at least the same order of magnitude.

配布ソースは、グループのサイズを報告して起動し、レシーバRTCP帯域幅は、後に報告し、その逆に切り替えることができます。配信元は、そうしなければ、それは受信RTCP帯域幅のサブレポートの対応示す値が略一致していることを確認する必要があり、即ち、大きさの少なくとも同じオーダーです。

In order to identify SSRC collisions, the Distribution Source is responsible for maintaining a record of each SSRC and the corresponding CNAME within at least one reporting interval by the group, in order to differentiate between clients. It is RECOMMENDED that an updated list of more than one interval be maintained to increase accuracy. This mechanism should prevent the possibility of collisions since the combination of SSRC and CNAME should be unique, if the CNAME is generated correctly. If collisions are not detected, the Distribution Source will have an inaccurate impression of the group size. Since the statistical probability is very low that collisions will both occur and be undetectable, this should not be a significant concern. In particular, the clients would have to randomly select the same SSRC and have the same username + IP address (e.g., using private address space behind a NAT router).

SSRCの衝突を識別するために、配信元は、クライアントを区別するために、グループが少なくとも一つの報告間隔内に各SSRC及び対応するCNAMEの記録を維持する責任があります。複数の間隔の更新リストは、精度を高めるために維持することが推奨されます。 CNAMEが正しく生成されている場合SSRC及びCNAMEの組み合わせは、ユニークでなければなりませんので、このメカニズムは、衝突の可能性を防ぐ必要があります。衝突が検出されない場合は、配布ソースは、グループサイズの不正確な印象を持っています。統計的確率は、衝突が発生し、検出できないだろう、両方のことが非常に低いので、これは大きな問題ではありません。具体的には、クライアントがランダムに(例えば、NATルータの背後にあるプライベートアドレス空間を使用して)同じSSRCを選択し、同じユーザー名+ IPアドレスを持っている必要があります。

7.2.1. Receiver Report Aggregation
7.2.1. 受信レポート集計

The Distribution Source is responsible for aggregating reception-quality information received in RR packets. In doing so, the Distribution Source MUST consider the report blocks received in every RR packet and MUST NOT consider the report blocks of an SR packet.

配布ソースは、RRパケットで受信した受信品質の情報を集約する責任があります。そうすることで、配布ソースは、すべてのRRパケットで受信レポートブロックを考慮しなければならないとSRパケットのレポートブロックを検討してはなりません。

Note: the receivers will get the information contained in the SR packets anyway by packet forwarding, so duplication of this information should be avoided.

注:受信機は、パケット転送により、とにかくSRパケットに含まれる情報を取得しますので、この情報の重複は避けるべきです。

For the optional sub-report blocks, the Distribution Source MAY decide which are the most significant feedback values to convey and MAY choose not to include any. The packet format provides flexibility in the amount of detail conveyed by the data points. There is a tradeoff between the granularity of the data and the accuracy of the data based on the multiplicative factor (MF), the number of buckets, and the min and max values. In order to focus on a particular region of a distribution, the Distribution Source can adjust the minimum and maximum values and either increase the number of buckets, and possibly the factorization, or decrease the number of buckets and provide more accurate values. See Appendix B for detailed examples on how to convey a summary of RTCP Receiver Reports as RSI sub-report block information.

オプションのサブレポートブロックの場合は、配布ソースは伝えるために、あらゆるを含めないことを選択することができる最も重要なフィードバック値であることを決定することができます。パケットフォーマットは、データ点によって搬送ディテールの量の柔軟性を提供します。データの粒度と乗法因子(MF)、バケットの数に基づいて、データの正確性、および最小値と最大値との間のトレードオフが存在します。分布の特定の領域に集中するために、配信元は、最小値と最大値を調整することができ、バケットの数を増やし、そしておそらく分解、又はバケットの数を減少させ、より正確な値を提供するいずれか。 RSIサブレポートブロック情報としてRTCPレシーバレポートの概要を伝える方法についての詳細な例については、付録Bを参照してください。

For each value the Distribution Source decides to include in an RSI packet, it MUST adhere to the following measurement rules.

配信元は、RSIパケットに含めることを決定した各値について、以下の測定ルールに従わなければなりません。

a) If the Distribution Source intends to use a sub-report to convey a distribution of values (Sections 7.1.3 to 7.1.7), it MUST keep per-receiver state, i.e., remember the last value V reported by the respective receiver. If a new value is reported by a receiver, the existing value MUST be replaced by the new one. The value MUST be deleted (along with the entire entry) if the receiver is timed out (as per Section 6.3.5 of [1]) or has sent a BYE packet (as per Section 6.3.7 of [1]).

a)の配布元が値(セクション7.1.3 7.1.7まで)の分布を伝えるために、サブレポートを使用しようとするならば、それごとの受信状態を維持しなければならない、すなわち、それぞれの受信機によって報告された最後の値Vを覚えています。新しい値が受信機によって報告された場合、既存の値は新しいものに交換する必要があります。受信機は、([1]のセクション6.3.5に従って)タイムアウトしているか([1]のセクション6.3.7による)BYEパケットを送信した場合、この値は(全体のエントリと一緒に)削除しなければなりません。

       All the values collected in this way MUST be included in the
       creation of the subsequent Distribution sub-report block.
        

The results should correspond as closely as possible to the values received during the interval since the last report. The Distribution Source may stack as many sub-report blocks as required in order to convey different distributions. If the distribution size exceeds the largest packet length (1008 bytes data portion), more packets MAY be stacked with additional information (but in total SHOULD NOT exceed the path MTU).

結果は、最後の報告以降の間隔の間に受信した値に可能な限り厳密に対応しなければなりません。異なる分布を伝えるために、必要に応じて配布ソースは、多くのサブレポートブロックを積み重ねることがあります。分布のサイズが最大パケット長(1008バイトのデータ部)を超えた場合、より多くのパケットは、追加情報を積み重ねることができる(ただし、合計パスMTUを超えてはなりません)。

All stacked sub-reports MUST be internally consistent, i.e., generated from the same session data. Overlapping of distributions is therefore allowed, and variation in values should only occur as a result of data set granularity, with the more accurate bucket sizes taking precedence in the event that values differ. Non-divisible values MUST be rounded up or down to the closest bucket value, and the number of data buckets must always be an even number, padding where necessary with an additional zero bucket value to maintain consistency.

全ての積層サブレポートは、同じセッション・データから生成された、すなわち、内部的に一貫していなければなりません。分布の重なりは、従って許可され、値の変化は、値が異なる場合に優先して、より正確なバケットサイズで、粒度のデータセットの結果として生じるべきです。非割り切れる値は切り上げまたは最も近いバケット値まで、データバケットの数は、常に一貫性を維持するために必要な追加ゼロバケット値と偶数、パディングでなければなりません。

Note: This intentionally provides persistent full coverage of the entire session membership to avoid oscillations due to changing membership samples.

注意:これは意図的に変更、メンバーシップサンプルに起因する振動を避けるために、セッション全体のメンバシップの永続的な完全なカバレッジを提供します。

Scheduling the transmission of summarization reports is left to the discretion of the Distribution Source. However, the Distribution Source MUST adhere to the bandwidth limitations for Receiver Reports as defined for the respective AV profile in use.

要約レポートの送信をスケジューリングすることは配布ソースの裁量に任されています。使用中のそれぞれのAVプロファイル用に定義されているようしかし、配布ソースは、レシーバレポートの帯域幅の制限に従わなければなりません。

b) If the Distribution Source intends to report a short summary using the General Statistics sub-report block format, defined in Section 7.1.10, for EACH of the values included in the report (MFL, HCNL, average inter-arrival jitter), it MUST keep a timer T_summary as well as a sufficient set of variables to calculate the summaries for the last three reporting intervals. This MAY be achieved by keeping per-receiver state (i.e., remember the last value V reported by the respective receiver) or by maintaining summary variables for each of these intervals.

b)の配布ソースレポート(MFL、HCNL、平均到着間ジッタ)に含まれる値のそれぞれに対して、セクション7.1.10で定義された一般的な統計サブレポートブロックのフォーマットを使用して、短い概要を報告するつもりならば、それは最後の三つの報告間隔のための要約を計算するタイマーT_summaryだけでなく、変数の十分なセットを維持する必要があります。このごとの受信状態を維持することによって(すなわち、それぞれの受信機によって報告された最後の値Vを覚えている)、またはこれらの間隔の各々の要約変数を維持することによって達成することができます。

       The summary values are included here to reflect the current group
       situation.  By recording the last three reporting intervals, the
       Distribution Source incorporates reports from all members while
       allowing for individual RTCP Receiver Report packet losses.  The
       process of collecting these values also aims to avoid resetting
       any of the values and then having to send out an RSI report based
       upon just a few values collected.  If data is available for less
       than three reporting intervals (as will be the case for the first
       two reports sent), only those values available are considered.
        

The timer T_summary MUST be initialized as T_summary = 1.5 * Td, where Td is the deterministic reporting interval, and MUST be updated following timer reconsideration whenever the group size or the average RTCP size ("avg_rtcp_size") changes. This choice should allow each receiver to report once per interval.

タイマーT_summaryはTdが決定論レポート間隔で、タイマ再考するたびにグループのサイズや平均RTCPサイズ(「avg_rtcp_size」)の変更、次の更新されなければならないT_summary = 1.5 * Tdの、として初期化しなければなりません。この選択は、各受信機がインターバルごとに一度報告できるようにする必要があります。

            Td
           __^__
        t0/     \   t1        t2        t3        t4        t5
       ---+---------+---------+---------+---------+---------+------->
          \____ ____/         :         :         :         :
          :    V    :         :         :         :         :
          :T_summary:         :         :         :         :
          :=1.5 * Td:         :         :         :         :
          \______________ ______________/         :         :
                    :    V    :                   :         :
                    : 3 * T_summary               :         :
                    :         :                   :         :
                    \______________ ______________/         :
                              :    V                        :
                              : 3 * T_summary               :
                              :                             :
                              \______________ ______________/
                                             V
                                          3 * T_summary
        

Figure 2: Overview of Summarization Reporting

図2:要約報告の概要

Figure 2 depicts how the summarization reporting shall be performed. At time t3, the RTCP reports collected from t0 through t3 are included in the RSI reporting; at time t4, those from t1 through t4; and so on. The RSI summary report sent MUST NOT include any RTCP report from more than three reporting intervals ago, e.g., the one sent at time t5, must not include reports received at the Distribution Source prior to t2.

図2は、要約報告が行われなければならない方法を示しています。時刻t3において、T3を通じてT0から収集されたRTCPレポートは報告RSIに含まれています。時刻t4において、T4を介しt1からのもの。等々。以上の3つの報告間隔前から任意のRTCPレポートを含めることはできません送信されRSIサマリレポートは、例えば、1は、時刻t5で送信され、レポートがt2の前の配信元で受信含めることはできません。

7.2.2. Handling Other RTCP Packets from RTP Receivers
7.2.2. RTPレシーバから他のRTCPパケットの処理

When following the Feedback Summary Model, the Distribution Source MAY reflect any other RTCP packets of potential relevance to the receivers (such as APP, RTPFB, PSFB) to the receiver group. Also, it MAY decide not to forward other RTCP packets not needed by the receivers such as BYE, RR, SDES (because the Distribution Source performs collision resolution), group size estimation, and RR aggregation. The Distribution Source MUST NOT forward RR packets to the receiver group.

フィードバック概要モデルを以下のときに、配信元は、受信機グループに(例えばAPP、RTPFB、PSFBなど)受信機への潜在的な関連性の他のRTCPパケットを反映することができます。また、そのような受信機が必要としない他のRTCPパケットを転送しないことを決定することができるBYE、RR、SDES、グループサイズの推定、およびRR凝集(配信元が衝突解決を行うため)。配布ソースは受信グループにRRパケットを転送してはなりません。

If the Distribution Source is able to interpret and aggregate information contained in any RTCP packets other than RR, it MAY include the aggregated information along with the RSI packet in its own compound RTCP packet.

配信元が解釈及びRR以外のRTCPパケットに含まれる情報を集約することが可能である場合、それはそれ自身の化合物RTCPパケットでRSIパケットと共に集約情報を含むことができます。

Aggregation MAY be a null operation, i.e., the Distribution Source MAY simply append one or more RTCP packets from receivers to the compound RTCP packet (containing at least RR, SDES, and RSI from the Distribution Source).

凝集は、すなわち、配信元は、単に受信機から(配信元から少なくともRR、SDES、及びRSIを含む)化合物RTCPパケットに一つ以上のRTCPパケットを付加MAY、ヌル操作であってもよいです。

Note: This is likely to be useful only for a few cases, e.g., to forward aggregated information from RTPFB Generic NACK packets and thereby maintain the damping property of [15].

注:これは、いくつかのケースのために有用である可能性がある、例えば、RTPFB汎用NACKパケットから集約された情報を転送することにより、[15]の減衰特性を維持します。

Note: This entire processing rule implies that the flow of information contained in non-RR RTCP packets may terminate at the Distribution Source, depending on its capabilities and configuration.

注:この全体の処理ルールは、非RRのRTCPパケットに含まれる情報の流れは、その機能と構成に応じて、配信元で終了することができることを意味します。

The configuration of the RTCP SSM media session (expressed in SDP) MUST specify explicitly which processing the Distribution Source will apply to which RTCP packets. See Section 10.1 for details.

(SDPで表される)RTCP SSMメディアセッションの構成は、配信元を処理したRTCPパケットに適用され、明示的に指定しなければなりません。詳細については、10.1節を参照してください。

7.2.3. Receiver Report Forwarding
7.2.3. 受信レポートの転送

If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST explicitly inform the Media Senders of the receiver group. To achieve this, the Distribution Source has two options: 1) it forwards the RTCP RR and SDES packets received from the receivers to the Media Sender(s); or 2) if the Media Senders also support the RTCP RSI packet, the Distribution Source sends the RSI packets not just to the receivers but also to the Media Senders.

メディア送信者(s)はRTCPパケット反射のためのSSMグループの一部でない場合は、配布ソースを明示的に受信グループのメディア送信者に通知しなければなりません。これを達成するために、配布ソースには2つのオプションがあります:1)それはRTCP RRとSDESパケットはメディア送信者(複数可)に受信機から受信した転送を。または2)メディア送信者はまた、RTCP RSIパケットをサポートしている場合、配布ソースは、メディア送信者の受信機にもするだけでなく、RSIパケットを送信します。

If the Distribution Source decides to forward RR and SDES packets unchanged, it MAY also forward any other RTCP packets to the senders.

配布ソースをそのままRRとSDESパケットを転送することを決定した場合、それはまた、送信者に、他のRTCPパケットを転送することができます。

If the Distribution Source decides to forward RSI packets to the senders, the considerations of Section 7.2.2 apply.

配布ソースが送信者にRSIパケットを転送することを決定した場合は、7.2.2項の考慮事項が適用されます。

7.2.4. Handling Sender Reports
7.2.4. 送信者レポートの取り扱い

The Distribution Source also receives RTCP (including SR) packets from the RTP Media Senders.

配布ソースもRTPメディア送信者からのRTCP(SR含む)パケットを受信します。

The Distribution Source MUST forward all RTCP packets from the Media Senders to the RTP receivers.

配布ソースは、RTP受信機にメディアの送信者からのすべてのRTCPパケットを転送する必要があります。

If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from any one Media Sender to all other Media Senders.

そこに複数のメディアSenderがあり、これらのメディアの送信者は配布ソースと相互にASMを介して通信していない場合は、配布ソースは、他のすべてのメディアの送信者へのいずれかのメディアの送信者から各RTCPパケットを転送する必要があります。

7.2.5. RTCP Data Rate Calculation
7.2.5. RTCPデータレートの計算

As noted above, the Distribution Source is a receiver from an RTP perspective. The Distribution Sources MUST calculate its deterministic transmission interval Td as every other receiver; however, it MAY adjust its available data rate depending on the destination transport address and its local operation:

上述したように、配信元は、RTPの観点から受信機です。配布ソースは他のすべての受信機としての確定的な送信間隔Tdとを計算しなければなりません。しかし、それは先のトランスポートアドレスとそのローカル操作に応じて利用可能なデータレートを調整することができます。

1. For sending its own RTCP reports to the SSM group towards the receivers, the Distribution Source MAY use up to the joint share of all receivers as it is forwarding summaries on behalf of all of them. Thus, the Distribution Source MAY send its reports up to every Td/R time units, with R being the number of receivers.

独自のRTCPを送信するために1.それはそれらのすべてを代表して要約を転送しているとして配布ソースがすべての受信機の共同株式まで使用でき、受信機に向けてSSMグループに報告します。したがって、配布ソースはRは、受信機の数であることと、すべてのTdの/ Rの時間単位までそのレポートを送信することができます。

2. For sending its own RTCP reports to the Media Senders only (i.e., if the Media Senders are not part of the SSM group), the allocated rate depends on the operation of the Distribution Source:

独自のRTCPを送信するために2.(すなわち、メディア送信者は、SSMグループの一部ではない場合)のみ、メディア送信者に報告し、割り当てられたレートは、配布ソースの操作に依存します。

a) If the Distribution Source only sends RSI packets along with its own RTCP RR packets, the same rate calculation applies as for #1 above.

配布ソースが唯一、独自のRTCP RRパケットとともにRSIパケットを送信する場合a)は、同じ速度の計算は、上記の#1の場合と同様に適用されます。

b) If the Distribution Source forwards RTCP packets from all other receivers to the Media Senders, then it MUST adhere to the same bandwidth share for its own transmissions as all other receivers and use the calculation as per [1].

配布ソースのメディア送信者へのすべての他の受信からRTCPパケットを転送する場合b)に、それは他のすべてのレシーバとして、自身の送信に同じ帯域幅の共有に付着し、に従って計算を使用しなければならない[1]。

7.2.6. Collision Resolution
7.2.6. 衝突解決

A Distribution Source observing RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1] and MUST do so immediately after noticing.

独自の選ばれたSSRCと衝突SSRCとメディアの送信者からのRTPパケットを観測配布ソースは[1]の手順に従って、自身のSSRCを変更する必要がありますし、すぐに気付いた後、そうしなければなりません。

A Distribution Source MAY use out-of-band information about the Media Sender SSRC(s) used in the media session when available to avoid SSRC collisions with Media Senders. Nevertheless, the Distribution Source MUST monitor Sender Report (SR) packets to detect any changes, observe collisions, and then follow the above collision-resolution procedure.

配布ソースは、メディア送信者とSSRCの衝突を避けるために、利用可能なメディアセッションで使用されるメディアの送信者SSRC(S)程度の帯域外の情報を使用するかもしれません。それにも関わらず、配布ソースは、任意の変更を検出衝突を観察し、その後、上記の衝突解決手順に従うことを送信者レポート(SR)パケットを監視しなければなりません。

For collision resolution between the Distribution Source and receivers or the Feedback Target(s) (if a separate entity, as described in the next subsection), the Distribution Source and the Feedback Target (if separate) operate similar to ordinary receivers.

配信元及び受信機又はフィードバックターゲット(複数可)(次のサブセクションで説明したように、別個のエンティティであれば)との間の衝突の解決のため、配信元とフィードバックターゲット(別個の場合)は、通常の受信機と同様に動作します。

7.3. Disjoint Distribution Source and Feedback Target
7.3. ばらばらの配布元とフィードバック目標

If the Distribution Source and the Feedback Target are disjoint, the processing of the Distribution Source is limited by the amount of RTCP feedback information made available by the Feedback Target.

配信元とフィードバック目標が互いに素である場合、配信元の処理は、フィードバック対象によって利用可能RTCPフィードバック情報の量によって制限されます。

The Feedback Target(s) MAY simply forward all RTCP packets incoming from the RTP receivers to the Distribution Source, in which case the Distribution Source will have all the necessary information available to perform all the functions described above.

フィードバック目標(S)は、単に前方全てRTCPパケットは、配信元は、上述したすべての機能を実行するために利用可能なすべての必要な情報を持っている場合には配信元のRTP受信機から着信MAY。

The Feedback Target(s) MAY also perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source. In this case, the Feedback Target(s) MUST use correctly formed RTCP packets to communicate with the Distribution Source and they MUST operate in concert with the Distribution Source so that the Distribution Source and the Feedback Target(s) appear to be operating as a single entity. The Feedback Target(s) MUST report their observed receiver group size to the Distribution Source, either explicitly by means of RSI packets or implicitly by forwarding all RR packets.

フィードバック目標(複数可)は、着信RTCPパケットの集約を行い、配信元にのみ集約情報を送信することができます。この場合、フィードバック目標(複数可)は配信元と通信するために正しく形成されたRTCPパケットを使用しなければならないし、配信元とフィードバックターゲット(複数可)として動作するように見えるようにそれらが配信元と協調して動作しなければなりません単一のエンティティ。フィードバックターゲット(複数可)は、明示的RSIパケットによって、または暗黙的にすべてのRRパケットを転送することによって、配信元への観察された受信グループ・サイズを報告しなければなりません。

Note: For example, for detailed statistics reporting, the Distribution Source and the Feedback Target(s) may need to agree on a common reporting granularity so that the Distribution Source can aggregate the buckets incoming from various Feedback Targets into a coherent report sent to the receivers.

注意:配布ソースがに送信されたコヒーレントレポートにさまざまなフィードバック目標から到来するバケットを集約することができるように、例えば、配布元とフィードバック目標(複数可)を報告して詳細な統計のための共通の報告粒度に同意する必要があるかもしれません受信機。

The joint behavior of the Distribution Source and Feedback Target(s) MUST be reflected in the (SDP-based) media session description as per Section 7.2.2.

配信元とフィードバックターゲット(S)の関節動作は、セクション7.2.2に従って(SDPベースの)メディアセッション記述に反映されなければなりません。

If the Feedback Target performs summarization functions, it MUST also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. The collision-resolution considerations for receivers apply.

フィードバック目標が要約機能を実行した場合、それはまた、受信機として機能し、配布ソースに向けた独自の報告のためのユニークなSSRCを選択する必要があります。レシーバの衝突解像度の考慮事項が適用されます。

7.4. Receiver Behavior
7.4. レシーバーの動作

An RTP receiver MUST process RSI packets and adapt session parameters, such as the RTCP bandwidth, based on the information received. The receiver no longer has a global view of the session and will therefore be unable to receive information from individual receivers aside from itself. However, the information conveyed by the Distribution Source can be extremely detailed, providing the receiver with an accurate view of the session quality overall, without the processing overhead associated with listening to and analyzing all Receiver Reports.

RTP受信機は、RSIパケットを処理し、受信した情報に基づいて、このようなRTCP帯域幅などのセッションパラメータを、適応しなければなりません。受信機は、もはやセッションのグローバルな視野を持っていない、したがってそれ自体は別に、個々の受信機からの情報を受信することができません。しかし、配信元によって伝えられる情報は、に耳を傾け、すべての受信レポートを分析に関連する処理のオーバーヘッドなしに、全体的なセッションの品質の正確なビューを有する受信機を提供する、非常に詳細であることができます。

The RTP receiver MUST process the report blocks contained in any RTP SR and RR packets to complete its view of the RTP session.

RTP受信機はRTPセッションのビューを完了するために、任意のRTP SRとRRパケットに含まれるレポートブロックを処理しなければなりません。

The SSRC collision list MUST be checked against the SSRC selected by the receiver to ensure there are no collisions as MUST be incoming RTP packets from the Media Senders. A receiver observing RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing and before sending any (further) RTCP feedback messages.

SSRC衝突リストは、メディア送信者からの着信RTPパケットでなければならないように衝突がないことを確認するために受信機によって選択されたSSRCに対してチェックしなければなりません。 SSRC選択された独自に衝突SSRCとメディア送信元からRTPパケットを観測受信機は、[1]の手順に従って、自身のSSRCを変更しなければなりません。受信機はすぐに気付いた後、任意の(さらに)RTCPフィードバックメッセージを送信する前に行う必要があります。

A Group and Average Packet Size sub-report block is most likely to be appended to the RSI header (either a Group Size sub-report or an RTCP Bandwidth sub-report MUST be included). The group size n allows a receiver to calculate its share of the RTCP bandwidth, r. Given R, the total available RTCP bandwidth share for receivers (in the SSM RTP session) r = R/(n). For the group size calculation, the RTP receiver MUST NOT include the Distribution Source, i.e., the only RTP receiver sending RSI packets.

グループと平均パケットサイズのサブレポートブロックは、RSIヘッダ(グループサイズのサブレポートまたはRTCP帯域幅のサブレポートが含まれなければならないのいずれか)に追加される可能性が最も高いです。グループサイズnは、r、受信機は、RTCP帯域幅のシェアを計算することを可能にします。与えられたR、(SSM RTPセッションにおける)受信機のために利用可能な全RTCP帯域幅を共有R = R /(N)。グループサイズの計算のために、RTP受信機は、配信元、RSIパケットを送信する、すなわち、唯一のRTP受信機を含んではいけません。

The receiver RTCP bandwidth field MAY override this value. If the receiver RTCP bandwidth field is present, the receiver MUST use this value as its own RTCP reporting bandwidth r.

受信機RTCP帯域幅のフィールドには、この値を無効にすることができます。受信機RTCP帯域幅のフィールドが存在する場合、受信機は、独自のRTCP報告帯域幅rと、この値を使用する必要があります。

If the RTCP bandwidth field was used by the Distribution Source in an RTCP session but this field was not included in the last five RTCP RSI reports, the receiver MUST revert to calculating its bandwidth share based upon the group size information.

RTCP帯域幅フィールドはRTCPセッションで配布ソースで使用されていましたが、このフィールドは、最後の5 RTCP RSIレポートに含まれていなかった場合、受信機は、グループサイズ情報に基づいてその帯域幅のシェアを計算する元に戻す必要があります。

If the receiver has not received any RTCP RSI packets from the Distribution Source for a period of five times the sender reporting interval, it MUST cease transmitting RTCP Receiver Reports until the next RTCP RSI packet is received.

受信機が5回送信者の報告インターバルの期間、配布ソースから任意のRTCP RSIパケットを受信して​​いない場合は、次のRTCP RSIパケットが受信されるまで、それはRTCPレシーバレポートを送信を中止しなければなりません。

The receiver can use the summarized data as desired. This data is most useful in providing the receiver with a more global view of the conditions experienced by other receivers and enables the client to place itself within the distribution and establish the extent to which its reported conditions correspond to the group reports as a whole. Appendix B provides further information and examples of data processing at the receiver.

所望に応じて、受信機は、要約されたデータを使用することができます。このデータは、他の受信機が経験する条件のよりグローバルな視点での受信機を提供する上で最も有用であり、分布内自体を配置し、その報告されている条件は、グループ全体のレポートに対応する範囲を確立するためにクライアントを可能にします。付録Bは、さらに、情報および受信機でのデータ処理の一例を提供します。

The receiver SHOULD assume that any sub-report blocks in the same packet correspond to the same data set received by the Distribution Source during the last reporting time interval. This applies to packets with multiple blocks, where each block conveys a different range of values.

受信機は、同じパケット内の任意のサブレポートブロックが最後のレポート時間間隔中に配信元によって受信された同じデータ・セットに対応すると仮定すべきです。これは、各ブロックは、値の異なる範囲を伝達する複数のブロックを有するパケットに適用されます。

A receiver MUST NOT rely on all of the RTCP packets it sends reaching the Media Senders or any other receiver. While RR statistics will be aggregated, BYE packets will be processed, and SSRC collisions will usually be announced, processing and/or forwarding of further RTCP packets is up to the discretion of the Distribution Source and will be performed as specified in the session description.

受信機は、それがメディアの送信者またはその他の受信機に到達した送信RTCPパケットの全て当てにしてはいけません。 RR統計はBYEパケットが処理され、SSRC衝突が通常発表され、集約されるが、処理および/またはさらなるRTCPパケットの転送は、配信元の裁量に任され、セッション記述で指定されるように行われます。

If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. The receiver MUST be aware that such out-of-band information may be outdated (i.e., that the sender SSRC(s) may have changed) and MUST follow the above collision-resolution procedure if necessary.

受信機はメディアセッションで使用されるメディアの送信者SSRC(複数可)についての利用可能帯域外の情報を持っている場合、それは自分自身のために同じSSRCを使用してはなりません。受信機は、アウト・オブ・バンド情報が古くなってもよい(送信者SSRC(s)が変更されていてもよい、すなわち、こと)、必要に応じて上記衝突解決手順に従わなければならないことを認識しなければなりません。

A receiver MAY use such Media Sender SSRC information when available but MUST beware of potential changes to the SSRC (which can only be learned from Sender Report (SR) packets).

受信機は、利用可能な場合、このようなメディアの送信者のSSRC情報を使用することができるが、(唯一の送信者レポート(SR)パケットから学ぶことができる)SSRCへの潜在的な変化に注意しなければなりません。

7.5. Media Sender Behavior
7.5. メディア送信者行動

Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (optionally forwarded by the Distribution Source).

メディア送信者は、受信機によって送信されたRTCPレポートのユニキャストまたはマルチキャストトランスポートアドレスをリッスン(と配布ソースによって転送)または(必要に応じて配布ソースによって転送)他のメディアの送信者。

Unlike in the case of the simple forwarding model, Media Senders MUST be able to process RSI packets from the Distribution Source to determine the group size and their own RTCP bandwidth share. Media Senders MUST also be capable of determining the group size (and their corresponding RTCP bandwidth share) from listening to (forwarded) RTCP RR and SR packets (as mandated in [1]).

シンプルな転送モデルの場合とは異なり、メディア送信者は、グループの大きさと、独自のRTCP帯域幅シェアを決定するために配布ソースからRSIパケットを処理できなければなりません。メディア送信者はまた、([1]に義務付けられた)(転送)RTCP RRとSRパケットを聞くからグループサイズ(及びそれらの対応するRTCP帯域幅シェア)を決定することができなければなりません。

As long as they send RTP packets, they MUST also send RTCP SRs, as defined in [1].

[1]で定義されている限り、それらがRTPパケットを送信するように、それらはまた、RTCPのSRを送信しなければなりません。

A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision-resolution actions, as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately.

また、メディアの送信者ではない別のエンティティとのSSRC衝突[1]、5 * 1.5 * Tdだけ、Tdは決定論的計算され報告間隔であると、のための通り、それ自身の衝突解決アクションを遅延させることができる観察メディアセンダ受信機は、競合がまだ存在するかどうかを確認します。他のメディアの送信者とのSSRC衝突がすぐに作用しなければなりません。

Note: This gives precedence to Media Senders and places the burden of collision resolution on RTP receivers.

注意:これは、メディアの送信者を優先しますし、RTP受信機に衝突解決の負担を配置します。

Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC eagerly or unnecessarily.

送信者SSRC情報は、SDPメディア記述の手段によって、例えば、アウト・オブ・バンド通信することができます。したがって、送信者は熱心にまたは不必要に自分自身のSSRCを変更しないでください。

8. Mixer/Translator Issues
8.ミキサー/翻訳の問題

The original RTP specification allows a session to use mixers and translators to help connect heterogeneous networks into one session. There are a number of issues, however, which are raised by the unicast feedback model proposed in this document. The term 'mixer' refers to devices that provide data stream multiplexing where multiple sources are combined into one stream. Conversely, a translator does not multiplex streams but simply acts as a bridge between two distribution mechanisms, e.g., a unicast-to-multicast network translator. Since the issues raised by this document apply equally to either a mixer or translator, the latter are referred to from this point onwards as mixer-translator devices.

オリジナルのRTP仕様では、セッションは1つのセッションに異種のネットワークを接続するために役立つミキサーと翻訳者を使用することができます。多くの問題は、この文書で提案されたユニキャストフィードバックモデルによって提起されている、しかし、があります。用語「ミキサー」は、複数のソースを1つのストリームに結合されたデータストリームの多重化を提供するデバイスを指します。逆に、トランスレータはない多重化ストリームを行いますが、単に2つの配布メカニズム、例えば、ユニキャストとマルチキャストネットワークトランスレータの間のブリッジとして機能します。このドキュメントによって提起された問題は、ミキサーまたは翻訳のいずれにも等しく適用されるため、後者は、ミキサー - トランスレータ装置として以降この点から参照されています。

A mixer-translator between distribution networks in a session must ensure that all members in the session receive all the relevant traffic to enable the usual operation by the clients. A typical use may be to connect an older implementation of an RTP client with an SSM distribution network, where the client is not capable of unicasting feedback to the source. In this instance, the mixer-translator must join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements.

セッションでの流通ネットワーク間のミキサー・トランスレータは、セッション内のすべてのメンバーは、クライアントが通常の操作を可能にするために、関連するすべてのトラフィックを受信することを確認する必要があります。典型的な使用は、クライアントがソースにフィードバックをユニキャストすることができないSSM配信ネットワークとRTPクライアントの古い実装を接続することができます。この例では、ミキサー・トランスレータは、クライアントに代わってセッションに参加しなければならないし、クライアントへのセッションからのトラフィックを送受信します。特定のハイブリッドシナリオは異なる要件を有することができます。

8.1. Use of a Mixer-Translator
8.1. ミキサー・翻訳の利用

The mixer-translator MUST adhere to the SDP description [5] for the single-source session (Section 11) and use the feedback mechanism indicated. Implementers of receivers SHOULD be aware that when a mixer-translator is present in the session, more than one Media Sender may be active, since the mixer-translator may be forwarding traffic to the SSM receivers either from multiple unicast sources or from an ASM session. Receivers SHOULD still forward unicast RTCP reports in the usual manner to their assigned Feedback Target/Distribution Source, which in this case -- by assumption -- would be the mixer-translator itself. It is RECOMMENDED that the simple packet-reflection mechanism be used under these circumstances, since attempting to coordinate RSI + summarization reporting between more than one source may be complicated unless the mixer-translator is capable of summarization.

ミキサトランスレータは、単一のソース・セッション(第11)[5] SDP記述に付着して示されるフィードバック機構を使用しなければなりません。受信機の実装はミキサ翻訳者がセッションに存在する場合ミキサートランスレータは、複数のユニキャストソースから、またはASMセッションからのいずれかSSMレシーバにトラフィックを転送することができるので、複数のメディア送信者は、アクティブであってもよいことに注意してください。仮定することによって - - ミキサー・トランスレータ自身だろうレシーバはまだ前方ユニキャストRTCPは、この場合には、割り当てられたフィードバック目標/配布ソースに通常の方法で報告する必要があります。単純なパケット反射機構がミキサトランスレータは要約することが可能でなければ複雑にすることができる複数のソース間RSI +要約レポートを調整しようとするので、このような状況下で使用することを推奨されています。

8.2. Encryption and Authentication Issues
8.2. 暗号化および認証の問題

Encryption and security issues are discussed in detail in Section 11. A mixer-translator MUST be able to follow the same security policy as the client in order to unicast RTCP feedback to the source, and it therefore MUST be able to apply the same authentication and/or encryption policy required for the session. Transparent bridging and subsequent unicast feedback to the source, where the mixer-translator is not acting as the Distribution Source, is only allowed if the mixer-translator can conduct the same source authentication as required by the receivers. A translator MAY forward unicast packets on behalf of a client but SHOULD NOT translate between multicast-to-unicast flows towards the source without authenticating the source of the feedback address information.

暗号化およびセキュリティの問題がミキサ翻訳者がソースへのユニキャストRTCPフィードバックするために、クライアントと同じセキュリティポリシーに従うことができなければなりません、セクション11で詳細に説明され、そしてそれ故、同じ認証を適用できなければならないと/またはセッションに必要な暗号化ポリシー。受信機によって要求されるようにミキサトランスレータが同じソースの認証を行うことができる場合にミキサトランスレータが配信元として機能していないソースにトランスペアレントブリッジングおよびその後のユニキャストフィードバックは、のみ許されます。翻訳者は、クライアントの代わりにユニキャストパケットを転送することができるが、フィードバックアドレス情報のソースを認証することなく、ソースに向けて、マルチキャストからユニキャストへの流れの間の変換すべきではありません。

9. Transmission Interval Calculation
9.送信間隔の計算

The Control Traffic Bandwidth referred to in [1] is an arbitrary amount that is intended to be supplied by a session-management application (e.g., SDR [21]) or decided based upon the bandwidth of a single sender in a session.

制御トラフィック帯域幅で参照[1]セッション管理アプリケーション(例えば、SDR [21])によって供給されるか、セッションにおける単一の送信者の帯域幅に基づいて決定されることが意図される任意の量です。

The RTCP transmission interval calculation either remains the same as in the original RTP specification [1] or uses the algorithm in [10] when bandwidth modifiers have been specified for the session.

RTCP送信間隔の計算は、元のRTP仕様で同じままである[1]又は帯域幅調整剤は、セッションのために指定されているときに[10]にアルゴリズムを使用するのいずれか。

9.1. Receiver RTCP Transmission
9.1. レシーバRTCP送信

If the Distribution Source is operating in Simple Feedback Model (which may be indicated in the corresponding session description for the media session but which the receiver also notices from the absence of RTCP RSI packets), a receiver MUST calculate the number of other members in a session based upon its own SSRC count, derived from the forwarded Sender and Receiver Reports it receives. The receiver MUST calculate the average RTCP packet size from all the RTCP packets it receives.

配信元は、(メディアセッションに対応するセッション記述に示されてもよいが、受信機はまた、RTCP RSIパケットが存在しないことから気づいた)単純なフィードバックモデルで動作している場合、受信機は、他のメンバーの数を計算しなければなりませんセッションは、自身のSSRC回数に基づいて転送され、送信者から派生し、受信側は受信したレポート。受信機は、受信したすべてのRTCPパケットから平均RTCPパケットサイズを計算しなければなりません。

If the Distribution Source is operating in Distribution Source Feedback Summary Model, the receiver MUST use either the group size field and the average RTCP packet size field or the Receiver Bandwidth field from the respective sub-report blocks appended to the RSI packet.

配信元は、配信元フィードバック概要モデルで動作している場合、受信機は、RSIのパケットに付加された各サブレポートブロックからグループサイズフィールドと平均RTCPパケットサイズのフィールドまたはReceiver Bandwidthフィールドのいずれかを使用しなければなりません。

A receiver uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].

受信機は、[1]及び[10]の通りに決定論的計算さインターバルの計算への入力としてこれらの値を使用します。

9.2. Distribution Source RTCP Transmission
9.2. 配布ソースRTCP送信

If operating in Simple Feedback Model, the Distribution Source MUST calculate the transmission interval for its Receiver Reports and associated RTCP packets, based upon the above control traffic bandwidth, and MUST count itself as RTP receiver. Receiver Reports will be forwarded as they arrive without further consideration. The Distribution Source MAY choose to validate that all or selected receivers roughly adhere to the calculated bandwidth constraints and

単純なフィードバックモデルで動作している場合、配布ソースは、上記の制御トラフィックの帯域幅に基づいて、その受信機レポートおよび関連するRTCPパケットの送信間隔を計算しなければならない、とRTP受信機としての地位をカウントしなければなりません。彼らはさらに考慮せずに到着すると受信機レポートが転送されます。配布ソースは、すべてまたは選択した受信機は、大きく算出された帯域幅の制約に従うことを検証することを選択するかもしれなくて、

MAY choose to drop excess packets for receivers that do not. In all cases, the average RTCP packet size is determined from the forwarded Media Senders' and receivers' RTCP packets and from those originated by the Distribution Source.

ない受信機のため余分なパケットをドロップするように選ぶかもしれません。すべての場合において、平均RTCPパケットサイズは、転送メディア送信者と受信者RTCPパケットからと配布ソースによって発信それらから決定されます。

If operating in Distribution Source Feedback Summary Model, the Distribution Source does not share the forward RTCP bandwidth with any of the receivers. Therefore, the Distribution Source SHOULD use the full RTCP bandwidth for its Receiver Reports and associated RTCP packets, as well as RTCP RSI packets. In this case, the average RTCP packet size is only determined from the RTCP packets originated by the Distribution Source.

配布ソースフィードバックの概要モデルで動作している場合、配布ソースは、受信機のいずれかと前方RTCP帯域幅を共有しません。そのため、配布ソースは、その受信機レポートおよび関連するRTCPパケットと同様に、RTCP RSIパケットのための完全なRTCP帯域幅を使用すべきです。この場合には、平均RTCPパケットサイズは、配信元から発信RTCPパケットから決定されます。

The Distribution Source uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].

配信元は、[1]の通りに決定論的計算さインターバルの計算への入力としてこれらの値を使用して[10]。

9.3. Media Senders RTCP Transmission
9.3. メディア送信者RTCP送信

In Simple Feedback Model, the Media Senders obtain all RTCP SRs and RRs as they would in an ASM session, except that the packets are forwarded by the Distribution Source. They MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10].

彼らはASMセッションと同じように単純なフィードバックモデルでは、メディアの送信者は、パケットが配信ソースによって転送されていることを除いて、すべてのRTCPのSRとRRを得ます。これらは、[10] [1]に従って決定論送信間隔のそれらのRTCPグループサイズ推定値と計算を実行しなければなりません。

In Distribution Source Feedback Summary Model, the Media Senders obtain all RTCP SRs as they would in an ASM session. They receive either RTCP RR reports as in ASM (in case these packets are forwarded by the Distribution Source) or RSI packets containing summaries. In the former case, they MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10]. In the latter case, they MUST combine the information obtained from the Sender Reports and the RSI packets to create a complete view of the group size and the average RTCP packet size and perform the calculation of the deterministic transmission interval, as per [1] and [10], based upon these input values.

彼らはASMセッションと同じように配布元のフィードバックの概要モデルでは、メディアの送信者は、すべてのRTCPのSRを得ます。彼らは、受信のいずれかRTCP RRは、ASM(場合にはこれらのパケットを配布ソースによって転送されている)、または要約を含むRSIパケットのように報告します。前者の場合、それらはに従って決定論送信間隔のそれらのRTCPグループサイズ推定値と計算を実行しなければなりません[1]及び[10]。後者の場合には、それらが通り、グループサイズと平均RTCPパケットサイズの完全なビューを作成し、決定論的な送信間隔の計算を実行するために送信者レポートとRSIパケットから得られた情報を結合しなければならない[1]及び[10]、これらの入力値に基づきます。

9.4. Operation in Conjunction with AVPF and SAVPF
9.4. AVPFとSAVPFと組み合わせた場合の動作

If the RTP session is an AVPF session [15] or an SAVPF session [28] (as opposed to a regular AVP [6] session), the receivers MAY modify their RTCP report scheduling, as defined in [15]. Use of AVPF or SAVPF does not affect the Distribution Source's RTCP transmission or forwarding behavior.

RTPセッションがAVPFセッション[15]またはSAVPFセッション[28](正規AVP [6]セッションとは対照的に)である場合、受信機は[15]で定義されるように、それらのRTCPレポートスケジュールを変更することができます。 AVPFまたはSAVPFの使用は、配信元のRTCP送信や転送動作には影響を与えません。

It is RECOMMENDED that a Distribution Source and possible separate Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP packets in order to not counteract the damping mechanism built into AVPF; optionally, they MAY aggregate the feedback information from the receivers as per Section 7.2.2. If only generic feedback packets that are understood by the Distribution Source and that can easily be aggregated are in use, the Distribution MAY combine several incoming RTCP feedback packets and forward the aggregate along with its next RTCP RR/RSI packet. In any case, the Distribution Source and Feedback Target(s) SHOULD minimize the extra delay when forwarding feedback information, but the Distribution Source MUST stay within its RTCP bandwidth constraints.

なお、配信元と可能別個フィードバックターゲット(複数可)AVPFに組み込まれた減衰機構を相殺しないために、AVPF / SAVPF固有RTCPパケットを転送するように構成されることをお勧めします。必要に応じて、彼らは7.2.2項に従って受信機からのフィードバック情報を集約することができます。配布ソースによって理解され、それが簡単に集約することができる唯一の一般的なフィードバックパケットが使用されている場合は、ディストリビューションには、いくつかの着信RTCPフィードバックパケットを結合し、その次のRTCP RR / RSIパケットと一緒に集計を転送することができます。フィードバック情報を転送するときに、どのような場合には、配布元とフィードバック目標(複数可)余分な遅延を最小限に抑える必要がありますが、配布ソースは、そのRTCP帯域幅の制約の範囲内で滞在しなければなりません。

In the event that specific APP packets without a format and summarization mechanism understood by the Feedback Target(s) and/or the Distribution Source are to be used, it is RECOMMENDED that such packets are forwarded with minimal delay. Otherwise, the capability of the receiver to send timely feedback messages is likely to be affected.

フィードバック目標(複数可)および/または配布元によって理解されるフォーマットおよび集約メカニズムことなく、特定のAPPパケットが使用されるた場合に、そのようなパケットは、最小の遅延で転送されることが推奨されます。それ以外の場合は、タイムリーなフィードバックメッセージを送信するための受信機の能力が影響を受ける可能性があります。

10. SDP Extensions
10. SDP拡張機能

The Session Description Protocol (SDP) [5] is used as a means to describe media sessions in terms of their transport addresses, codecs, and other attributes. Signaling that RTCP feedback will be provided via unicast, as specified in this document, requires another session parameter in the session description. Similarly, other SSM RTCP feedback parameters need to be provided, such as the summarization model at the sender and the target unicast address to which to send feedback information. This section defines the SDP parameters that are needed by the proposed mechanisms in this document (and that have been registered with IANA).

セッション記述プロトコル(SDP)[5]は、そのトランスポート・アドレス、コーデック、およびその他の属性の観点からメディアセッションを記述するための手段として使用されます。この文書で指定されたRTCPフィードバックは、ユニキャストを介して提供されることをシグナリング、セッション記述における他のセッションパラメータを必要とします。同様に、他のSSM RTCPフィードバックパラメータは、送信側で集計モデルとフィードバック情報を送信するために目標ユニキャストアドレスとして、提供される必要があります。このセクションでは、この文書で提案機構によって必要とされる(それは、IANAに登録されている)SDPパラメータを定義します。

10.1. SSM RTCP Session Identification
10.1. SSM RTCPセッション識別

A new session-level attribute MUST be used to indicate the use of unicast instead of multicast feedback: "rtcp-unicast".

「RTCP-ユニキャスト」:新しいセッション・レベルの属性ではなく、マルチキャストフィードバックのユニキャストの使用を示すために使用されなければなりません。

This attribute uses one parameter to specify the model of operation. An optional set of parameters specifies the behavior for RTCP packet types (and subtypes).

この属性は、操作のモデルを指定するために1つのパラメータを使用しています。オプションのパラメータのセットは、RTCPパケットタイプ(およびサブタイプ)の動作を指定します。

rtcp-unicast:reflection

RTCP-ユニキャスト:反射

This attribute MUST be used to indicate the "Simple Feedback" model of operation where packet reflection is used by the Distribution Source (without further processing).

この属性は、パケットの反射が(さらなる処理なしに)配信元によって使用される動作の「単純なフィードバック」モデルを示すために使用されなければなりません。

rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])

RTCPユニキャスト:RSI *(SP <処理>:<RTCP型>])

This attribute MUST be used to indicate the "Distribution Source Feedback Summary" model of operation. In this model, a list or parameters may be used to explicitly specify how RTCP packets originated by receivers are handled. Options for processing a given RTCP packet type are:

この属性は、動作の「配布ソースフィードバック概要」モデルを示すために使用されなければなりません。このモデルでは、リストまたはパラメータが明示的に受信機によって発信RTCPパケットの処理方法を指定するために使用することができます。与えられたRTCPパケットタイプを処理するためのオプションは次のとおりです。

aggr: The Distribution Source has means for aggregating the contents of the RTCP packets and will do so.

AGGR:配布ソースは、RTCPパケットの内容を集約するための手段を有しているとそうなります。

forward: The Distribution Source will forward the RTCP packet unchanged.

前方:配布ソースはそのままRTCPパケットを転送します。

term: The Distribution Source will terminate the RTCP packet.

用語:配布ソースは、RTCPパケットを終了します。

The default rules applying if no parameters are specified are as follows:

次のようにパラメータを指定しない場合は適用するデフォルトのルールは以下のとおりです。

RR and SDES packets MUST be aggregated and MUST lead to RSI packets being generated. All other RTP packets MUST be terminated at the Distribution Source (or Feedback Target(s)).

RRとSDESパケットを集約しなければならなくて、生成されるRSIパケットにつながるしなければなりません。他のすべてのRTPパケットは、配布ソース(またはフィードバック目標(S))で終えなければなりません。

The SDP description needs only to specify deviations from the default rules. Aggregation of RR packets and forwarding of SR packets MUST NOT be changed.

SDP記述は、デフォルトのルールからの逸脱を指定する必要があります。 RRパケット及びSRパケットの転送の集計を変更してはいけません。

The token for the new SDP attribute is "rtcp-unicast" and the formal SDP ABNF syntax for the new attribute value is as follows:

新しいSDP属性のトークンは、「RTCP-ユニキャスト」で、次のように新しい属性値の正式なSDP ABNFの構文は次のとおりです。

att-value = "reflection" / "rsi" *(SP rsi-rule)

ATT値= "反射" / "RSI" *(SPのRSIルール)

rsi-rule = processing ":" rtcp-type

RSI-ルール=処理 ":" RTCP型

processing = "aggr" / "forward" / "term" / token ;keep it extensible

処理=「AGGR」/「フォワード」/「という用語は、」/トークン、拡張可能それを維持

rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)

RTCP型= 3 * 3DIGIT; RTCPタイプ(192、193、202--209)

10.2. SSM Source Specification
10.2. SSMソースの仕様

In a Source-Specific Multicast RTCP session, the address of the Distribution Source needs to be indicated both for source-specific joins to the multicast group and for addressing unicast RTCP packets on the backchannel from receivers to the Distribution Source.

ソース固有マルチキャストRTCPセッションでは、配信元のアドレスは、マルチキャストグループへと配信元に受信機からのバックチャネル上のユニキャストRTCPパケットに対処するための加入ソース固有の両方に示される必要があります。

This is achieved by following the proposal for SDP source filters documented in [4]. According to the specification, only the inclusion model ("a=source-filter:incl") MUST be used for SSM RTCP.

これは、[4]に記載SDPソースフィルタの提案に従うことによって達成されます。仕様によれば、のみ封入モデル(「A =ソースフィルタ:込み」)はSSM RTCPのために使用されなければなりません。

There SHOULD be exactly one "a=source-filter:incl" attribute listing the address of the Distribution Source. The RTCP port MUST be derived from the m= line of the media description.

正確に一つの「A =ソースフィルタ:税込」がなければならない属性は、配信元のアドレスが一覧表示されます。 RTCPポートは、メディア記述のM =行に由来しなければなりません。

An alternative Feedback Target Address and port MAY be supplied using the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4 192.0.2.1. This attribute only defines the transport address of the Feedback Target and does not affect the SSM group specification for media stream reception.

代替フィードバック目標アドレスとポートはSDP RTCP属性を使用して供給されるかもしれません[7]、例えば、A = RTCP:<ポート> IP4 192.0.2.1のIN。この属性は、フィードバック目標のトランスポートアドレスを定義し、メディアストリームの受信のためのSSMグループの指定には影響を与えません。

Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the same Distribution Source.

二つの「ソース・フィルタ」属性は、IPv4と同じ配布ソースのIPv6の表現を示すために存在してもよいです。

10.3. RTP Source Identification
10.3. RTPソース識別

The SSRC information for the Media Sender(s) MAY be communicated explicitly out of band (i.e., outside the RTP session). One option for doing so is the Session Description Protocol (SDP) [5]. If such an indication is desired, the "ssrc" attribute [12] MUST be used for this purpose. As per [12], the "cname" Source Attribute MUST be present. Further Source Attributes MAY be specified as needed.

メディア送信者(S)のためのSSRC情報(すなわち、RTPセッションの外側に)帯域外明示的に通信されても​​よいです。そうするための1つのオプションは、セッション記述プロトコル(SDP)[5]です。このような表示が所望される場合、「SSRC」属性[12]は、この目的のために使用されなければなりません。 [12]あたりのように、「CNAME」ソース属性が存在しなければなりません。必要に応じてさらにソースの属性を指定することができます。

If used in an SDP session description of an RTCP-SSM session, the ssrc MUST contain the SSRC intended to be used by the respective Media Sender and the cname MUST equal the CNAME for the Media Sender. If present, the role SHOULD indicate the function of the RTP entity identified by this line; presently, only the "media-sender" role is defined.

RTCP-SSMセッションのSDPセッション記述において使用される場合、SSRCはSSRCは、各メディア送信者によって使用されることを意図含まなければなりませんとCNAMEは、メディア送信者のためのCNAMEを等しくなければなりません。存在する場合、役割は、この行で識別されるRTPエンティティの機能を示すべきです。現在、唯一の「メディアの送信者」の役割が定義されます。

Example:

例:

a=ssrc:314159 cname:iptv-sender@example.com

= SSRC:314159 CNAME:iptv-sender@example.com

In the above example, the Media Sender is identified to use the SSRC identifier 314159 and the CNAME iptv-sender@example.com.

上記の例では、メディア送信者がSSRC識別子314159とCNAME iptv-sender@example.comを使用することが同定されています。

11. Security Considerations
11.セキュリティについての考慮事項

The level of security provided by the current RTP/RTCP model MUST NOT be diminished by the introduction of unicast feedback to the source. This section identifies the security weaknesses introduced by the feedback mechanism, potential threats, and level of protection that MUST be adopted. Any suggestions on increasing the level of security provided to RTP sessions above the current standard are RECOMMENDED but OPTIONAL. The final section outlines some security frameworks that are suitable to conform to this specification.

現在のRTP / RTCPモデルによって提供されるセキュリティのレベルがソースへのユニキャストフィードバックの導入によって減少してはいけません。このセクションでは、採用されなければならないフィードバック機構、潜在的な脅威、および保護のレベルによって導入されたセキュリティ上の弱点を特定します。現在の標準以上のRTPセッションに提供されるセキュリティのレベルを上げる上の任意の提案をお勧めしますが、オプションです。最後のセクションでは、この仕様に準拠するのに適しているいくつかのセキュリティフレームワークの概要を説明します。

11.1. Assumptions
11.1. 仮定

RTP/RTCP is a protocol that carries real-time multimedia traffic, and therefore a main requirement is for any security framework to maintain as low overhead as possible. This includes the overhead of different applications and types of cryptographic operations as well as the overhead to deploy or to create security infrastructure for large groups.

RTP / RTCPはリアルタイムマルチメディアトラフィックを運ぶプロトコルであり、したがって主な要件は、可能な限り低いオーバーヘッドを維持するために、任意のセキュリティ・フレームワークのためのものです。これは、暗号化操作の異なる用途及びタイプのオーバーヘッド並びに展開する、または大規模なグループのためのセキュリティインフラストラクチャを作成するオーバーヘッドを含みます。

Although the distribution of session parameters (typically encoded as SDP objects) through the Session Announcement Protocol (SAP) [22], email, or the web is beyond the scope of this document, it is RECOMMENDED that the distribution method employs adequate security measures to ensure the integrity and authenticity of the information. Suitable solutions that meet the security requirements outlined here are included at the end of this section.

セッションアナウンスメントプロトコル(SAP)[22]、電子メール、またはウェブを介してセッションパラメータ(典型的には、SDPオブジェクトとして符号化された)の分布は、この文書の範囲外であるが、配信方法はに十分なセキュリティ対策を採用することが推奨されます情報の整合性と信頼性を確保。ここで説明するセキュリティ要件を満たす適切な溶液は、このセクションの末尾に含まれています。

In practice, the multicast and group distribution mechanism, e.g., the SSM routing tree, is not immune to source IP address spoofing or traffic snooping; however, such concerns are not discussed here. In all the following discussions, security weaknesses are addressed from the transport level or above.

実際には、マルチキャストグループの分配機構は、例えば、SSMルーティングツリーは、ソースIPアドレススプーフィングやトラフィックスヌーピングに対する免疫はありません。しかし、そのような懸念は、ここで議論されていません。すべての以下の議論では、セキュリティ上の弱点は、トランスポート・レベルまたは上から取り上げています。

11.2. Security Threats
11.2. セキュリティの脅威

Attacks on media distribution and the feedback architecture proposed in this document may take a variety of forms. A detailed outline of the types of attacks follows:

メディア配信と、この文書で提案されているフィードバック・アーキテクチャへの攻撃は、種々の形態をとり得ます。攻撃の種類の詳細な概要は次のとおりです。

a) Denial of Service (DoS)

a)はサービス拒否(DoS)の

DoS is a major area of concern. Due to the nature of the communication architecture, a DoS can be generated in a number of ways by using the unicast feedback channel to the attacker's advantage.

DoS攻撃は、懸念の主要な領域です。通信アーキテクチャの性質のために、DoS攻撃は、攻撃者の利点にユニキャストフィードバックチャネルを用いて多くの方法で生成することができます。

b) Packet Forgery

b)のパケット偽造

Another potential area for attack is packet forgery. In particular, it is essential to protect the integrity of certain influential packets since compromise could directly affect the transmission characteristics of the whole group.

攻撃のための別の可能性のある領域は、パケットの偽造です。特に、妥協が直接グループ全体の伝送特性に影響を与える可能性があるため、特定の有力なパケットの完全性を保護することが不可欠です。

c) Session Replay

C)セッションリプレイ

The potential for session recording and subsequent replay is an additional concern. An attacker may not actually need to understand packet content but simply have the ability to record the data stream and, at a later time, replay it to any receivers that are listening.

セッションの記録とその後の再生の可能性は、追加の懸念事項です。攻撃者は、実際にパケットの内容を理解する必要がなく、単にデータストリームを記録する機能を持っていると、後の時点で、聞いているすべての受信者にそれを再生しない場合があります。

d) Eavesdropping on a Session

セッションのd)の盗聴

The consequences of an attacker eavesdropping on a session already constitutes a security weakness; in addition, eavesdropping might facilitate other types of attacks and is therefore considered a potential threat. For example, an attacker might be able to use the eavesdropped information to perform an intelligent DoS attack.

セッション上の攻撃者の盗聴の結果は、既にセキュリティ上の弱点を構成しています。加えて、盗聴は、他のタイプの攻撃を促進する可能性があるため、潜在的な脅威と見なされています。例えば、攻撃者は、インテリジェントなDoS攻撃を実行するために盗聴情報を使用することができるかもしれません。

11.3. Architectural Contexts
11.3. 建築コンテキスト

To better understand the requirements of the solution, the threats outlined above are addressed for each of the three communication contexts:

より良いソリューションの要件を理解するために、上記概説した脅威は、3つの通信コンテキストごとに取り組まれています。

a) Source-to-Receiver Communication

a)のソース - レシーバコミュニケーション

The downstream communication channel, from the source to the receivers, is critical to protect since it controls the behavior of the group; it conveys the bandwidth allocation for each receiver, and hence the rate at which the RTCP traffic is unicast, directly back to the source. All traffic that is distributed over the downstream channel is generated by a single source. Both the RTP data stream and the RTCP control data from the source are included in this context, with the RTCP data generated by the source being indirectly influenced by the group feedback.

下り通信チャネルは、受信機にソースから、それがグループの挙動を制御するために保護することが重要です。それは、各受信機のための帯域幅割り当て、ひいてはRTCPトラフィックは直接バックソースに、ユニキャストされる速度を搬送します。ダウンストリームチャネルに分配されるすべてのトラフィックは、単一のソースによって生成されます。 RTPデータストリームソースからのRTCP制御データの両方が間接的グループフィードバックに影響されるソースによって生成されたRTCPデータと、これに関連して含まれます。

The downstream channel is vulnerable to the four types of attack outlined above. The denial of service attack is possible but less of a concern than the other types. The worst case effect of DoS would be the transmission of large volumes of traffic over the distribution channel, with the potential to reach every receiver but only on a one-to-one basis. Consequently, this threat is no more pronounced than the current multicast ASM model. The real danger of denial of service attacks in this context comes indirectly via compromise of the source RTCP traffic. If receivers are provided with an incorrect group size estimate or bandwidth allowance, the return traffic to the source may create a distributed DoS effect on the source. Similarly, an incorrect feedback address -- whether as a result of a malicious attack or by mistake, e.g., an IP address configuration error (e.g., typing) -- could directly create a denial of service attack on another host.

ダウンストリームチャネルは、上記で概説した攻撃の4種類に対して脆弱です。サービス拒否攻撃は可能ですが、他のタイプよりも心配が少ないです。 DoS攻撃の最悪の影響はなく、唯一の一対一上のすべての受信機に到達する可能性と、流通チャネルを介して大量のトラフィックの送信になります。したがって、この脅威は、現在のマルチキャストのASMモデルよりもより顕著ではありません。この文脈でのサービス妨害攻撃の本当の危険は、ソースRTCPトラフィックの妥協を介して間接的に来ます。受信機は、誤ったグループサイズの見積もりや帯域幅手当が設けられている場合は、ソースへのリターントラフィックは、ソース上の分散DoS攻撃の効果を作成することがあります。同様に、誤ったフィードバックアドレス - 悪意のある攻撃の結果として、または誤っているかどうか、例えば、IPアドレス設定エラー(例えば、タイピング)は - 直接別のホスト上のサービス拒否攻撃を作成することができます。

An additional concern relating to Denial of service attacks would come indirectly through the generation of fake BYE packets, causing the source to adjust the advertised group size. A Distribution Source MUST follow the correct rules for timing out members in a session prior to reporting a change in the group size, which allows the authentic SSRC sufficient time to continue to report and, consequently, cancel the fake BYE report.

サービス妨害攻撃に関する追加の懸念は、アドバタイズグループのサイズを調整するためのソースを引き起こし、偽のBYEパケットの生成を介して間接的に来るだろう。配布ソースは前の本物のSSRC十分な時間が報告し、その結果、偽のBYEレポートをキャンセルし続けることを可能にするグループサイズの変化を報告するセッションでタイムアウトメンバーの正しいルールに従わなければなりません。

The danger of packet forgery in the worst case may be to maliciously instigate a denial of service attack, e.g., if an attacker were capable of spoofing the source address and injecting incorrect packets into the data stream or intercepting the source RTCP traffic and modifying the fields.

攻撃者が送信元アドレスを偽装し、データストリームに不正なパケットを注入するか、ソースRTCPトラフィックを傍受し、フィールドを変更することができたならば、最悪の場合のパケット偽造の危険性は、例えば、悪意を持ってサービス拒否攻撃を扇動することであってもよいです。

The replay of a session would have the effect of recreating the receiver feedback to the source address at a time when the source is not expecting additional traffic from a potentially large group. The consequence of this type of attack may be less effective on its own, but in combination with other attacks might be serious.

セッションのリプレイは、ソースが潜在的に大規模なグループからの追加のトラフィックを期待されていない時点での送信元アドレスに受信機からのフィードバックを再現する効果を持っているでしょう。このタイプの攻撃の結果は、それ自身にはあまり効果的かもしれないが、他の攻撃との組み合わせで深刻かもしれません。

Eavesdropping on the session would provide an attacker with information on the characteristics of the source-to-receiver traffic, such as the frequency of RTCP traffic. If RTCP traffic is unencrypted, this might also provide valuable information on characteristics such as group size, Media Source SSRC(s), and transmission characteristics of the receivers back to the source.

セッション上の盗聴は、RTCPトラフィックの周波数として、ソース - 受信トラフィックの特性に関する情報を、攻撃者を提供するであろう。 RTCPトラフィックが暗号化されていない場合、これはまた、このようなグループサイズ、メディアソースSSRC(S)、およびソースに戻る受信機の伝送特性などの特性上の貴重な情報を提供するかもしれません。

b) Receiver-to-Distribution-Source Communication

B)レシーバ・ツー・ディストリビューション・ソース・コミュニケーション

The second context is the return traffic from the group to the Distribution Source. This traffic should only consist of RTCP packets and should include Receiver Reports, SDES information, BYE reports, extended reports (XR), feedback messages (RTPFB, PSFB) and possibly application-specific packets. The effects of compromise on a single or subset of receivers are not likely to have as great an impact as in context (a); however, much of the responsibility for detecting compromise of the source data stream relies on the receivers.

第二のコンテキストは、ディストリビューション・ソースにグループからのリターントラフィックです。このトラフィックはRTCPパケットで構成されなければならないとレシーバレポート、SDES情報、BYEレポート、拡張レポート(XR)、フィードバックメッセージ(RTPFB、PSFB)と、おそらく、アプリケーション固有のパケットを含むべきです。受信機の単一またはサブセット上で妥協の効果は、コンテキスト(A)ほど大きな影響を有する可能性はありません。ただし、ソース・データ・ストリームの妥協点を検出するための責任の多くは、受信機に依存しています。

The effects of compromise of critical Distribution Source control information can be seriously amplified in the present context. A large group of receivers may unwittingly generate a distributed

重要な配布ソース制御情報の妥協の影響が深刻に本発明の文脈で増幅することができます。受信機の大規模なグループは、無意識のうちに生成することができる分散

DoS attack on the Distribution Source in the event that the integrity of the source RTCP channel has been compromised and the compromise is not detected by the individual receivers.

イベントでの配布ソースにDoS攻撃は、ソースRTCPチャネルの整合性が損なわれているとの妥協は、個々の受信機によって検出されないこと。

An attacker capable of instigating a packet forgery attack could introduce false RTCP traffic and create fake SSRC identifiers. Such attacks might slow down the overall control channel data rate since an incorrect perception of the group size may be created. Similarly, the creation of fake BYE reports by an attacker would cause some group size instability, but should not be effective as long as the correct timeout rules are applied by the source in removing SSRC entries from its database.

パケット偽造攻撃を扇動できる攻撃者は、偽のRTCPトラフィックを導入し、偽のSSRC識別子を作成することができます。グループサイズの誤認識を作成することができるので、このような攻撃は、全体制御チャネルのデータ・レートを遅くすることがあります。同様に、攻撃者が偽のBYE報告書の作成は、いくつかのグループサイズが不安定になるだろうが、正しいタイムアウトルールがそのデータベースからSSRCのエントリを削除するには、ソースによって適用されている限り効果的であってはなりません。

A replay attack on receiver return data to the source would have the same implications as the generation of false SSRC identifiers and RTCP traffic to the source. Therefore, ensuring authenticity and freshness of the data source is important.

ソースへの受信機の戻りデータのリプレイ攻撃を元に虚偽のSSRC識別子とRTCPトラフィックの世代と同じ意味を持っているでしょう。したがって、データソースの信憑性と新鮮さを確保することが重要です。

Eavesdropping in this context potentially provides an attacker with a great deal of potentially personal information about a large group of receivers available from SDES packets. It would also provide an attacker with information on group traffic-generation characteristics and parameters for calculating individual receiver bandwidth allowances.

この文脈での盗聴は、潜在的にSDESパケットから利用できる受信機の大規模なグループに関する潜在的に個人情報の多大で、攻撃者が用意されています。それはまた、個々の受信帯域幅手当を算出するグループトラフィック発生特性およびパラメータに関する情報を攻撃者を提供するであろう。

c) Receiver-to-Feedback-Target Communication

C)レシーバ・ツー・フィードバック・ターゲット通信

The third context is the return traffic from the group to the Feedback Target. It suffers from the same threats as the receiver-to-source context, with the difference being that now a large group of receivers may unwittingly generate a distributed DoS (DDos) attack on the Feedback Target, where it is impossible to discern if the DDoS is deliberate or due merely to a misconfiguration of the Feedback Target Address. While deliberate attacks can be mitigated by properly authenticating messages that communicate the Feedback Target Address (i.e., the SDP session description and the Feedback Target Address sub-report block carried in RTCP), a misconfigured address will originate from an authenticated source and hence cannot be prevented using security mechanisms.

第三コンテキストは、フィードバック目標にグループからのリターントラフィックです。これは違いが現在の受信機の大規模なグループは、無意識のうちに、場合DDoS攻撃を識別することは不可能であるフィードバック目標に分散DoS攻撃(DDoS攻撃)攻撃を生成することができることであると、受信機 - ソースコンテキストと同じ脅威に苦しん単にフィードバック目標アドレスの設定ミスに意図的かによるものです。意図的な攻撃が正しくフィードバック目標アドレス(すなわち、SDPセッション記述とRTCPで運ばフィードバック目標アドレスサブレポートブロック)を伝えるメッセージを認証することによって軽減することができるが、設定ミスアドレスが認証された供給源に由来し、したがってことができませんセキュリティ・メカニズムを使用して防ぎます。

Furthermore, the Feedback Target is unable to communicate its predicament with either the Distribution Source or the session receivers. From the feedback packets received, the Feedback Target cannot tell either which SSM multicast group the feedback belongs to or the Distribution Source, making further analysis and suppression difficult. The Feedback Target may not even support RTCP or listen on the port number in question.

さらに、フィードバック目標は配布ソースまたはセッションの受信機のいずれかでその苦境を伝えることができません。フィードバックパケットを受信したことから、フィードバック目標は、さらなる分析と抑制が困難に、フィードバックはに属しいずれかがSSMマルチキャストグループまたは配布ソースを伝えることはできません。フィードバック目標でもRTCPをサポートしたり、問題のポート番号をリッスンしない場合があります。

Note that because the DDoS occurs inside of the RTCP session and because the unicast receivers adhere to transmission interval calculations ([1], [10]), the bandwidth misdirected toward the Feedback Target in the misconfigured case will be limited to a percentage of the session bandwidth, i.e., the Control Traffic Bandwidth established for the session.

DDoS攻撃は、RTCPセッションの内側及びために発生するので、ユニキャスト受信機は送信間隔の計算に付着することに注意してください([1]、[10])、設定ミスの場合にフィードバック目標に向けて誤って誘導帯域幅の割合に制限されますセッション帯域幅は、すなわち、制御トラフィックの帯域幅は、セッションのために設立しました。

11.4. Requirements in Each Context
11.4. 各コンテキストでの要件

To address these threats, this section presents the security requirements for each context.

これらの脅威に対処するために、このセクションでは、各コンテキストのセキュリティ要件を提示します。

a) The main threat in the source-to-receiver context concerns denial of service attacks through possible packet forgery. The forgery may take the form of interception and modification of packets from the source, or it may simply inject false packets into the distribution channel. To combat these attacks, data integrity and source authenticity MUST be applied to source traffic. Since the consequences of eavesdropping do not affect the operation of the protocol, confidentiality is not a requirement in this context. However, without confidentiality, access to personal and group characteristics information would be unrestricted to an external listener. Therefore, confidentiality is RECOMMENDED.

a)のソース - レシーバ文脈における主な脅威は、可能なパケットの偽造を介してサービス拒否攻撃に関するものです。偽造は、ソースからのパケットの傍受や変形の形態をとることができる、またはそれは単に流通チャネルに誤ったパケットを注入することができます。これらの攻撃に対抗するために、データの整合性とソースの信憑性は、ソーストラフィックに適用されなければなりません。盗聴の結果は、プロトコルの動作には影響しませんので、機密性は、この文脈では必須ではありません。しかし、機密性なしに、個人およびグループの特性へのアクセスは、情報が外部のリスナーへの無制限のだろう。そのため、機密性が推奨されます。

b) The threats in the receiver-to-source context concern the same kinds of attacks, but are considered less important than the downstream traffic compromise. All the security weaknesses are also applicable to the current RTP/RTCP security model, and therefore only recommendations towards protection from compromise are made. Data integrity is RECOMMENDED to ensure that interception and modification of an individual receiver's RTCP traffic can be detected. This would protect against the false influence of group control information and the potentially more serious compromise of future services provided by the distribution functionality. In order to ensure security, data integrity and authenticity of receiver traffic is therefore also RECOMMENDED. With respect to data confidentiality, the same situation applies as in the first context, and it is RECOMMENDED that precautions be taken to protect the privacy of the data.

b)は、同じ種類の攻撃の受信機 - ソースコンテキストの懸念で脅威が、下流トラフィック妥協よりも重要と考えられています。すべてのセキュリティ上の弱点は、現在のRTP / RTCPのセキュリティモデルに適用されているので、妥協からの保護に向けた唯一の勧告がなされています。データの整合性を検出することができ、個々の受信者のRTCPトラフィックの傍受や修正を確保することをお勧めします。これは、グループ制御情報と配信機能により提供される将来のサービスの潜在的に深刻な妥協の虚偽の影響から保護します。セキュリティを確保するためには、受信トラフィックのデータの整合性と信頼性は、そのためにも推奨されます。データの機密性に関しては、同じような状況は、最初のコンテキストのように適用され、注意がデータのプライバシーを保護するために取られることが推奨されます。

c) The threats to the receiver-to-feedback-target context are similar to those in the receiver-to-source context, and thus the recommendations to protect against them are similar.

C)レシーバ・ツー・フィードバックターゲットコンテキストに対する脅威は、レシーバ・ソースコンテキストと同様であるので、それらから保護するための推奨事項は、類似しています。

However, there are a couple situations with broader issues to solve, which are beyond the scope of this document.

しかし、このドキュメントの範囲を超えて解決する幅広い問題、とのカップルの状況があります。

1. An endpoint experiencing DDoS or the side effects of a misconfigured RTCP session may not even be a participant in the session, i.e., may not be listening on the respective port number and may even support RTCP, so it will be unable to react within RTCP. Determining that there is a problem will be up to network administrators and, possibly, anti-malware software that can perform correlation across receiver nodes.

1.エンドポイントのDDoS攻撃を経験したか、誤って設定RTCPセッションの副作用もセッションに参加できない場合があり、すなわち、それぞれのポート番号でリッスンすることはできませんし、内部に反応することはできませんのででも、RTCPをサポートすることが可能RTCP。問題は、ネットワーク管理者と、受信ノード間の相関を実行することができ、おそらく、アンチマルウェアソフトウェアまでであろうがあると判断。

2. With misconfiguration, unfortunately the normally desirable usage of SRTP and SRTCP becomes undesirable. Because the packet content is encrypted, neither the misconfigured Feedback Target nor the network administrator have the ability to determine the root cause of the traffic.

設定ミスで2は、残念ながら、SRTPとSRTCPの通常望ましい使い方は望ましくなります。パケットの内容は暗号化されているので、誤って設定フィードバック目標やネットワーク管理者でもないが、トラフィックの根本的な原因を決定する能力を持っています。

In the case where the misconfigured Feedback Target happens to be a node participating in the session or is an RTCP-enabled node, the Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. As this type of packet MUST be included in every RTCP packet originated by the Distribution Source, all receivers would be able to obtain the corrected Feedback Target information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late-session arrivals. The only caveat is that the misconfigured Feedback Target is largely uninvolved in the repair of this situation and thus relies on others for the detection of the problem.

誤設定フィードバック目標は、セッションに参加したノードであることを起こるまたはRTCP対応ノードである場合には、フィードバック目標アドレスブロックは、受信機の代替ユニキャストRTCPフィードバックアドレスをシグナリングする配信元のための動的機構を提供します。このタイプのパケットは、配布ソースによって発信すべてのRTCPパケットに含まれなければならないとして、すべての受信機は、修正フィードバックターゲット情報を得ることができるであろう。このように、受信機の動作はしても、パケットロス時や後期セッション到着があるの顔に一貫している必要があります。唯一の注意点は、設定に誤りフィードバック目標は、このような状況の修復に大幅に関与しないということであるため、問題の検出のために他人に依存しています。

An additional security consideration, which is not a component of this specification but which has a direct influence upon the general security, is the origin of the session-initiation data. This involves the SDP parameters that are communicated to the members prior to the start of the session via channels such as an HTTP server, email, SAP, or other means. It is beyond the scope of this document to place any strict requirements on the external communication of such information; however, suitably secure SDP communication approaches are outlined in Section 11.7.

本明細書の構成要素ではなく、追加のセキュリティの考慮事項は、一般的なセキュリティの際に直接影響を有するセッション開始データの起源です。これは、HTTPサーバ、電子メール、SAP、または他の手段のようなチャネルを介して前のセッションの開始をメンバーに伝達されるSDPパラメータを含みます。それは、このような情報の外部通信上の任意の厳格な要件を配置するには、この文書の範囲外です。しかし、適切に安全なSDP通信アプローチは、セクション11.7に概説されています。

11.5. Discussion of Trust Models
11.5. トラストモデルの議論

As identified in the previous sections, source authenticity is a fundamental requirement of the protocol. However, it is important to also clarify the model of trust that would be acceptable to achieve this requirement. There are two fundamental models that apply in this instance: a) The shared-key model, where all authorized group members share the same key and can equally encrypt/decrypt the data. This method assumes that an out-of-band method is applied to the distribution of the shared group key, ensuring that every key-holder is individually authorized to receive the key and, in the event of member departures from the group, a re-keying exercise can occur. The advantage of this model is that the costly processing associated with one-way key-authentication techniques is avoided, as well as the need to execute additional cipher operations with alternative key sets on the same data set, e.g., in the event that data confidentiality is also applied. The disadvantage is that, for very large groups where the receiver set becomes effectively untrusted, a shared key does not offer much protection.

前のセクションで識別されるように、ソース真偽は、プロトコルの基本的な要件です。しかし、また、この要件を達成するために許容可能である信頼のモデルを明確にすることが重要です。すべての許可グループメンバーが同じ鍵を共有し、均等にデータを復号化/暗号化することができA)共有鍵モデル:この例では適用二つの基本的なモデルがあります。この方法は、すべてのキー・ホルダーを個別キーと、グループからメンバを逸脱した場合に、再を受信するために認可されていることを確認して、アウトオブバンド方式を共有グループ鍵の配布に適用されることを前提としていキーイング運動が発生する可能性があります。このモデルの利点は、データの機密性のイベントでは、同じデータセットの代替キーセット、例えばに追加の暗号操作を実行する必要があるだけでなく、一方向鍵認証技術に関連するコストのかかる処理が回避されていることです適用されます。欠点は、受信機のセットが効果的に信頼されていないとなり非常に大規模なグループ、共有キーのための多くの保護を提供していない、ということです。

b) The public-key authentication model, using cryptosystems such as RSA-based or PGP authentication, provides a more secure method of source authentication at the expense of generating higher processing overhead. This is typically not recommended for real-time data streams but, in the case of RTCP reports, which are distributed with a minimum interval of 5 seconds, this may be a viable option (the processing overhead might still be too great for small, low-powered devices and should therefore be considered with caution). Wherever possible, however, the use of public key source authentication is preferable to the shared key model identified above.

例えばRSAベースまたはPGP認証などB)公開鍵認証モデルを用いて暗号は、より高い処理オーバーヘッドを発生さを犠牲にしてソース認証のより安全な方法を提供します。これは、(処理のオーバーヘッドがまだ低い、小型のためには大きすぎるかもしれない、通常のリアルタイム・データ・ストリームのために推奨されず、5秒の最小間隔と一緒に配布され、報告RTCPの場合には、これは現実的な選択肢かもしれ)デバイス-poweredしたがって、慎重に考慮されるべきです。可能な限り、しかし、公開鍵ソース認証の使用は、上記で同定共有鍵モデルに好適です。

As concerns requirements for protocol acceptability, either model is acceptable although it is RECOMMENDED that the more secure public-key-based options be applied wherever possible.

より安全な公開鍵ベースのオプションは、可能な限り適用されることをお勧めしますが、プロトコルの受容のための懸念の要件としては、どちらかのモデルが許容可能です。

11.6. Recommended Security Solutions
11.6. 推奨セキュリティソリューション

This section presents some existing security mechanisms that are RECOMMENDED to suitably address the requirements outlined in Section 11.5. This is only intended as a guideline and it is acknowledged that there are other solutions that would also be suitable to comply with the specification.

このセクションでは、適切に11.5節で概説した要件に対応するために推奨されているいくつかの既存のセキュリティメカニズムを提供します。これはガイドラインとしてのみ意図され、また、仕様に準拠するには適しているであろう他のソリューションがあることが認められています。

11.6.1. Secure Distribution of SDP Parameters
11.6.1. SDPパラメータの安全な配布

a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters for the session SHOULD use a secure mechanism such as the SAP authentication framework, which allows an authentication certificate to be attached to the session announcements. Other methods might involve HTTPS or signed email content from a trusted source. However, some more commonly used techniques for distributing session information and starting media streams are the Real-Time Streaming Protocol (RTSP) [25] and SIP [14].

A)SAP、HTTPS、電子メール - そのような認証証明書は、セッション告知に取り付けることを可能にするSAP認証フレームワーク、などの安全なメカニズムを使用するべきであるセッションのSDPパラメータの初期分布。他の方法は、HTTPSまたは信頼できるソースから署名付き電子メールの内容を伴うかもしれません。しかし、セッション情報を配信し、メディアストリームを開始するためのいくつかのより一般的に使用される技術は、リアルタイムストリーミングプロトコル(RTSP)[25]とSIP [14]です。

b) RTSP -- RTSP provides a client- or server-initiated stream control mechanism for real-time multimedia streams. The session parameters are conveyed using SDP syntax and may adopt standard HTTP authentication mechanisms in combination with suitable network (e.g., IPsec)- or transport (e.g., Transport Layer Security (TLS))-level security.

B)RTSP - RTSPは、リアルタイムのマルチメディアストリームのためのクライアント - またはサーバー開始ストリーム制御メカニズムを提供します。セッション・パラメータは、SDP構文を使用して搬送され、適切なネットワーク(例えば、IPsecの)と組み合わせて、標準的なHTTP認証メカニズムを採用することができる - または輸送(例えば、トランスポート層セキュリティ(TLS)) - レベルのセキュリティ。

c) SIP -- A typical use of SIP involving a unicast feedback identifier might be a client wishing to dynamically join a multi-party call on a multicast address using unicast RTCP feedback. The client would be required to authenticate the SDP session descriptor information returned by the SIP server. The recommended method for this, as outlined in the SIP specification [14], is to use an S/MIME message body containing the session parameters signed with an acceptable certificate.

C)SIP - ユニキャストフィードバック識別子を含むSIPの典型的な使用は、動的ユニキャストRTCPのフィードバックを使用してマルチキャストアドレスにマルチパーティコールに参加を希望するクライアントであるかもしれません。クライアントは、SIPサーバから返されたSDPセッション記述情報を認証するために必要とされるであろう。このために推奨される方法は、SIP仕様[14]に概説するように、許容される証明書で署名されたセッションパラメータを含むS / MIMEメッセージの本文を使用することです。

For the purposes of this profile, it is acceptable to use any suitably secure authentication mechanism that establishes the identity and integrity of the information provided to the client.

このプロファイルの目的のためには、クライアントに提供される情報の識別情報との整合性を確立任意の適切な安全な認証メカニズムを使用することが可能です。

11.6.2. Suitable Security Solutions for RTP Sessions with Unicast Feedback

11.6.2. ユニキャストフィードバック付きRTPセッションに適したセキュリティソリューション

a) SRTP -- SRTP [3] is the recommended Audio/Video Transport (AVT) security framework for RTP sessions. It specifies the general packet formats and cipher operations that are used and provides the flexibility to select different stream ciphers based on preference/requirements. It can provide confidentiality of the RTP and RTCP packets as well as protection against integrity compromise and replay attacks. It provides authentication of the data stream using the shared-key trust model. Any suitable key-distribution mechanism can be used in parallel to the SRTP streams.

A)SRTP - SRTP [3] RTPセッションのための推奨オーディオ/ビデオトランスポート(AVT)セキュリティフレームワークです。これは、使用される一般的なパケットフォーマット及び暗号操作を指定し、優先/要件に基づいて異なるストリーム暗号を選択する柔軟性を提供します。これは、RTPとRTCPパケットだけでなく、整合性の妥協とリプレイ攻撃に対する保護の機密性を提供することができます。これは、共有鍵信頼モデルを使用して、データ・ストリームの認証を提供します。任意の適切な鍵配布機構は、SRTPストリームと並列に使用することができます。

b) IPSEC -- A more general group security profile that might be used is the Group Domain of Interpretation [23], which defines the process of applying IPSec mechanisms to multicast groups. This requires the use of the Encapsulating Security Payload (ESP) in tunnel mode as the framework and it provides the capability to authenticate -- either using a shared key or individually through public-key mechanisms. It should be noted that using IPSec would break the 'transport-independent' condition of RTP and would therefore not be useable for anything other than IP-based communication.

B)IPSEC - 使用されるかもしれない、より一般的なグループセキュリティプロファイルは、解釈のグループのドメインである[23]、マルチキャストグループへのIPSec機構を適用するプロセスを定義します。これは、フレームワークとしてトンネルモードでカプセル化セキュリティペイロード(ESP)の使用を必要とし、それが認証する機能を提供する - のいずれかの公開鍵機構を介して、共有鍵、または個別に使用して。 IPSecを使用してRTPの「トランスポートに依存しない」状態を破るため、IPベースの通信以外に使用可能ではないであろうことに留意すべきです。

c) TESLA - Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [24] is a scheme that provides a more flexible approach to data authentication using time-based key disclosure. The authentication uses one-way, pseudo-random key functions based on key chain hashes that have a short period of authenticity based on the key disclosure intervals from the source. As long as the receiver can ensure that the encrypted packet is received prior to the key disclosure by the source, which requires loose time synchronization between source and receivers, it can prove the authenticity of the packet. The scheme does introduce a delay into the packet distribution/decryption phase due to the key disclosure delay; however, the processing overhead is much lower than other standard public-key mechanisms and therefore may be more suited to small or energy-restricted devices.

C)TESLA - タイミングの効率的な流れ損失トレラント認証(テスラ)[24]は、時間ベースのキーの開示を使用して、データ認証のより柔軟なアプローチを提供する方式です。認証は一方向、ソースから鍵開示間隔に基づいて真偽の短い期間を有するキーチェーンのハッシュに基づいて疑似ランダムキー機能を使用します。限り、受信機は暗号化されたパケットは、ソースと受信機との間の緩い時間同期を必要とソースによってキー開示の前に受信されることを保証することができるように、そのパケットの正当性を証明することができます。スキーム起因鍵開示遅延パケット分配/復号相に遅延を導入しません。しかし、処理のオーバーヘッドは、他の標準の公開鍵機構よりもはるかに低く、したがって、小さなまたはエネルギー制限装置に適してもよいです。

11.6.3. Secure Key Distribution Mechanisms
11.6.3. キー配布メカニズムを確保

a) MIKEY -- Multimedia Internet KEYing (MIKEY) [29] is the preferred solution for SRTP sessions providing a shared group-key distribution mechanism and intra-session rekeying facilities. If a partly protected communication channel exists, keys may also be conveyed using SDP as per [27].

A)MIKEY - マルチメディアインターネットキーイング(MIKEY)[29]共有グループ鍵配布機構とイントラセッションリキー機能を提供SRTPセッションのための好ましい解決策です。部分的に保護された通信チャネルが存在する場合、キーはまた、[27]に従ってSDPを用いて搬送することができます。

b) GSAKMP -- The Group Secure Association Key Management Protocol (GSAKMP) is the general solution favored for Multicast Secure group-key distribution. It is the recommended key distribution solution for Group Domain of Interpretation (GDOI) [RFC3547] sessions.

B)GSAKMP - グループセキュア協会鍵管理プロトコル(GSAKMP)は、マルチキャストグループセキュアキーの配布のために好まれる一般的なソリューションです。それは解釈のグループドメイン(GDOI)[RFC3547]セッションのために推奨される鍵配布ソリューションです。

11.7. Troubleshooting Misconfiguration
11.7. トラブルシューティングの設定ミス

As noted above, the security mechanisms in place will not help in case an authorized source spreads properly authenticated and integrity-protected yet incorrect information about the Feedback Target. In this case, the accidentally communicated Feedback Target will receive RTCP packets from a potentially large group of receivers -- the RTCP rate fortunately limited by the RTCP timing rules.

上述したように、代わりにセキュリティメカニズムは、許可されたソースがフィードバック目標について正しく認証と完全性保護された、まだ誤った情報を拡散する場合には助けにはなりません。幸いRTCPタイミング規則によって制限されるRTCPレート - この場合には、誤って伝えフィードバックターゲット受信機の潜在的に大きなグループからRTCPパケットを受信します。

Yet, the RTCP packets do not provide much context information and, if encrypted, do not provide any context, making it difficult for the entity running (the network with) the Feedback Target to debug and correct this problem, e.g., by tracking down and informing the origin of the misconfiguration.

しかし、RTCPパケットは、多くのコンテキスト情報を提供しないと、暗号化されている場合、追跡により、例えば、実行中のエンティティ(とネットワーク)のデバッグにフィードバック目標のためにそれを困難に、任意のコンテキストを提供し、この問題を修正していないと設定ミスの起源を知らせます。

One suitable approach may be to provide explicit context information in RTCP packets that would allow determining the source. While such an RTCP packet could be defined in this specification, it would be of no use when using SRTP/SRTCP and encryption of RTCP reports. Therefore, and because the extensions in this document may not be the only case that may face such a problem, it is desirable to find a solution that is applicable to RTP at large. Such mechanisms are for further study in the AVT WG.

一つの適切なアプローチは、ソースを決定することを可能にするRTCPパケット内の明示的なコンテキスト情報を提供することができます。このようRTCPパケットはこの仕様で定義することができますがRTCPのSRTP / SRTCPと暗号化を使用した場合、それは役に立たないであろう報告しています。この文書に記載されている拡張機能は、このような問題に直面するかもしれない唯一の場合ではないかもしれないので、したがって、そして、大でRTPに適用することができる解決策を見つけることが望ましいです。このようなメカニズムは、AVT WGでのさらなる研究のためのものです。

12. Backwards Compatibility
12.後方互換性

The use of unicast feedback to the source should not present any serious backwards compatibility issues. The RTP data streams should remain unaffected, as should the RTCP packets from the Media Sender(s) that continue to enable inter-stream synchronization in the case of multiple streams. The unicast transmission of RTCP data to a source that does not have the ability to redistribute the traffic either by simple reflection or through summaries could have serious security implications, as outlined in Section 11, but would not actually break the operation of RTP. For RTP-compliant receivers that do not understand the unicast mechanisms, the RTCP traffic may still reach the group in the event that an ASM distribution network is used, in which case there may be some duplication of traffic due to the reflection channel, but this should be ignored. It is anticipated, however, that typically the distribution network will not enable the receiver to multicast RTCP traffic, in which case the data will be lost and the RTCP calculations will not include those receivers. It is RECOMMENDED that any session that may involve non-unicast-capable clients should always use the simple packet-reflection mechanism to ensure that the packets received can be understood by all clients.

ソースへのユニキャストフィードバックの使用は重大な後方互換性の問題を提示してはなりません。複数のストリームの場合のストリーム間の同期を可能にするために、引き続きメディア送信者(複数可)からRTCPパケットが必要としてRTPデータストリームは、影響を受けないままであるべきです。第11節で概説したように、深刻なセキュリティ上の意味合いを持っている可能性があり、単純な反射によって、または要約のいずれかを介してトラフィックを再分配する能力を持っていませんが、実際にはRTPの操作を壊さないだろうソースにRTCPデータのユニキャスト送信。ユニキャストメカニズムを理解していないRTP準拠の受信機のために、RTCPトラフィックは依然として反射によるチャネルへのトラフィックのいくつかの重複があるかもしれない、その場合、ASM分配ネットワークが使用された場合にグループに達するが、このことができます無視されるべきです。典型的には、分配ネットワークは、データが失われ、RTCP計算がそれらの受信機を含んでいないであろう場合にRTCPトラフィックをマルチキャストするために受信機を有効にしないであろうことが予想されます。非ユニキャスト可能なクライアントを含むことができる任意のセッションは常に受信されたパケットは、すべてのクライアントによって理解することができることを確実にするために、単純なパケット反射機構を使用することが推奨されます。

13. IANA Considerations
13. IANAの考慮事項

The following contact information shall be used for all registrations included here:

以下の連絡先情報はここに含まれるすべての登録に使用しなければなりません。

Contact: Joerg Ott mail: jo@acm.org tel: +358-9-470-22460

連絡先:イェルクオットメール:jo@acm.org TEL:+ 358-9-470-22460

Based on the guidelines suggested in [2], a new RTCP packet format has been registered with the RTCP Control Packet type (PT) Registry:

[2]、新しいRTCPパケットフォーマットはRTCP制御パケットタイプ(PT)レジストリに登録されているに提案ガイドラインに基づきます。

Name: RSI Long name: Receiver Summary Information Value: 209 Reference: This document.

名前:RSIロング名:レシーバの概要情報値:209参照:このドキュメント。

This document defines a substructure for RTCP RSI packets. A new sub-registry has been set up for the sub-report block type (SRBT) values for the RSI packet, with the following registrations created initially:

この文書では、RTCP RSIパケットのためのサブ構造を定義します。新しいサブレジストリは、最初に作成し、以下の登録で、RSIパケットのためのサブレポートのブロックタイプ(SRBT)の値に設定されています。

Name: IPv4 Address Long name: IPv4 Feedback Target Address Value: 0 Reference: This document.

名前:IPv4のフィードバック目標アドレス値:0参考:この文書はIPv4ロングネームアドレス。

Name: IPv6 Address Long name: IPv6 Feedback Target Address Value: 1 Reference: This document.

名前:IPv6のフィードバック目標アドレス値:1つの参照:このドキュメントIPv6のロングネームアドレス。

Name: DNS Name Long name: DNS Name indicating Feedback Target Address Value: 2 Reference: This document.

名前:DNS名ロング名:フィードバック目標アドレス値を示すDNS名:2参照:このドキュメント。

Name: Loss Long name: Loss distribution Value: 4 Reference: This document.

名前:ロスロングネーム:損失分布値:4参考:このドキュメント。

Name: Jitter Long name: Jitter Distribution Value: 5 Reference: This document.

名前:ジッタロングネーム:ジッタ分布値:5参考:このドキュメント。

Name: RTT Long name: Round-trip time distribution Value: 6 Reference: This document.

名前:RTTロング名:ラウンドトリップ時間分布値:6参考:このドキュメント。

Name: Cumulative loss Long name: Cumulative loss distribution Value: 7 Reference: This document.

名前:累積損失ロングネーム:累積損失分布値:7参考:このドキュメント。

Name: Collisions Long name: SSRC Collision list Value: 8 Reference: This document.

名前:衝突ロングネーム:SSRC衝突リスト値:8参考:このドキュメント。

Name: Stats Long name: General statistics Value: 10 Reference: This document.

名前:統計ロング名:一般的な統計値:10参考:このドキュメント。

Name: RTCP BW Long name: RTCP Bandwidth indication Value: 11 Reference: This document.

名前:RTCP BWロングネーム:RTCP帯域幅の指示値:11参考:このドキュメント。

Name: Group Info Long name: RTCP Group and Average Packet size Value: 12 Reference: This document.

名前:グループ情報ロング名:RTCPグループと平均パケットサイズ値:12参考:このドキュメント。

The value 3 shall be reserved as a further way of specifying a Feedback Target Address. The value 3 MUST only be allocated for a use defined in an IETF Standards Track document.

値3は、フィードバック目標アドレスを指定するさらなる方法として確保されなければなりません。値3は、IETF標準化過程文書で定義された使用のために割り当てられなければなりません。

Further values may be registered on a first come, first served basis. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated sub-report block. The general registration procedures of [5] apply.

さらに、値が先着順に登録することができます。各新規登録の場合、恒久的な安定、かつ公的にアクセス可能な文書は、その登録パラメータだけでなく、関連するサブレポートのブロックの構文と意味のセマンティクスを指定する存在することが必須です。 [5]適用の一般的な登録手順。

In the registry for SDP parameters, the attribute named "rtcp-unicast" has been registered as follows:

次のようにSDPパラメータのレジストリでは、「RTCP-ユニキャスト」という名前の属性が登録されています:

SDP Attribute ("att-field"):

(「フィールドへ」)SDP属性:

Attribute Name: rtcp-unicast Long form: RTCP Unicast feedback address Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: RFC 5760 Reference: RFC 5760 Values: See this document.

属性名:RTCP-ユニキャストロングフォーム:名前のRTCPユニキャストフィードバックアドレスタイプ:属性のATTフィールドタイプ:メディアは文字セットにのみ対象レベル:なし目的:RFC 5760参照:RFC 5760の値:このドキュメントを参照してください。

14. References
14.参考文献
14.1. Normative References
14.1. 引用規格

[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[2] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。

[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[3] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル(SRTP)"、RFC 3711、2004年3月。

[4] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.

[4]クイン、B.とR.フィンレイソン、 "セッション記述プロトコル(SDP)ソースフィルタ"、RFC 4570、2006年7月。

[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[5]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[6] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。

[7] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.

、RFC 3605、2003年10月[7]のHuitema、C.、 "セッション記述プロトコル(SDP)でのリアルタイム制御プロトコル(RTCP)属性"。

[8] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.

[8]マイヤー、D.、ロッケル、R.、およびG.シェパード、 "232/8でソース固有プロトコル独立マルチキャスト"、BCP 120、RFC 4608、2006年8月。

[9] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.

[9]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "インターネットグループ管理プロトコルバージョン3(IGMPv3の)およびマルチキャストリスナ発見プロトコルバージョン2(MLDv2の)ソース固有のマルチキャストのための使用"、RFC 4604、8月2006。

[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.

[10] Casner、S.、 "セッション記述プロトコル(SDP)RTP制御プロトコル(RTCP)帯域の帯域幅修飾子"、RFC 3556、2003年7月。

[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[11] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

[12] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.

[12]レノックス、J.、オット、J.、およびT. Schierl、RFC 5576、2009年6月 "ソース固有のメディアセッション記述プロトコル(SDP)の属性"。

[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[13]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

14.2. Informative References
14.2. 参考文献

[14] 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.

[14]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[15] 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.

[15]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック(RTP / AVPF)リアルタイムトランスポート制御プロトコル(RTCP)の拡張RTPプロファイル」、RFC 4585、2006年7月。

[16] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.

[16] Pusateri、T.、 "距離ベクトルマルチキャストルーティングプロトコル"、進歩、2003年10月に作業。

[17] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[17]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード(PIM-SM):プロトコル仕様(改訂)"、RFC 4601、2006年8月。

[18] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.

[18]アダムス、A.、ニコラス、J.、およびW. Siadak、 "プロトコル独立マルチキャスト - デンスモード(PIM-DM):プロトコル仕様(改訂)"、RFC 3973、2005年1月。

[19] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[19]ベイツ、T.、チャンドラ、R.、キャッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 4760、2007年1月。

[20] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[20]フェナー、B.、エド。、およびD.マイヤー、エド。、 "は、Multicast Source Discovery Protocol(MSDP)"、RFC 3618、2003年10月。

[21] Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.

[21]セッションディレクトリランデヴー(SDR)、マーク・ハンドリーとマルチメディア研究グループ、http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/でロンドン大学で開発されました。

[22] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[22]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。

[23] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.

[23] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。

[24] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.

[24] Perrig、A.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証(テスラ):マルチキャスト発信元認証は、はじめの変換"、RFC 4082、 2005年6月。

[25] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.

[25] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル(RTSP)"、RFC 2326、1998年4月。

[26] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.

[26]フリードマン、T.、エド。、カセレス、R.、エド。、およびA.クラーク、エド。、 "RTP制御プロトコルの拡張レポート(RTCP XR)"、RFC 3611、2003年11月。

[27] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.

[27]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル(SDP)のセキュリティの説明"、RFC 4568、2006年7月。

[28] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.

[28]オット、J.およびE.カララ、RFC 5124、2008年2月 "リアルタイムトランスポート制御プロトコル(RTCP)ベースのフィードバック(RTP / SAVPF)にSecure RTPプロファイル拡張"。

[29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.

[29] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK.ノルウェー、 "MIKEY:マルチメディアインターネットキーイング"、RFC 3830、2004年8月。

Appendix A. Examples for Sender-Side Configurations

送信側の構成については、付録A.例

This appendix describes a few common setups, focusing on the contribution side, i.e., the communications between the Media Sender(s) and the Distribution Source. In all cases, the same session description may be used for the distribution side as defined in the main part of this document. This is because this specification defines only the media stream setup between the Distribution Source and the receivers.

この付録では、拠出側に焦点を当て、いくつかの一般的なセットアップを説明し、すなわち、メディア送信者(S)と配布ソースとの間の通信。この文書の主要部分で定義されている全ての場合において、同一のセッション記述は、配信側に使用することができます。この仕様は、配布元と受信機の間の唯一のメディアストリームの設定を定義するためです。

A.1. One Media Sender Identical to the Distribution Source

A.1。配布ソースに同一つのメディア送信者

In the simplest case, the Distribution Source is identical to the Media Sender as depicted in Figure 3. Obviously, no further configuration for the interaction between the Media Sender and the Distribution Source is necessary.

図3に示すように、最も単純な場合では、配信元は明らかに、メディア送信者と配信元との間の相互作用のためのさらなる構成が必要でないメディア送信者と同一です。

                          Source-specific
         +--------+          Multicast
         |        |     +----------------> R(1)
         |M   D S |     |                    |
         |E   I O |  +--+                    |
         |D   S U |  |  |                    |
         |I   T R |  |  +-----------> R(2)   |
         |A   R C |->+-----  :          |    |
         |  = I E |  |  +------> R(n-1) |    |
         |S   B   |  |  |          |    |    |
         |E   U   |  +--+--> R(n)  |    |    |
         |N   T   |          |     |    |    |
         |D   I   |<---------+     |    |    |
         |E   O   |<---------------+    |    |
         |R   N   |<--------------------+    |
         |        |<-------------------------+
         +--------+            Unicast
        

Figure 3: Media Source == Distribution Source

図3:メディアソース==配布ソース

A.2. One Media Sender

A.2。一つのメディア送信者

In a slightly more complex scenario, the Media Sender and the Distribution Source are separate entities running on the same or different machines. Hence, the Media Sender needs to deliver the media stream(s) to the Distribution Source. This can be done either via unicasting the RTP stream, via ASM multicast, or via SSM. In this case, the Distribution Source is responsible for forwarding the RTP packets comprising the media stream and the RTCP Sender Reports towards the receivers and conveying feedback from the receivers, as well as from itself, to the Media Sender.

もう少し複雑なシナリオでは、メディアの送信者と配布ソースは、同じまたは異なるマシン上で実行されている別のエンティティです。したがって、メディア送信者は配布ソースにメディアストリーム(複数可)を提供する必要があります。これは、RTPストリームをユニキャストを経由して、ASMマルチキャストを経由して、またはSSMのいずれかを介して行うことができます。この場合、配布ソースは、メディアSenderに、自身からだけでなく、メディアストリームを備えたRTPパケットと受信機に向けたRTCP送信レポートを転送し、受信機からのフィードバックを搬送するための責任があります。

This scenario is depicted in Figure 4. The communication setup between the Media Sender and the Distribution Source may be statically configured or SDP may be used in conjunction with some signaling protocol to convey the session parameters. Note that it is a local configuration matter of the Distribution Source how to associate a session between the Media Sender and itself (the Contribution session) with the corresponding session between itself and the receivers (the Distribution session).

このシナリオでは、メディア送信者と配信元との間の通信設定を静的に設定してもよいし、SDPは、セッションパラメータを伝達するために、いくつかのシグナリングプロトコルと組み合わせて使用​​することができる。図4に示されています。それは自分自身と受信機(配布セッション)の間に対応するセッションでメディアSenderと自身(の貢献セッション)の間のセッションを関連付ける方法を配布ソースのローカル設定の問題であることに注意してください。

                                      Source-specific
                        +-----+          Multicast
                        |     |     +----------------> R(1)
                        | D S |     |                    |
                        | I O |  +--+                    |
                        | S U |  |  |                    |
        +--------+      | T R |  |  +-----------> R(2)   |
        | Media  |<---->| R C |->+-----  :          |    |
        | Sender |      | I E |  |  +------> R(n-1) |    |
        +--------+      | B   |  |  |          |    |    |
                        | U   |  +--+--> R(n)  |    |    |
                        | T   |          |     |    |    |
                        | I   |<---------+     |    |    |
                        | O   |<---------------+    |    |
                        | N   |<--------------------+    |
                        |     |<-------------------------+
                        +-----+            Unicast
        

Contribution Distribution Session Session (unicast or ASM) (SSM)

貢献の配布セッションのセッション(ユニキャストまたはASM)(SSM)

Figure 4: One Media Sender Separate from Distribution Source

図4:つのメディア送信者の配信元別に

A.3. Three Media Senders, Unicast Contribution

A.3。 3つのメディア送信者、ユニキャストの貢献

Similar considerations apply if three Media Senders transmit to an SSM multicast group via the Distribution Source and individually send their media stream RTP packets via unicast to the Distribution Source.

3つのメディア送信者は配布ソースを経由してSSMマルチキャストグループに送信し、個別の配信元にユニキャストを経由して自分のメディアストリームのRTPパケットを送信する場合、同様の考察が適用されます。

In this case, the responsibilities of the Distribution Source are a superset to the previous case; the Distribution Source also needs to relay media traffic from each Media Sender to the receivers and to forward (aggregated) feedback from the receivers to the Media Senders. In addition, the Distribution Source relays RTCP packets (SRs) from each Media Sender to the other two.

この場合、配布ソースの責任は、前のケースにスーパーセットです。配布ソースも受信機に各メディアの送信者からのメディアトラフィックを中継するようにし、受信機からのメディア送信者に(集約)フィードバックを転送する必要があります。また、他の二つに各メディアの送信者からの配布ソースリレーRTCPパケット(SRS)。

The configuration of the Media Senders is identical to the previous case. It is just the Distribution Source that must be aware that there are multiple senders and then perform the necessary relaying. The transport address for the RTP session at the Distribution Source may be identical for all Media Senders (which may make correlation easier) or different addresses may be used.

メディア送信者の構成は、前述の場合と同じです。これは、複数の送信者があることを認識し、その後、必要に応じて中継を行わなければならないだけの配信元です。配布元のRTPセッションのためのトランスポートアドレスは(相関を容易に可能性がある)、すべてのメディアの送信者に対して同一であってもよく、または異なるアドレスを使用することができます。

This setup is depicted in Figure 5.

この設定は、図5に描かれています。

                                   Source-specific
                     +-----+          Multicast
     +--------+      |     |     +----------------> R(1)
     | Media  |<---->| D S |     |                    |
     |Sender 1|      | I O |  +--+                    |
     +--------+      | S U |  |  |                    |
                     | T R |  |  +-----------> R(2)   |
     +--------+      | R C |->+-----  :          |    |
     | Media  |<---->| I E |  |  +------> R(n-1) |    |
     |Sender 2|      | B   |  |  |          |    |    |
     +--------+      | U   |  +--+--> R(n)  |    |    |
                     | T   |          |     |    |    |
     +--------+      | I   |<---------+     |    |    |
     | Media  |<---->| O   |<---------------+    |    |
     |Sender 3|      | N   |<--------------------+    |
     +--------+      |     |<-------------------------+
                     +-----+            Unicast
        
           Contribution               Distribution
             Session                    Session
            (unicast)                    (SSM)
        

Figure 5: Three Media Senders, Unicast Contribution

図5:3つのメディア送信者、ユニキャスト貢献

A.4. Three Media Senders, ASM Contribution Group

A.4。 3つのメディア送信者、ASMの貢献グループ

In this final example, the individual unicast contribution sessions between the Media Senders and the Distribution Source are replaced by a single ASM contribution group (i.e., a single common RTP session). Consequently, all Media Senders receive each other's traffic by means of IP-layer multicast and the Distribution Source no longer needs to perform explicit forwarding between the Media Senders. Of course, the Distribution Source still forwards feedback information received from the receivers (optionally as summaries) to the ASM contribution group.

この最後の例では、メディア送信者及び配布元との間の個々のユニキャスト寄与セッションは、単一のASM寄与基(すなわち、単一の共通のRTPセッション)によって置換されています。その結果、すべてのメディア送信者は、IP層マルチキャストによって互いのトラフィックを受信しないと配布ソースは、もは​​やメディア送信者の間で明示的な転送を実行する必要があります。もちろん、配信元は依然としてASM寄与基に(任意に要約されるように)受信機から受信したフィードバック情報を転送します。

The ASM contribution group may be statically configured or the necessary information can be communicated using a standard SDP session description for a multicast session. Again, it is up to the implementation of the Distribution Source to properly associate the ASM contribution session and the SSM distribution sessions.

ASM寄与グループが静的に構成され得るか、または必要な情報は、マルチキャストセッションのための標準的なSDPセッション記述を使用して通信することができます。ここでも、それが適切にASMの貢献セッションとSSM配信セッションを関連付けるために配布ソースの実装次第です。

Figure 6 shows this scenario.

図6は、このシナリオを示しています。

                    _                   Source-specific
                   / \    +-----+          Multicast
     +--------+   |   |   |     |     +----------------> R(1)
     | Media  |<->| A |   | D S |     |                    |
     |Sender 1|   | S |   | I O |  +--+                    |
     +--------+   | M |   | S U |  |  |                    |
                  |   |   | T R |  |  +-----------> R(2)   |
     +--------+   | G |   | R C |->+-----  :          |    |
     | Media  |<->| r |<->| I E |  |  +------> R(n-1) |    |
     |Sender 2|   | o |   | B   |  |  |          |    |    |
     +--------+   | u |   | U   |  +--+--> R(n)  |    |    |
                  | p |   | T   |          |     |    |    |
     +--------+   |   |   | I   |<---------+     |    |    |
     | Media  |<->|   |   | O   |<---------------+    |    |
     |Sender 3|    \_/    | N   |<--------------------+    |
     +--------+           |     |<-------------------------+
                          +-----+            Unicast
        
              Contribution            Distribution
                Session                  Session
                 (ASM)                   (SSM)
        

Figure 6: Three Media Senders in ASM Group

図6:ASMグループの3つのメディア差出人

Appendix B. Distribution Report Processing at the Receiver

受信機では、付録B.分布レポート処理

B.1. Algorithm

B.1。アルゴリズム

Example processing of Loss Distribution Values

損失分布値の一例処理

X values represent the loss percentage. Y values represent the number of receivers.

Xの値は、損失の割合を表します。 Y値は、受信機の数を表します。

Number of x values is the NDB value

xの値の数は、NDB値であります

xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)

xrange =最大分布値(MADV) - 最小分布値(MnDV)

First data point = MnDV,first ydata

最初のデータポイント= MnDV、第YDATA

then

それから

For each ydata => xdata += (MnDV + (xrange / NDB))

各YDATA => XDATA + =(MnDV +(はxrange / NDB))のために

B.2. Pseudo-Code

B.2。擬似コード

Packet Variables -> factor,NDB,MnDVL,MaDV Code variables -> xrange, ydata[NDB],x,y

パケット変数 - >因子、NDB、MnDVL、MADVコード変数 - >はxrange、YDATA [NDB]、X、Y

xrange = MaDV - MnDV x = MnDV;

xrange = MADV - MnDV X = MnDV。

   for(i=0; i<NDB; i++) {
        y = (ydata[i] * factor);
        /*OUTPUT x and y values*/
        x += (xrange / NDB);
   }
        

B.3. Application Uses and Scenarios

B.3。アプリケーションが使用してシナリオ

Providing a distribution function in a feedback message has a number of uses for different types of applications. Although this appendix enumerates potential uses for the distribution scheme, it is anticipated that future applications might benefit from it in ways not addressed in this document. Due to the flexible nature of the summarization format, future extensions may easily be added. Some of the scenarios addressed in this section envisage potential uses beyond a simple SSM architecture, for example, single-source group topologies where every receiver may in fact also be capable of becoming the source. Another example may be multiple SSM topologies, which, when combined, make up a larger distribution tree.

フィードバックメッセージに分布関数を提供するアプリケーションの異なる種類の用途の数を有しています。この付録では、流通スキームのための潜在的な使用を列挙しますが、将来のアプリケーションは、このドキュメントでは扱われていない方法でそれの恩恵を受ける可能性があることが予想されます。要約形式の柔軟な性質のために、将来の拡張を容易に追加することができます。この節で取り上げたシナリオのいくつかは、例えば、単純なSSMアーキテクチャを越えて潜在的な用途を想定、すべての受信機は、実際には、ソースになることが可能であってもよいシングルソースグループトポロジ。別の例では、組み合わせた場合、より大きな配信ツリーを構成する複数のSSMトポロジであってもよいです。

A distribution of values is useful as input into any algorithm, multicast or otherwise, that could be optimized or tuned as a result of having access to the feedback values for all group members. Following is a list of example areas that might benefit from distribution information:

値の分布は、すべてのグループメンバーのためのフィードバック値へのアクセスを有する結果として最適化又は調整することができることを、任意のアルゴリズム、マルチキャストまたは他のに入力として有用です。配信情報の恩恵を受ける可能性がある例の領域は、次のとおりです。

- The parameterization of a multicast Forward Error Correction (FEC) algorithm. Given an accurate estimate of the distribution of reported losses, a source or other distribution agent that does not have a global view would be able to tune the degree of redundancy built into the FEC stream. The distribution might help to identify whether the majority of the group is experiencing high levels of loss, or whether in fact the high loss reports are only from a small subset of the group. Similarly, this data might enable a receiver to make a more informed decision about whether it should leave a group that includes a very high percentage of the worst-case reporters.

- マルチキャストの前方誤り訂正(FEC)アルゴリズムのパラメータ。報告された損害、チューニングするFECストリームに組み込まれた冗長性の度合いができるであろうグローバルな視野を持っていないソースまたは他のディストリビューションエージェントの分布の正確な推定を考えます。分布は、グループの大半は損失の高いレベルを経験しているかどうかを識別するのに役立つかもしれない、または実際にいるかどうか、高損失のレポートは、グループの小さなサブセットからのみです。同様に、このデータは、それは最悪の場合の記者の非常に高い割合を含むグループを残すべきかどうかについてのより多くの情報に基づいた意思決定を行うために受信機を可能にするかもしれません。

- The organization of a multicast data stream into useful layers for layered coding schemes. The distribution of packet losses and delay would help to identify what percentage of members experience various loss and delay levels, and thus how the data stream bandwidth might be partitioned to suit the group conditions. This would require the same algorithm to be used by both senders and receivers in order to derive the same results.

- マルチキャストデータの編成は、階層符号化方式のための有用な層にストリーム。パケットロスや遅延の分布は、データストリームの帯域幅は、グループ条件に合うように分割される可能性がありますどのようにこのように様々な損失や遅延のレベルを経験するメンバーの何パーセント識別するのに役立つ、となります。これは、同じ結果を導き出すためには送信側と受信側の両方が使用する同じアルゴリズムを必要とします。

- The establishment of a suitable feedback threshold. An application might be interested to generate feedback values when above (or below) a particular threshold. However, determining an appropriate threshold may be difficult when the range and distribution of feedback values is not known a priori. In a very large group, knowing the distribution of feedback values would allow a reasonable threshold value to be established, and in turn would have the potential to prevent message implosion if many group members share the same feedback value. A typical application might include a sensor network that gauges temperature or some other natural phenomenon. Another example is a network of mobile devices interested in tracking signal power to assist with hand-off to a different distribution device when power becomes too low.

- 適切なフィードバックしきい値の確立。アプリケーションが特定の閾値ときに上方(又は下方)フィードバック値を生成するために興味があるかもしれません。フィードバック値の範囲と分布が先験的に知られていない場合しかし、適切な閾値を決定することは困難であり得ます。非常に大規模なグループでは、フィードバック値の分布を知ることは、合理的な閾値を確立することを可能にする、ひいては多くのグループメンバーが同じフィードバック値を共有する場合、メッセージ内破を防止する可能性を有するであろう。典型的なアプリケーションは、温度またはいくつかの他の自然現象ゲージセンサネットワークを含むかもしれません。別の例では、パワーが低くなりすぎたときに異なる分配装置にハンドオフを支援するために信号電力を追跡することに興味のモバイル機器のネットワークです。

- The tuning of Suppression algorithms. Having access to the distribution of round-trip times, bandwidth, and network loss would allow optimization of wake-up timers and proper adjustment of the Suppression interval bounds. In addition, biased wake-up functions could be created not only to favor the early response from more capable group members but also to smooth out responses from subsequent respondents and to avoid bursty response traffic.

- 抑制アルゴリズムのチューニング。往復時間、帯域幅、およびネットワークの損失の分布へのアクセスを持つことは、ウェイクアップタイマーと抑制間隔境界の適切な調整の最適化が可能になります。また、偏ったウェイクアップ機能は、より有能なグループメンバーからの初期応答を支持するだけでなく、作成することができただけでなく、その後の回答者からの回答を滑らかにし、バースト性の応答トラフィックを避けるために。

- Leader election among a group of processes based on the maximum or minimum of some attribute value. Knowledge of the distribution of values would allow a group of processes to select a leader process or processes to act on behalf of the group. Leader election can promote scalability when group sizes become extremely large.

- いくつかの属性値の最大値または最小値に基づいてプロセスのグループの中でリーダー選挙。値の分布を知ることは、プロセスのグループは、グループを代表して行動するリーダー・プロセスまたはプロセスを選択することができるようになります。グループのサイズが非常に大きくなったときにリーダー選挙は、拡張性を促進することができます。

B.4. Distribution Sub-Report Creation at the Source

B.4。ソースのディストリビューションサブレポートの作成

The following example demonstrates two different ways to convey loss data using the generic format of a Loss sub-report block (Section 7.1.4). The same techniques could also be applied to representing other distribution types.

次の例では、損失、サブレポートブロック(セクション7.1.4)の一般的なフォーマットを使用して損失データを伝えるために二つの異なる方法を示しています。同じ技術はまた、他の配信タイプを表すにも適用することができます。

1) The first method attempts to represent the data in as few bytes as possible.

1)第一の方法は、できるだけ少ないバイトのデータを表現することを試みます。

2) The second method conveys all values without providing any savings in bandwidth.

2)第二の方法は、帯域幅内の任意の節約を設けることなく、すべての値を搬送します。

Data Set X values indicate loss percentage reported; Y values indicate the number of receivers reporting that loss percentage.

データセットのX値は、損失の割合が報告さを示しています。 Yの値は、その損失率を報告する受信機の数を示しています。

X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Y - 1000 | 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5

X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5

X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205

X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205

X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4

X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4

Constant value Due to the size of the multiplicative factor field being 4 bits, the maximum multiplicative value is 15.

定数値は4ビットである乗算係数フィールドのサイズに起因し、最大乗法値は15です。

The distribution type field of this packet would be value 1 since it represents loss data.

それは損失データを表すので、このパケットの分布型フィールドの値は1であろう。

Example: 1st Method

例:第一の方法

Description The minimal method of conveying data, i.e., small amount of bytes used to convey the values.

説明、値を伝えるために使用されるバイト、すなわち、少量のデータを搬送するの最小方法。

Algorithm Attempt to fit the data set into a small sub-report size, selected length of 8 octets

小サブレポートサイズに設定されたデータを適合させるアルゴリズム試み、8つのオクテットの選択された長さ

Can we split the range (0 - 39) into 16 4-bit values? The largest bucket value would, in this case, be the bucket for X values 5 - 7.5, the sum of which is 5970. An MF value of 9 will generate a multiplicative factor of 2^9, or 512 -- which, multiplied by the max bucket value, produces a maximum real value of 7680.

16の4ビットの値に - (39 0)私たちは、範囲を分割することはできますか?最大バケット値は、この場合には、X値5バケットであろう - を乗じ、 - 7.5、和は9の5970.アンMF値は2 ^ 9、または512の乗算係数を生成しています最大バケット値は、7680の最大真の値を生成します。

The packet fields will contain the values:

パケットのフィールドに値が含まれます。

Header distribution Block Distribution Type: 1 Number of Data Buckets: 16 Multiplicative Factor: 9 Packet Length field: 5 (5 * 4 => 20 bytes) Minimum Data Value: 0 Maximum Data Value: 39 Data Bucket values: (each value is 16-bits)

ヘッダ分配ブロック分布型:データバケットの1数:16乗算係数:9パケット長フィールド:5(5 * 4 => 20バイト)最小データ値:0最大データ値:39のデータバケット値(各値は16であります-bits)

Results, 4-bit buckets:

結果、4ビットのバケツ:

X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL Y - 4 | 9 | 12 | 2

X - 0から2.5 | 2.5から5 | 5から7.5 | 7.5から10(Y - 1803 | 4403 | 5970 | 853)は、実際のY - 4 | 9 | 12 | 2

X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL Y - 0 | 0 | 0 | 0

X - 10から12.5 | 12.5から15 | 15から17.5 | 20(Y - - 110 | 140 | 89.5 | 12.5)17.5 ACTUAL Y - 0 | 0 | 0 | 0

X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL Y - 1 | 8 | 1 | 1

X - 20から22.5 | 22.5から25 | 25から27.5 | 30(Y - - 447 | 3897 | 609.5 | 506.5)27.5 CURRENT Y - 1 | 8 | 1 | 1

X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL Y - 1 | 0 | 0 | 0

X - 30から32.5 | 32.5から35 | 35から37.5 | 40(Y - - 388.5 | 221.5 | 159.5 | 85.5)37.5現在のy - 1 | 0 | 0 | 0

Example: 2nd Method

例:第二の方法

Description This demonstrates the most accurate method for representing the data set. This method doesn't attempt to optimise any values.

説明このデータ・セットを表現するための最も正確な方法を示しています。この方法は、任意の値を最適化しようとしません。

Algorithm Identify the highest value and select buckets large enough to convey the exact values, i.e., no multiplicative factor.

アルゴリズムは、最高値と正確な値を伝達するのに十分な大きさを選択バケット、即ち、無乗法因子を特定します。

The highest value is 3120. This requires 12 bits (closest 2 bit boundary) to represent, therefore it will use 60 bytes to represent the entire distribution. This is within the max packet size; therefore, all data will fit within one sub-report block. The multiplicative value will be 1.

最高値は、従って、これは、それが全体の分布を表すために60バイトを使用する、12ビット(最も近い2ビット境界)を表すために必要と3120です。これは、マックスパケットサイズ以内です。そのため、すべてのデータが一つのサブレポートブロックに収まります。乗法値は1になります。

The packet fields will contain the values:

パケットのフィールドに値が含まれます。

Header Distribution Block Distribution Type: 1 Number of Data Buckets: 40 Multiplicative Factor: 0 Packet Length field: 18 (18 * 4 => 72 bytes) Minimum Loss Value: 0 Maximum Loss Value: 39

ヘッダ分配ブロック分布型:データバケットの1数:40乗算係数:0パケット長フィールド:18(18 * 4 => 72バイト)の最小損失値:0最大損失値:39

Bucket values are the same as the initial data set.

バケット値は、初期データセットと同じです。

Result Selecting one of the three methods outlined above might be done by a congestion parameter or by user preference. The overhead associated with processing the packets is likely to differ very little between the techniques. The savings in bandwidth are apparent, however, using 20, 52, and 72 octets respectively. These values would vary more widely for a larger data set with less correlation between results.

上記で概説した3つの方法のいずれかを選択する結果が混雑パラメータによって、ユーザの好みによって行うことがあります。パケットの処理に伴うオーバーヘッドは、技術の間に非常に若干異なる可能性があります。帯域幅の節約は、それぞれ20、52、及び72オクテットを使用して、しかし、明らかです。これらの値は、結果の間に以下の相関で設定大きなデータのために広く変化するであろう。

Acknowledgements

謝辞

The authors would like to thank Magnus Westerlund, Dave Oran, Tom Taylor, and Colin Perkins for detailed reviews and valuable comments.

著者は、詳細なレビューと貴重なコメントのためにマグヌスウェスター、デイブ・オラン、トム・テイラー、およびコリンパーキンスに感謝したいと思います。

Authors' Addresses

著者のアドレス

Joerg Ott Aalto University School of Science and Technology Department of Communications and Networking PO Box 13000 FIN-00076 Aalto

科学コミュニケーションの技術部門とネットワーク私書箱13000 FIN-00076アアルトのイェルクオットアアルト大学

EMail: jo@acm.org

メールアドレス:jo@acm.org

Julian Chesterfield University of Cambridge Computer Laboratory, 15 JJ Thompson Avenue Cambridge CB3 0FD UK

ケンブリッジ大学コンピュータ研究所のジュリアン・チェスター大学、15 JJトムソンアベニューケンブリッジCB3 0FD英国

EMail: julianchesterfield@cantab.net

メールアドレス:julianchesterfield@cantab.net

Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd. Santa Clara, CA, USA 95054-1537

イブ学生はインテル・リサーチ/ CTL MS RNB6-61 2200ミッション・カレッジブルバードサンタクララ、CA、USA 95054-1537

EMail: eve_schooler@acm.org

メールアドレス:eve_schooler@acm.org