[要約] RFC 5760は、単一ソースマルチキャストセッションにおけるRTCP拡張とユニキャストフィードバックに関する規格です。このRFCの目的は、マルチキャストセッションでのフィードバックメカニズムを提供し、ユニキャストフィードバックを使用してセッションの品質を向上させることです。
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
ユニキャストフィードバックを使用したシングルソースマルチキャストセッション用のRTPコントロールプロトコル（RTCP）拡張機能
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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は、ユニキャストモードまたはマルチキャストモードのいずれかで動作するように設計されています。マルチキャストモードでは、ソースマルチキャスト（ASM）グループモデルを想定しています。ここでは、224.0.0.0から239.255.255.255の範囲の共通グループアドレスを介して、1対多で多数のコミュニケーションがサポートされます。インターネット全体のマルチキャスト通信を有効にするために、ドメイン内ルーティングプロトコル（単一の管理ドメイン内でのみ動作するもの、たとえば距離ベクトルマルチキャストルーティングプロトコル（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 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.
1対多くのマルチキャストトポロジはルーティングを簡素化し、特定のRTPアプリケーションの要件に近い近似である可能性がありますが、単方向通信は、グループ内の受信機が他のグループメンバーとRTCPフィードバック情報を共有することを不可能にします。このドキュメントでは、その問題の解決策を指定します。すべてのセッションメンバーに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) 1対多くの放送ネットワーク。
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.
ユニキャストフィードバックは、地上の低帯域幅リターンチャネルやブロードバンドケーブルリンクを備えた衛星ネットワークなど、1対多くの放送ネットワークにとっても有益です。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フィードバックメカニズムを補完することを目的としています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [13]に記載されているように解釈される。
The following acronyms are used throughout this document:
このドキュメント全体で次の頭字語が使用されています。
ASM Any Source Multicast SSM Source-Specific Multicast
ASM任意のソースマルチキャストSSMソース固有のマルチキャスト
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).
ASMマルチセンダーグループ、ユニキャストのみのクライアント、および/またはSSMシングルセンダーレシーバーグループで構成される異種ネットワークを翻訳者またはミキサーで接続して、シングルソースグループを作成できることに注意してください（詳細についてはセクション8を参照）。
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システムアーキテクチャには分布ソースが含まれているため、混乱を避けるために、このドキュメントではメディアソースが一般的にメディア送信者と呼ばれます。多くの場合、配布源と共同で配置された単一のメディア送信者がいる場合があります。ただし、配布源は1つだけですが、配布源を代表して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を使用し、レシーバーから配布源までの方向にユニキャストフィードバックチャネルを使用することにより達成されます。次のセクションで説明したように、配布源とメディア送信者の間のチャネルの性質は異なる場合があります。
(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.
（Unicast RTCP）フィードバックターゲット：フィードバックターゲットは、RTCPユニキャストフィードバックトラフィックに対処する論理関数です。フィードバックターゲットと分布源の関数は、同じエンティティに共同住宅または統合される場合があります。この場合、RTPチャネルのポートN上の分布ソースAとRTCPチャンネルのKで定義されたセッションの場合、ユニキャストRTCPフィードバックターゲットは、特に特に特に特に分布ソースAのIPアドレスAによって識別されます。セッションの説明に記載されています。アドレスの指定方法の詳細については、セクション10を参照してください。フィードバックターゲットは、分布ソースとは異なる1つ以上のエンティティで実装される場合があり、異なるRTPレシーバーは、たとえば集約目的で異なるフィードバックターゲットインスタンスを使用する場合があります。この場合、フィードバックターゲットインスタンスは、このドキュメントで指定されたRTCPメカニズムを使用して、RTP受信機から分布ソースに受信したフィードバックを伝達する必要があります。分離する場合、フィードバックターゲットインスタンスは、並行して、階層的、または鎖で並んでいる任意のトポロジー構造で編成される可能性があります。ただし、フィードバックターゲットインスタンスと分布ソースは、たとえば、構成を通じて、フィードバックターゲットインスタンス（S）によって収集されたRTCPフィードバックに基づいて、コヒーレントRTCP情報をRTP受信機に提供できる十分な情報を共有する必要があります。両方の関数が同じエンティティの一部であった場合、行われます。
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つのソースによって可変サイズのフィードバックパケットが作成される場合があります。要約されたレポートスキームは、1つのパケットに複数の要約レポートブロックを含めることにより、このモデルに基づいています。ただし、複数の受信機からのレポートの積み重ねは、単純なフィードバックモデルでは許可されていません（セクション6を参照）。
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 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.
前のセクションの定義で示されているように、1つ以上のメディア送信者がRTPパケットを配布源に送信します。分布ソースは、ソース固有のマルチキャスト配置を使用して、RTPパケットを受信機にリレーします。逆方向に、受信機はユニキャストを介してRTCPパケットをフィードバックターゲットの1つ以上のインスタンスに送信します。フィードバックターゲットは、元のRTCPレポート（単純なフィードバックモデル）またはこれらのレポートの要約（要約フィードバックモデル）を配布源に送信します。配布源は、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レポートまたは要約されたRTCPレポートの再分配は些細なことです。フィードバックターゲットが物理的および/または分布ソースとは異なる場合、各フィードバックターゲットは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に示します。単一のメディア送信者または複数のメディア送信者（メディア送信者I、1 <= i <= m）があり、その分布ソースがRTPおよびRTCPパケットを普及させます。最も一般的なケースであると予想される基本ケースは、分布ソースが特定のメディア送信者と共同で開催されることです。基本的な仮定は、通信がレシーバー（r（j）、1 <= j <= n）への分布ソースの方向にあるマルチキャスト（SSMまたはASM）であり、分布源への受信機の方向にユニキャストであることです。。
Communication between Media Sender(s) and the Distribution Source may be performed in numerous ways:
メディア送信者と配布源との間のコミュニケーションは、さまざまな方法で実行できます。
i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast.
i. ユニキャストのみ：メディア送信者は、ユニキャストを介して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）：メディア送信者と配布ソースは同じ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）：メディア送信者と分布ソースは、ソースが分布ソースであるSSMグループにある場合があります。メディア送信者からのRTPおよびRTCPパケットはユニキャストを介して配布源に送信され、配布ソースからの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.
このSSMグループは、配布源から受信機へのRTP/RTCP配信に使用されるSSMグループと同一である可能性がある場合、または別のものである可能性があることに注意してください。
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 分布ソースは、ユニキャスト輸送アドレス（ES）または（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.
ユニキャスト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.
2番目の方法である「配布ソースフィードバック概要モデル」は、フィードバックターゲットの支援を受けて、その後分布パケットに分布ソースでレシーバーレポートを統合することにより、帯域幅の節約を提供する要約レポートスキームです。すべてのレシーバーに。分布ソースフィードバック概要モデルは、セクション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つのレポート方法を区別するには、セクション10で新しいSDP識別子が作成および説明されています。レポート方法は、セッションの開始前に決定する必要があります。分布ソースは、セッション中にメソッドを変更してはなりません。
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スタックによって除外する必要があります。
The RTCP packet types defined in [1], [26], and [15] are:
[1]、[26]、および[15]で定義されているRTCPパケットタイプは次のとおりです。
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:
このドキュメントは、さらに1つの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と同様に、さまざまなレポートを単一のRTCPパケットに結合することができます。これは、PATH MTUを超えてはなりません。パケットは、生成されたトラフィックの量を拡大するために、グループサイズに反比例するレートで引き続き送信されます。
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パケットを送信する必要があります。[1]で概説されているように、BYEとAPPパケットを生成するためのルールも適用されます。
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 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.
配布源（ユニキャストフィードバックターゲット）は、RTCPポートに送信されたユニキャストRTCPデータをリッスンする必要があります。このポートで受信したすべての有効なユニキャストRTCPパケットは、分布ソースによってマルチキャストRTCPチャネルのグループに転送される必要があります。分布ソースは、グループへの再送信のために、異なる受信機から受信したブロックを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パケットをメディア送信者に転送する必要があります。複数のメディア送信者がおり、これらのメディア送信者が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で説明します。
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パケットを受信機または別のフィードバックターゲット（直接的または間接的に）から分布源に転送する必要があります。
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.
レシーバーは、RTPチャネルでデータを聞く必要があり、RTCPチャネルを制御する必要があります。各レシーバーは、使用中のプロファイルに従ってコントロール帯域幅R/Nのシェアを計算する必要があります。これにより、RTCP帯域幅の一部が受信機に割り当てられたRTCP帯域幅rの一部が、セッション内の一意の受信機SSRCの数と均等に分割されます。n。Rは、RTCP_BW * 0.75またはRTCP_BW * 0.5（[1]に従って送信者の比率に応じて）またはSDP属性[10]によって明示的に設定される場合があります。帯域幅許容値の計算の詳細については、セクション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送信者レポートを観察する場合、[1]の手順に従って独自の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. Even if such out-of-band information is available, a receiver MUST obey the above collision-resolution mechanisms.
メディアセッションで使用されているメディア送信者SSRC（S）についてレシーバーが利用可能な帯域外情報を持っている場合、同じSSRCを使用してはなりません。このような帯域外情報が利用可能であっても、受信者は上記の衝突解像度メカニズムに従わなければなりません。
Further mechanisms defined in [1] apply for resolving SSRC collisions between receivers.
[1]で定義されているさらなるメカニズムは、受信機間のSSRC衝突の解決に適用されます。
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.
メディア送信者ではない別のエンティティとのSSRC衝突を観察するメディア送信者は、受信者の場合、TDが決定的な計算レポート間隔である5 * 1.5 * TDにより、[1]に従って衝突解像度アクションを遅らせることがあります。紛争がまだ存在するかどうかを確認します。他のメディア送信者との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を積極的または不必要に変更してはなりません。
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.
配布ソースフィードバックサマリーモデルでは、配布源は、受信機によって生成されたすべての受信機レポートから受信した情報を要約し、情報を要約レポートに入れる必要があります。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レポートブロックを生成するすべてのRRSに追加する必要があります。
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レポートとメディア送信者のSDEパケットを転送する必要があります。配布源が実際にメディア送信者である場合、たとえそれが唯一のセッション送信者であっても、メディア送信者としての役割について独自の送信者レポート（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パケットの後にサブレポートブロックをスタックする場合があります。そうする場合、各サブレポートブロックはRSIパケットに対応する必要があり、レポート時間間隔を計算するために受信機が必要とする基本的な要約情報の強化を構成します。このため、追加のサブレポートブロックは必要ありませんが、推奨されます。RSIパケットとオプションの対応するサブレポートブロックを含む複合RTCPパケットは、受信者が発行するパケットの[1]で定義されているルールに従って形成する必要があります。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帯域幅サブレポートのいずれかを含める必要があります。
All numeric values comprising multiple (usually two or four) octets MUST be encoded in network byte order.
複数の（通常は2つまたは4つの）オクテットを含むすべての数値値は、ネットワークバイトの順序でエンコードする必要があります。
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ビットワードのRTCPパケットの長さは、ヘッダーとパディングを含む1つを引いたものです。
SSRC: 32 bits The SSRC of the Distribution Source.
SSRC：32分布ソースのSSRCを32ビットします。
Summarized SSRC: 32 bits The SSRC (of the Media Sender) of which this report contains a summary.
要約されたSSRC：32ビット（メディア送信者の）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ビットは、このレポートが送信されたときの壁掛け時間を示します。WallClock Time（絶対日付と時刻）は、1900年1月1日の0H UTCに比べて数秒であるネットワークタイムプロトコル（NTP）のタイムスタンプ形式を使用して表されます[1]。壁掛け時間はNTPに同期している可能性があります（ただし必要ありません）が、時間の進歩に一貫した動作を提供する必要があります（NTPと同様）。フル解像度のNTPタイムスタンプが使用されます。これは、最初の32ビットの整数部と最後の32ビットの分数部分を備えた64ビット、符号なしの固定点数です。この形式は、RTCP送信者レポートに似ています（[1]のセクション6.4.1）。タイムスタンプの値は、重複したパケットの検出、並べ替え、フィードバックレポートの時系列プロファイルを提供するために使用されます。
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.
長さ：32ビット語でサブレポートの長さを8ビットします。
SRBT-specific data: <length * 4 - 2> octets This field may contain type-specific information based upon the SRBT value.
SRBT固有のデータ：<長さ * 4-2>オクテットこのフィールドには、SRBT値に基づいてタイプ固有の情報が含まれている場合があります。
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、累積損失）の場合、柔軟な「データバケット」スタイルのレポートが使用されます。この形式は、レポートブロックのヘッドにあるガイドフィールドに従って解釈される可変サイズのバケットにデータセットを分割します。
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.
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.
分布バケット数（NDB）：12ビットデータの分布バケット数。各バケットのサイズは、式（（長さ * 4）-12） * 8 / NDBビット数を使用して計算できます。計算は、オクテット（長さ * 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〜15で、MF = 1、2、4 ... 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バイト）でサブレポートブロックの全長を指示し、受信機がバケットサイズを識別できるようにします。たとえば、MTUの制限がない場合、配布パケットのデータ部分は1008バイト（255 * 4-12）と同じ大きさであり、長さ2ビットの最大4032データバケツ、または長さ4ビットの2016データバケツを提供します。、など
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.
最小分布値（MIN）：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).
最大分布値（最大）：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]
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.
バケットベースのレポートについては、分布源とフィードバックターゲットが馬鹿げたエンティティである場合、バケツから報告する粒度に関するバンド外の契約が推奨されます。受信機へのレポートの種類。
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.
最小分布値フィールドの有効な結果は0〜254です。同様に、最大分布値フィールドの有効な結果は1〜255です。最小分布値は常に最大よりも低くなければなりません。
For examples on processing summarized loss report sub-blocks, see Appendix B.
要約された損失レポートのサブブロックの処理の例については、付録Bを参照してください。
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つのレポート間隔に対してジッター分布値を報告してはなりません。
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送信者タイムスタンプの記録を維持し、独自のシステムクロックから測定された現在の時間を維持することにより、往復時間を受信機の往復時間を計算できます。その結果、配布源は、対応するSRタイムスタンプを識別し、RRパケットの受信時に計算された時点で計算された独自の時差測定からレシーバーによって報告されている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.
分布ソースとフィードバックターゲット関数がisjointである場合、すべてのフィードバックターゲットがすべてのRTCPレポートをすぐに転送する場合（つまり、予備要約を実行しない）、すべてのフィードバックターゲットがRTTを決定することが可能であることに注意してください。少なくともRRパケット。
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.
最小分布値フィールドの有効な結果は0〜254です。同様に、最大分布値フィールドの有効な結果は1〜255です。最小分布値は常に最大よりも低くなければなりません。累積損失サブレポートブロックタイプ（SRBT）は7です。
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
0：IPv4アドレス1：IPv6アドレス2：DNS名
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.
長さ：32ビット単語でサブレポートブロックの長さを8ビットします。IPv4アドレスの場合、これは2でなければなりません（つまり、合計長= 4 4 = 2 * 4オクテット）。IPv6アドレスの場合、これは5でなければなりません。DNS名の場合、長さフィールドは、文字列と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ビット境界にnullバイトでパッドで埋められた任意の長さの文字列です。文字列には、アプリケーション（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、1、または2の特定のSRBTがあります）は、パケット内で1回以上発生してはなりません。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を参照してください。
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、CNAME]に基づいて非統一SSRCが発見された場合、このブロックで衝突が報告され、影響を受けるノードはそれぞれの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ビットこのフィールドには、グループ内で複製されたSSRCのリストが含まれています。通常、これは同じSSRCの検出時にホストによって処理されます。ただし、分布ソースフィードバックサマリーモデルを使用したSSMセッションの受信機は、セッションのグローバルビューがなくなっているため、衝突アルゴリズムは分布ソースによって処理されます。衝突するSSRCはパケットにリストされています。各衝突SSRCは、衝突検出ごとに1回のみ報告されます。MTUに適合するよりも多くの衝突SSRCを報告する必要がある場合、レポートはラウンドロビンファッションで行われ、すべての衝突SSRCが報告の第2ラウンドが開始される前に1回報告されます。パケットを受け取ったとき、受信機は衝突を検出し、衝突がそれらに関係する場合は別の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レシーバーSSRCを介した分布ソースとフィードバックターゲット関数が分離および衝突レポートが提供される場合、フィードバックターゲットは、少なくともRRおよびSDESパケットを含むRTP受信機から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レシーバーがセッションでメディア送信者として機能しないシステム設定（さまざまな種類のテレビ放送の場合）は、RTPレシーバーのSSRC衝突検出を省略することができます。RTPレシーバーがメディア送信者になる可能性のあるシステム設定（たとえば、会話アプリケーション）では、RTP受信機にSSRC衝突検出を提供する必要があります。
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レシーバーの衝突解像度は、メディア送信者になることができるレシーバーにとって特に関連性があります。特定のRTPセッションで送信者として機能しない構成または実装の選択により、受信者からRTCPフィードバックメッセージを受信および処理しているエンティティが廃止できる限り、必ずしも衝突に注意する必要はありません。さまざまな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レシーバーは、メディア送信者のSSRCの変化に対処できる必要があることに注意してください（RTPレシーバーがしなければならないように）。可能であれば、メディアストリームを継続的にレンダリングする準備をしてください。
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.
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.
最も累積累積パケットの失われたパケット（HCNL）：24ビット最高の「累積累積パケット数が失われました」という値は、受信機の最新のRTCP RRパケットから値を失いました。すべての '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.
中央値到着ジッター：32ビットの中央値の「到着間ジッター」値は、受信機セットからの最新のRTCP RRパケットの値です。すべての '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.
分布源とフィードバックターゲット関数がis辱された場合、すべてのフィードバックターゲットがすべてのRTCPレポートをすぐに順番に転送し、に含める場合、分布ソースが到着間ジッターの中央値を決定することが可能であることに注意してください。少なくともRRパケット。
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.
Receivers (R): 1 bit The contained bandwidth value applies to each RTP receiver.
受信機（R）：1ビット含まれる帯域幅値は、各RTPレシーバーに適用されます。
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帯域幅：32ビットSビットが1に設定されている場合、このフィールドは、個々のメディア送信者に割り当てられた最大帯域幅を示します。これはまた、送信者に予想されるRTCPレポートの頻度について受信者に通知します。これは、2番目と3番目のバイトの間にバイナリポイントがある固定点値です。値は、1秒あたりのキロビットのレシーバーごとの帯域幅割り当てを表し、値は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番目のバイトの間にバイナリポイントがある固定点値です。この値は、1秒あたりのキロビットのレシーバーごとの帯域幅割り当てを表し、値は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です。
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です。
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 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.
配布源は、[1]で定義されているように、受信機からRTCPパケットを受け入れ、レシーバーごとの情報を解釈および保存する責任があります。誤った情報が深刻な意味を持つ可能性があるため、これらの機能を提供することの重要性は、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レポートは、RRレポートから開始し、その後に関連するSDESフィールドが続く必要があります。次に、分布ソースは、要約固有のデータを含むRSIヘッダーとサブレポートを追加する必要があります。さらに、グループと平均パケットサイズのサブレポートまたはレシーバー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の衝突を特定するために、分布ソースは、クライアントを区別するために、グループごとの少なくとも1つのレポート間隔内で各SSRCと対応するCNAMEの記録を維持する責任があります。精度を高めるために、複数の間隔の更新リストを維持することをお勧めします。CNAMEが正しく生成される場合、SSRCとCNAMEの組み合わせは一意でなければならないため、このメカニズムは衝突の可能性を防ぐ必要があります。衝突が検出されない場合、分布源はグループサイズの不正確な印象を与えます。統計的確率は非常に低いため、衝突が発生し、検出不能になるため、これは大きな懸念事項ではありません。特に、クライアントは同じSSRCをランダムに選択し、同じユーザー名IPアドレスを持っている必要があります（たとえば、NATルーターの背後にあるプライベートアドレススペースを使用）。
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）、バケットの数、およびMINと最大値に基づくデータの精度との間にはトレードオフがあります。分布の特定の領域に焦点を合わせるために、分布ソースは最小値と最大値を調整し、バケツの数を増やし、場合によってはバケツの数を減らしてより正確な値を提供できます。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）、レシーバーごとの状態を維持する必要があります。新しい値がレシーバーによって報告されている場合、既存の値は新しい値に置き換える必要があります。レシーバーがタイミング（[1]のセクション6.3.5に従って）になっている場合（[1]のセクション6.3.7に従って）、レシーバーがタイミングを出した場合（エントリ全体とともに）削除する必要があります。
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バイトデータ部分）を超える場合、追加情報が追加される場合があります（ただし、合計でPATH 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.
すべての積み重ねられたサブレポートは、内部的に一貫している必要があります。つまり、同じセッションデータから生成されます。したがって、分布の重複が許可されているため、値の変動はデータセットの粒度の結果としてのみ発生する必要があり、値が異なる場合にはより正確なバケットサイズが優先されます。非visible値は、最も近いバケット値まで上下する必要があり、データの数は常に偶数の数でなければなりません。一貫性を維持するために、追加のゼロバケット値を備えたパディングが必要です。
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と、最後の3つのレポート間隔の要約を計算するのに十分な変数セットを保持します。これは、受信者ごとの状態を保持すること（つまり、それぞれの受信機によって報告された最後の値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.
ここには、現在のグループの状況を反映するために、概要の値が含まれています。最後の3つのレポート間隔を記録することにより、分布ソースには、個々のRTCP受信者レポートパケット損失を許可しながら、すべてのメンバーからのレポートを組み込みます。また、これらの値を収集するプロセスは、値のリセットを回避し、収集されたわずかな値に基づいてRSIレポートを送信する必要があることも目的としています。データが3回未満のレポート間隔で利用可能である場合（最初の2つのレポートの場合と同様）、利用可能な値のみが考慮されます。
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は、T_Summary = 1.5 * TDとして初期化する必要があります。ここで、TDは決定論的報告間隔であり、グループサイズまたは平均RTCPサイズ（ "AVG_RTCP_SIZE"）が変更された場合、タイマーの再考に従って更新する必要があります。この選択により、各レシーバーはインターバルごとに1回報告できるようになります。
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では、T0からT3から収集されたRTCPレポートがRSIレポートに含まれています。時間T4で、T1からT4のもの。等々。送信されたRSIサマリーレポートには、3回以上のレポート間隔からのRTCPレポートを含めてはなりません。たとえば、T5で送信されたレポートのレポートには、T2より前に分布ソースで受信したレポートを含めてはなりません。
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パケットを反映できます。また、BYE、RR、SDES（分布ソースが衝突解像度を実行するため）、グループサイズの推定、RR集約などの受信機に必要ではない他のRTCPパケットを転送しないことを決定する場合があります。配布源は、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).
集約はヌル操作である可能性があります。つまり、分布ソースは、1つ以上のRTCPパケットを受信機から化合物RTCPパケットに追加するだけです（少なくともRR、SDE、およびRSIを分布ソースから含む）。
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.
RTCP SSMメディアセッション（SDPで表現）の構成は、どのRTCPパケットに適用される分布ソースを適用する分布ソースを明示的に指定する必要があります。詳細については、セクション10.1を参照してください。
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.
メディア送信者が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の考慮事項が適用されます。
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.
配布源は、すべてのRTCPパケットをメディア送信者からRTPレシーバーに転送する必要があります。
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.
複数のメディア送信者がおり、これらのメディア送信者がASMを介して配布ソースと互いに通信しない場合、配布ソースは、各RTCPパケットを1つのメディア送信者から他のすべてのメディア送信者に転送する必要があります。
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.
1. 独自のRTCPレポートを受信機に向けてSSMグループに送信するために、分布ソースは、それらすべてに代わって概要を転送しているため、すべての受信機の共同シェアを使用する場合があります。したがって、配布源はレポートをすべてのTD/Rタイムユニットに送信する場合があり、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:
2. 独自のRTCPレポートをメディア送信者のみに送信する場合（つまり、メディア送信者が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.
a) 分布ソースが独自のRTCP RRパケットと一緒にRSIパケットを送信する場合、上記の＃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].
b) 配布源がRTCPパケットを他のすべての受信機からメディア送信者に転送する場合、他のすべての受信機と同じ帯域幅の共有を独自の送信で接着し、[1]に従って計算を使用する必要があります。
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に関するバンド外情報を使用する場合があります。それにもかかわらず、配布ソースは、送信者レポート（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.
配布源と受信機またはフィードバックターゲット（S）の間の衝突解像度（次のサブセクションで説明されている別のエンティティの場合）の場合、配布源とフィードバックターゲット（個別の場合）は通常の受信機と同様に動作します。
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.
フィードバックターゲットは、RTP受信機から配布源に到達するすべてのRTCPパケットを単に転送することができます。その場合、分布ソースは、上記のすべての機能を実行するために必要なすべての情報を利用できます。
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.
分布ソースとフィードバックターゲットの共同挙動は、セクション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を選択する必要があります。受信機の衝突解像度の考慮事項が適用されます。
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に対してチェックする必要があります。[1]の手順に従って、独自のSSRCと衝突するSSRCを使用してメディア送信者からRTPパケットを観察するレシーバーは、独自の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を使用すると、受信機はRTCP帯域幅rのシェアを計算できます。Rが与えられた場合、受信機の合計RTCP帯域幅共有（SSM RTPセッション）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（S）についてレシーバーが利用可能な帯域外情報を持っている場合、同じSSRCを使用してはなりません。受信者は、そのような帯域外の情報が時代遅れである可能性があることに注意する必要があります（つまり、送信者SSRCが変更された可能性があることは）、必要に応じて上記の衝突解像度手順に従う必要があります。
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情報を利用可能な場合は使用できますが、SSRCの潜在的な変更（Sender Report（SR）パケットからのみ学習できます）に注意する必要があります。
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]).
単純な転送モデルの場合とは異なり、メディア送信者は、分布ソースからRSIパケットを処理して、グループサイズと独自のRTCP帯域幅共有を決定できる必要があります。メディア送信者は、（転送）RTCP RRおよびSRパケット（[1]で義務付けられている）を聞くことから、グループサイズ（および対応するRTCP帯域幅の共有）を決定することもできなければなりません。
As long as they send RTP packets, they MUST also send RTCP SRs, as defined in [1].
RTPパケットを送信する限り、[1]で定義されているように、RTCP SRSも送信する必要があります。
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衝突を観察するメディア送信者は、5 * 1.5 * TDにより[1]に従って独自の衝突解像度アクションを遅らせる可能性があり、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を熱心にまたは不必要に変更してはなりません。
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.
セッションの流通ネットワーク間のミキサー翻訳者は、セッションのすべてのメンバーがすべての関連するトラフィックを受け取って、クライアントによる通常の操作を有効にすることを保証する必要があります。典型的な用途は、RTPクライアントの古い実装をSSMディストリビューションネットワークに接続することです。クライアントは、ソースにフィードバックをユニカストすることができません。この場合、ミキサー翻訳者はクライアントに代わってセッションに参加し、セッションからクライアントにトラフィックを送信して受信する必要があります。特定のハイブリッドシナリオには、要件が異なる場合があります。
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）のSDP説明[5]に接着し、示されているフィードバックメカニズムを使用する必要があります。受信者の実装者は、ミキサー翻訳者が複数のユニキャストソースまたはASMセッションからSSMレシーバーにトラフィックを転送している可能性があるため、セッションにミキサー翻訳者が存在する場合、複数のメディア送信者がアクティブになる可能性があることに注意する必要があります。。受信者は、通常の方法でUnicast RTCPレポートを割り当てられたフィードバックターゲット/配布ソースに転送する必要があります。この場合、仮定により、ミキサー翻訳者自体になります。ミキサー翻訳者が要約できる限り、複数のソース間のRSI要約レポートを調整しようとすることを複数のソース間で調整しようとすることを試みるため、これらの状況では簡単なパケット反射メカニズムを使用することをお勧めします。
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.
暗号化とセキュリティの問題については、セクション11で詳しく説明します。ミキサー翻訳者は、RTCPフィードバックをソースにユニキャストするためにクライアントと同じセキュリティポリシーに従うことができなければならないため、同じ認証と同じ認証を適用できる必要があります。/またはセッションに必要な暗号化ポリシー。ミキサー翻訳者が分布ソースとして作用しないソースへの透明なブリッジングとその後のユニキャストフィードバックは、ミキサー翻訳者が受信機が必要とするのと同じソース認証を実行できる場合にのみ許可されます。翻訳者は、クライアントに代わってユニキャストパケットを転送できますが、フィードバックアドレス情報のソースを認証せずに、マルチキャスト間フローをソースに向けて翻訳するべきではありません。
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]のアルゴリズムを使用します。
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パケットサイズフィールドまたは受信機の帯域幅フィールドのいずれかを使用する必要があります。
A receiver uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].
受信者は、これらの値を、[1]および[10]に従って、決定論的計算間隔の計算への入力として使用します。
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 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パケットの伝送間隔を計算する必要があり、RTP受信機としてカウントする必要があります。レシーバーレポートは、さらに考慮せずに到着すると転送されます。配布源は、すべてまたは選択された受信機が計算された帯域幅の制約に大まかに接着することを検証することを選択でき、そうでないレシーバーの余分なパケットをドロップすることを選択できます。すべての場合において、平均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 RSIパケットだけでなく、レシーバーレポートと関連するRTCPパケットに完全な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]に従って、決定論的計算間隔の計算への入力として使用します。
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 SRSおよびRRSを取得します。彼らは、[1]および[10]に従って、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 SRSを取得します。ASMのようにRTCP RRレポートを受け取ります（これらのパケットが分布ソースによって転送された場合）または要約を含むRSIパケット。前者の場合、彼らは[1]および[10]に従って、RTCPグループサイズの推定と決定論的伝送間隔の計算を実行する必要があります。後者の場合、送信者レポートとRSIパケットから取得した情報を組み合わせて、グループサイズと平均RTCPパケットサイズの完全なビューを作成し、[1]と決定論的伝送間隔の計算を実行する必要があります。[10]、これらの入力値に基づいています。
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.
フィードバックターゲットおよび/または分布源によって理解される形式と要約メカニズムのない特定のアプリパケットが使用される場合、そのようなパケットは最小限の遅延で転送することをお勧めします。それ以外の場合、レシーバーがタイムリーなフィードバックメッセージを送信する機能が影響を受ける可能性があります。
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]は、輸送アドレス、コーデック、およびその他の属性の観点からメディアセッションを説明する手段として使用されます。このドキュメントで指定されているように、Unicastを介してRTCPフィードバックが提供されることを示すには、セッションの説明に別のセッションパラメーターが必要です。同様に、送信者の要約モデルやフィードバック情報を送信するターゲットユニキャストアドレスなど、他のSSM RTCPフィードバックパラメーターを提供する必要があります。このセクションでは、このドキュメントで提案されたメカニズム（およびIANAに登録されている）で必要なSDPパラメーターを定義します。
A new session-level attribute MUST be used to indicate the use of unicast instead of multicast feedback: "rtcp-unicast".
新しいセッションレベルの属性を使用して、マルチキャストフィードバック「RTCP-Unicast」の代わりにユニキャストの使用を示す必要があります。
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-Unicast：リフレクション
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>])
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パケットは、配布源（またはフィードバックターゲット）で終了する必要があります。
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-Unicast」であり、新しい属性値の正式なSDP ABNF構文は次のとおりです。
att-value = "reflection" / "rsi" *(SP rsi-rule)
att-value = "reflection" / "rsi" *（sp rsi-rule）
rsi-rule = processing ":" rtcp-type
rsi-rule = processing "：" rtcp-type
processing = "aggr" / "forward" / "term" / token ;keep it extensible
rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)
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 = source-filter：inl"）のみを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 = source-filter：bint」属性が1つある必要があります。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.
IP4 192.0.2.1のSDP RTCP属性[7]、A = RTCP：<port>を使用して、代替フィードバックターゲットアドレスとポートを提供できます。この属性は、フィードバックターゲットの輸送アドレスのみを定義し、メディアストリーム受信のSSMグループ仕様には影響しません。
Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the same Distribution Source.
IPv4と同じ分布ソースのIPv6表現を示すために、2つの「ソースフィルター」属性が存在する場合があります。
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.
メディア送信者の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
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を使用するように識別されます。
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セッションに提供されるセキュリティのレベルを上げることに関する提案は推奨されますが、オプションです。最後のセクションでは、この仕様に準拠するのに適したセキュリティフレームワークの概要を説明します。
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アドレスのスプーフィングやトラフィックスヌーピングの影響を受けません。ただし、このような懸念はここでは議論されていません。以下のすべての議論で、セキュリティの弱点は輸送レベル以上から対処されます。
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は懸念事項です。コミュニケーションアーキテクチャの性質により、Unicastフィードバックチャネルを攻撃者の利点に使用することにより、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.
攻撃のもう1つの潜在的な領域は、パケット偽造です。特に、妥協がグループ全体の伝送特性に直接影響する可能性があるため、特定の影響力のあるパケットの完全性を保護することが不可欠です。
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攻撃を実行できる場合があります。
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の最悪の効果は、流通チャネル上の大量のトラフィックの送信であり、すべてのレシーバーに到達する可能性がありますが、1対1のベースです。その結果、この脅威は、現在のマルチキャスト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.
サービス拒否攻撃に関する追加の懸念は、偽のバイパケットの生成を通じて間接的に発生し、ソースが広告グループサイズを調整します。配布源は、グループサイズの変更を報告する前にセッションでメンバーをタイミングするための正しいルールに従う必要があります。これにより、本物の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、受信機の送信特性などの特性に関する貴重な情報を提供する可能性もあります。
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.
2番目のコンテキストは、グループから分布ソースへのリターントラフィックです。このトラフィックは、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.
重要な分布ソース制御情報の妥協の効果は、現在の状況で深刻に増幅することができます。ソースRTCPチャネルの整合性が損なわれ、個々のレシーバーによって妥協が検出されない場合、レシーバーの大規模なグループは、分布ソースへの分布DOS攻撃を無意識に生成する可能性があります。
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識別子を作成する可能性があります。このような攻撃は、グループサイズの誤った認識が作成される可能性があるため、全体的な制御チャネルデータレートを遅くする可能性があります。同様に、攻撃者による偽のさようならレポートの作成は、グループサイズの不安定性を引き起こしますが、データベースから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.
3番目のコンテキストは、グループからフィードバックターゲットへのリターントラフィックです。受信者からソースへのコンテキストと同じ脅威に苦しんでおり、違いは、レシーバーの大規模なグループがフィードバックターゲットに分散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.
DDOはRTCPセッション内で発生し、ユニキャストレシーバーがトランスミッション間隔計算（[1]、[10]）に付着するため、誤った場合のフィードバックターゲットに向けて誤った方向に向けられた帯域幅は、セッション帯域幅、つまり、セッション用に確立された制御トラフィック帯域幅。
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. DDOを経験しているエンドポイントまたは誤解された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パラメーターが含まれます。このような情報の外部通信に厳格な要件を配置することは、このドキュメントの範囲を超えています。ただし、セクション11.7では、適切に安全なSDP通信アプローチが概説されています。
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.
前のセクションで特定されたように、ソースの信頼性はプロトコルの基本的な要件です。ただし、この要件を達成するために受け入れられる信頼のモデルを明確にすることも重要です。この場合に適用される2つの基本的なモデルがあります。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.
b) RSAベースやPGP認証などの暗号システムを使用したPublic-Key認証モデルは、より高い処理オーバーヘッドを生成することを犠牲にして、より安全なソース認証方法を提供します。これは通常、リアルタイムのデータストリームには推奨されませんが、5秒の最小間隔で配布されるRTCPレポートの場合、これは実行可能なオプションかもしれません（処理オーバーヘッドは小さい、低いものには大きすぎる可能性があります - 電源のデバイスであるため、注意して検討する必要があります）。ただし、可能な限り、上記で特定された共有キーモデルよりも、公開キーソース認証の使用が望ましいです。
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.
プロトコル許容性の要件に関する懸念として、どちらのモデルも許容されますが、可能な限り安全なパブリックキーベースのオプションを適用することをお勧めします。
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で概説されている要件に適切に対処するように推奨される既存のセキュリティメカニズムを示します。これはガイドラインとしてのみ意図されており、仕様に準拠するのに適した他のソリューションがあることが認められています。
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、電子メール - セッションのSDPパラメーターの初期配布では、SAP認証フレームワークなどの安全なメカニズムを使用する必要があります。これにより、認証証明書をセッションの発表に添付できます。他の方法では、信頼できるソースからのHTTPまたは署名された電子メールコンテンツが含まれる場合があります。ただし、セッション情報と起動メディアストリームを配信するためのより一般的に使用される手法は、リアルタイムストリーミングプロトコル（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など）または輸送（輸送層セキュリティ（TLS）など）と組み合わせて標準のHTTP認証メカニズムを採用する場合があります。
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.
このプロファイルの目的のために、クライアントに提供される情報のアイデンティティと完全性を確立する適切に安全な認証メカニズムを使用することは許容されます。
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パケットの機密性を提供するだけでなく、整合性の妥協とリプレイ攻撃に対する保護を提供できます。Shared-Key Trustモデルを使用して、データストリームの認証を提供します。適切なキーディストリビューションメカニズムは、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-使用される可能性のあるより一般的なグループセキュリティプロファイルは、マルチキャストグループにIPSECメカニズムを適用するプロセスを定義する解釈のグループドメイン[23]です。これには、フレームワークとしてトンネルモードでカプセル化セキュリティペイロード（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-タイミングされた効率的なストリーム損失耐性認証（TESLA）[24]は、時間ベースのキー開示を使用したデータ認証に対するより柔軟なアプローチを提供するスキームです。認証は、ソースからの主要な開示間隔に基づいて、信頼性の短い期間を持つキーチェーンハッシュに基づいて、一方向の擬似ランダムキー関数を使用します。ソースとレシーバーの間のゆるい時間同期を必要とするキー開示の前に、暗号化されたパケットを確実に受信できるようにする限り、パケットの信頼性を証明できます。このスキームは、重要な開示遅延のために、パケット分布/復号化フェーズへの遅延を導入します。ただし、処理オーバーヘッドは他の標準的なパブリックキーメカニズムよりもはるかに低いため、小型またはエネルギー制限デバイスにより適している可能性があります。
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-Multimedia Internet Keying（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-Group Secure Association Key Management Protocol（GSAKMP）は、マルチキャストセキュアグループキーディストリビューションに好まれる一般的なソリューションです。これは、グループドメインの解釈（GDOI）[RFC3547]セッションのための推奨される重要な分布ソリューションです。
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.
適切なアプローチの1つは、ソースを決定できるRTCPパケットに明示的なコンテキスト情報を提供することです。このようなRTCPパケットはこの仕様で定義できますが、SRTP/SRTCPを使用してRTCPレポートの暗号化を使用する場合は役に立ちません。したがって、このドキュメントの拡張機能がそのような問題に直面する可能性のある唯一のケースではない可能性があるため、RTP全体に適用できるソリューションを見つけることが望ましいです。このようなメカニズムは、AVT WGでさらなる研究のためのものです。
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.
ソースへのユニキャストフィードバックの使用は、深刻な後方互換性の問題を提示しないでください。RTPデータストリームは、複数のストリームの場合にストリーム間同期を可能にし続けるメディア送信者からのRTCPパケットと同様に、影響を受けないようにする必要があります。セクション11で概説されているように、単純な反射または要約を通じてトラフィックを再分配する能力を持たないソースへのRTCPデータのユニキャスト送信は、実際にRTPの動作を破ることはありません。ユニキャストメカニズムを理解していないRTPに準拠した受信機の場合、ASM配信ネットワークが使用されている場合、RTCPトラフィックは依然としてグループに到達する可能性があります。無視する必要があります。ただし、通常、流通ネットワークはレシーバーがマルチキャストRTCPトラフィックを可能にしないことが予想されます。その場合、データは失われ、RTCP計算にはそれらの受信機が含まれません。非ユニカスト対応クライアントが関与する可能性のあるセッションは、常にすべてのクライアントが受け取ったパケットを理解できるように、常に単純なパケット反省メカニズムを使用することをお勧めします。
The following contact information shall be used for all registrations included here:
次の連絡先情報は、ここに含まれるすべての登録に使用するものとします。
Contact: Joerg Ott
mail: 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 LONG NAME：受信機の概要情報値：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アドレス長い名前：IPv4フィードバックターゲットアドレス値：0リファレンス：このドキュメント。
Name: IPv6 Address Long name: IPv6 Feedback Target Address Value: 1 Reference: This document.
名前：IPv6アドレス長い名前：IPv6フィードバックターゲットアドレス値：1リファレンス：このドキュメント。
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-Unicast」という名前の属性が次のように登録されています。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
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-UNICAST LONGフォーム：RTCPユニキャストフィードバックアドレスタイプ名：ATTフィールドタイプの属性：メディアレベルのみのcharsetのみ：目的なし：RFC 5760リファレンス：RFC 5760値：このドキュメントを参照してください。
[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.、Frederick、R。、およびV. Jacobson、「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.、McGrew、D.、Naslund、M.、Carrara、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] Quinn、B。およびR. Finlayson、「セッション説明プロトコル（SDP）ソースフィルター」、RFC 4570、2006年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5] Handley、M.、Jacobson、V。、およびC. Perkins、「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.
[7] Huitema、C。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[8] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.
[8] Meyer、D.、Rockell、R。、およびG. Shepherd、「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] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト、RFC 4604、2006年8月。
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[10] Casner、S。、「RTPコントロールプロトコル（RTCP）帯域幅のセッション説明プロトコル（SDP）帯域幅修飾子」、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] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、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] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、2006年7月。
[16] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.
[16] プサテリ、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] Fenner、B.、Handley、M.、Holbrook、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] Adams、A.、Nicholas、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] Bates、T.、Chandra、R.、Katz、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] Fenner、B.、ed。、およびD. Meyer、ed。、「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] Mark HandleyおよびMultimedia Research Group、http：//www-mice.cl.ac.ac.uk/multimedia/software/sdr/によって、ロンドンユニバーシティカレッジで開発されたセッションディレクトリRendez-vous（SDR）。
[22] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[22] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換導入」、RFC 4082、2005年6月。
[25] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[25] Schulzrinne、H.、Rao、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] Friedman、T.、Ed。、Caceres、R.、ed。、およびA. Clark、ed。、「RTP Control Protocol拡張レポート（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] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（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] Ott、J。およびE. Carrara、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）の拡張セキュアーRTPプロファイル」、RFC 5124、2008年2月。
[29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[29] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
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.
この付録では、貢献面、つまりメディア送信者と配布源の間の通信に焦点を当てたいくつかの一般的なセットアップについて説明しています。すべての場合において、このドキュメントの主要部分で定義されているように、分布側に同じセッションの説明が使用される場合があります。これは、この仕様により、配布源と受信機の間のメディアストリームのセットアップのみが定義されているためです。
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
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を介して実行できます。この場合、配布ソースは、メディアストリームとRTCP送信者が受信者にレポートするRTPパケットを転送し、レシーバーとそれ自体からのフィードバックをメディア送信者に伝える責任があります。
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).
このシナリオを図4に示します。メディア送信者と配布源の間の通信セットアップを静的に構成するか、SDPを使用してセッションパラメーターを伝えるためにいくつかのシグナル伝達プロトコルと併用できます。それは、メディア送信者とそれ自体（貢献セッション）との間のセッションをそれ自体と受信機の間の対応するセッション（ディストリビューションセッション）との間のセッションを関連付ける方法の分布ソースのローカル構成問題であることに注意してください。
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)
Figure 4: One Media Sender Separate from Distribution Source
図4：配布ソースとは別に1つのメディア送信者
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.
この場合、配布源の責任は、以前のケースに対するスーパーセットです。配布源は、各メディアの送信者から受信機へのメディアトラフィックを中継し、受信機からメディア送信者へのフィードバックを転送する（集約）する必要があります。さらに、分布ソースは、各メディアセンダーから他の2つに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つのメディア送信者、ユニキャスト貢献
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つのメディア送信者
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)
First data point = MnDV,first ydata
then
それから
For each ydata => xdata += (MnDV + (xrange / NDB))
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
for(i=0; i<NDB; i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}
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.
- 一部の属性値の最大または最小値に基づいたプロセスのグループ間のリーダー選挙。値の分布に関する知識により、プロセスのグループがグループに代わって行動するリーダープロセスまたはプロセスを選択できます。リーダーの選挙は、グループサイズが非常に大きくなると、スケーラビリティを促進できます。
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.
次の例は、損失サブレポートブロックの汎用形式を使用して損失データを伝える2つの異なる方法を示しています（セクション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) 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.
範囲（0-39）を16の4ビット値に分割できますか？この場合、最大のバケツ値はx値5-7.5のバケットであり、その合計は5970です。MF値9は、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)
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 - 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 - 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 - 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
Example: 2nd Method
例：2番目の方法
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.
最高値は3120です。これには、表すために12ビット（最も近い2ビット境界）が必要なため、分布全体を表すために60バイトを使用します。これは最大パケットサイズ内です。したがって、すべてのデータは1つのサブレポートブロック内に収まります。乗法値は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
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
Joerg Ott Aalto University School of Communications and Networking PO Box 13000 Fin-00076 Aalto
EMail: jo@acm.org
Julian Chesterfield University of Cambridge Computer Laboratory, 15 JJ Thompson Avenue Cambridge CB3 0FD UK
ジュリアンチェスターフィールドケンブリッジ大学コンピューター研究所、15 JJトンプソンアベニューケンブリッジCB3 0FD UK
EMail: julianchesterfield@cantab.net
Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd. Santa Clara, CA, USA 95054-1537
Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd.米国カリフォルニア州サンタクララ95054-1537
EMail: eve_schooler@acm.org