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
                                                           February 2010
               RTP Control Protocol (RTCP) Extensions for
         Single-Source Multicast Sessions with Unicast Feedback



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.


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


Copyright Notice


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

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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ドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

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


Table of Contents


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

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

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

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

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

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

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

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


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

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

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


a) SSM groups with a single sender.


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.


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

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

c) ASM with a single sender.


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.


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


2. Conventions and Acronyms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [13].

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

The following acronyms are used throughout this document:


ASM Any Source Multicast SSM Source-Specific Multicast


3. Definitions

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.


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).


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

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

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

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

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

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

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


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


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

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

4. Basic Operation

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.


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.


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

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

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


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


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.


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.


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

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


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 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 receivers know the addresses of their respectively responsible Feedback Targets; and


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


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.


Future specifications may be defined to address these aspects.


         +--------+       +-----+          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


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

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

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


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.


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.


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.


5. Packet Types

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


   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:


   Type       Description                    Payload number
   RSI        Receiver Summary Information   209

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


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

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

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

6. Simple Feedback Model
6.1. Packet Formats
6.1. パケットフォーマット

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


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

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


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

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

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


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.


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


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.


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

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

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

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

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

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

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


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.


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


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

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


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

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

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


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.


7. Distribution Source Feedback Summary Model

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.


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.


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.


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.


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


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

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

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


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

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


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

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


   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:


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.


SSRC: 32 bits The SSRC of the Distribution Source.


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


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

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

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

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


    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.


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


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

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

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

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


    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.

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

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

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

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

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

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


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).


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

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

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

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

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


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


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

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


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


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

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

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


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

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


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.


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

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


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.


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.


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

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

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

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

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

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

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


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.


    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:


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

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

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

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

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

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

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

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

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

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


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.


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

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


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |     SRBT=8    |    Length     |           Reserved            |
   |                                                               |
   :                         Collision SSRC                        :
   |                                                               |

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

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

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


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.


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

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

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

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

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


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

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


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |    SRBT=10    |    Length     |           Reserved            |
   |      MFL      |                    HCNL                       |
   |                    Median inter-arrival jitter                |

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

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

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

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

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

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

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


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.


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

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


    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.


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


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

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

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

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

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

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

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

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

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

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


    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.


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


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

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


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).


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).


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.


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

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

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


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.


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.


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

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

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

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


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


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

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

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


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

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

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

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


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


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


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


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.


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

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

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

        t0/     \   t1        t2        t3        t4        t5
          \____ ____/         :         :         :         :
          :    V    :         :         :         :         :
          :T_summary:         :         :         :         :
          :=1.5 * Td:         :         :         :         :
          \______________ ______________/         :         :
                    :    V    :                   :         :
                    : 3 * T_summary               :         :
                    :         :                   :         :
                    \______________ ______________/         :
                              :    V                        :
                              : 3 * T_summary               :
                              :                             :
                              \______________ ______________/
                                          3 * T_summary

Figure 2: Overview of Summarization Reporting


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.


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

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


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.


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).


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


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.


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

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

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

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

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

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


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


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

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


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


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.


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

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


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

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

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


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

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

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


7.2.6. Collision Resolution
7.2.6. 衝突解決

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


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.


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


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

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


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.


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.


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.


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.


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

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


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

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

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

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

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

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

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


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.


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.


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).


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

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


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

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

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


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

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

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


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.


8. Mixer/Translator Issues

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.


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

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

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

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

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


9. Transmission Interval Calculation

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.


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

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

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

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

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

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


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

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


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.


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

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

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


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

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

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

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

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

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

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

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

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

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

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


10. SDP Extensions
10. SDP拡張機能

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

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

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

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


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).




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


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

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

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


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


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


term: The Distribution Source will terminate the RTCP packet.


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)).


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

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

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

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

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

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

rsi-rule = processing ":" rtcp-type

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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





= SSRC:314159

In the above example, the Media Sender is identified to use the SSRC identifier 314159 and the CNAME

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

11. Security Considerations

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

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

11.1. Assumptions
11.1. 仮定

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

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

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


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.


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

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


a) Denial of Service (DoS)


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.


b) Packet Forgery


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


c) Session Replay


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


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.


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

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


a) Source-to-Receiver Communication

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

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

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

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

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

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


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.


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


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

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

b) Receiver-to-Distribution-Source Communication


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.


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.


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.


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.


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.


c) Receiver-to-Feedback-Target Communication


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

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

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


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.


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

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


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

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

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

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

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


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.


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.


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.


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.


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

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


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.


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


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

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


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

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

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

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

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

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

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

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


11.6.2. Suitable Security Solutions for RTP Sessions with Unicast Feedback

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

12. Backwards Compatibility

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.


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

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


Contact: Joerg Ott mail: tel: +358-9-470-22460

連絡先:イェルクオットメール 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:


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


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.


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


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


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


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


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


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


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


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


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.


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.


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

14. References
14.1. Normative References
14.1. 引用規格

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14.2. Informative References
14.2. 参考文献

[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

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

[15] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

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

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

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

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

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

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

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

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

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

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

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

[21] Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group,


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Appendix A. Examples for Sender-Side Configurations


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.


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


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.


         +--------+          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


A.2. One Media Sender


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.


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).


                        +-----+          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


A.3. Three Media Senders, Unicast Contribution

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

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


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.


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.


This setup is depicted in Figure 5.


                     +-----+          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


A.4. Three Media Senders, ASM Contribution Group

A.4。 3つのメディア送信者、ASMの貢献グループ

In this final example, the individual unicast contribution sessions between the Media Senders and the Distribution Source are replaced by a single ASM contribution group (i.e., a single common RTP session). Consequently, all Media Senders receive each other's traffic by means of IP-layer multicast and the Distribution Source no longer needs to perform explicit forwarding between the Media Senders. Of course, the Distribution Source still forwards feedback information received from the receivers (optionally as summaries) to the ASM contribution group.


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.


Figure 6 shows this scenario.


                    _                   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


Appendix B. Distribution Report Processing at the Receiver


B.1. Algorithm


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


xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)

xrange =最大分布値(MADV) - 最小分布値(MnDV)

First data point = MnDV,first ydata

最初のデータポイント= MnDV、第YDATA



For each ydata => xdata += (MnDV + (xrange / NDB))

各YDATA => XDATA + =(MnDV +(はxrange / NDB))のために

B.2. Pseudo-Code


Packet Variables -> factor,NDB,MnDVL,MaDV Code variables -> xrange, ydata[NDB],x,y

パケット変数 - >因子、NDB、MnDVL、MADVコード変数 - >はxrange、YDATA [NDB]、X、Y

xrange = MaDV - MnDV x = MnDV;

xrange = MADV - MnDV X = MnDV。

   for(i=0; i<NDB; i++) {
        y = (ydata[i] * factor);
        /*OUTPUT x and y values*/
        x += (xrange / NDB);

B.3. Application Uses and Scenarios


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.


A distribution of values is useful as input into any algorithm, multicast or otherwise, that could be optimized or tuned as a result of having access to the feedback values for all group members. Following is a list of example areas that might benefit from distribution information:


- The parameterization of a multicast Forward Error Correction (FEC) algorithm. Given an accurate estimate of the distribution of reported losses, a source or other distribution agent that does not have a global view would be able to tune the degree of redundancy built into the FEC stream. The distribution might help to identify whether the majority of the group is experiencing high levels of loss, or whether in fact the high loss reports are only from a small subset of the group. Similarly, this data might enable a receiver to make a more informed decision about whether it should leave a group that includes a very high percentage of the worst-case reporters.

- マルチキャストの前方誤り訂正(FEC)アルゴリズムのパラメータ。報告された損害、チューニングするFECストリームに組み込まれた冗長性の度合いができるであろうグローバルな視野を持っていないソースまたは他のディストリビューションエージェントの分布の正確な推定を考えます。分布は、グループの大半は損失の高いレベルを経験しているかどうかを識別するのに役立つかもしれない、または実際にいるかどうか、高損失のレポートは、グループの小さなサブセットからのみです。同様に、このデータは、それは最悪の場合の記者の非常に高い割合を含むグループを残すべきかどうかについてのより多くの情報に基づいた意思決定を行うために受信機を可能にするかもしれません。

- The organization of a multicast data stream into useful layers for layered coding schemes. The distribution of packet losses and delay would help to identify what percentage of members experience various loss and delay levels, and thus how the data stream bandwidth might be partitioned to suit the group conditions. This would require the same algorithm to be used by both senders and receivers in order to derive the same results.

- マルチキャストデータの編成は、階層符号化方式のための有用な層にストリーム。パケットロスや遅延の分布は、データストリームの帯域幅は、グループ条件に合うように分割される可能性がありますどのようにこのように様々な損失や遅延のレベルを経験するメンバーの何パーセント識別するのに役立つ、となります。これは、同じ結果を導き出すためには送信側と受信側の両方が使用する同じアルゴリズムを必要とします。

- The establishment of a suitable feedback threshold. An application might be interested to generate feedback values when above (or below) a particular threshold. However, determining an appropriate threshold may be difficult when the range and distribution of feedback values is not known a priori. In a very large group, knowing the distribution of feedback values would allow a reasonable threshold value to be established, and in turn would have the potential to prevent message implosion if many group members share the same feedback value. A typical application might include a sensor network that gauges temperature or some other natural phenomenon. Another example is a network of mobile devices interested in tracking signal power to assist with hand-off to a different distribution device when power becomes too low.

- 適切なフィードバックしきい値の確立。アプリケーションが特定の閾値ときに上方(又は下方)フィードバック値を生成するために興味があるかもしれません。フィードバック値の範囲と分布が先験的に知られていない場合しかし、適切な閾値を決定することは困難であり得ます。非常に大規模なグループでは、フィードバック値の分布を知ることは、合理的な閾値を確立することを可能にする、ひいては多くのグループメンバーが同じフィードバック値を共有する場合、メッセージ内破を防止する可能性を有するであろう。典型的なアプリケーションは、温度またはいくつかの他の自然現象ゲージセンサネットワークを含むかもしれません。別の例では、パワーが低くなりすぎたときに異なる分配装置にハンドオフを支援するために信号電力を追跡することに興味のモバイル機器のネットワークです。

- The tuning of Suppression algorithms. Having access to the distribution of round-trip times, bandwidth, and network loss would allow optimization of wake-up timers and proper adjustment of the Suppression interval bounds. In addition, biased wake-up functions could be created not only to favor the early response from more capable group members but also to smooth out responses from subsequent respondents and to avoid bursty response traffic.

- 抑制アルゴリズムのチューニング。往復時間、帯域幅、およびネットワークの損失の分布へのアクセスを持つことは、ウェイクアップタイマーと抑制間隔境界の適切な調整の最適化が可能になります。また、偏ったウェイクアップ機能は、より有能なグループメンバーからの初期応答を支持するだけでなく、作成することができただけでなく、その後の回答者からの回答を滑らかにし、バースト性の応答トラフィックを避けるために。

- Leader election among a group of processes based on the maximum or minimum of some attribute value. Knowledge of the distribution of values would allow a group of processes to select a leader process or processes to act on behalf of the group. Leader election can promote scalability when group sizes become extremely large.

- いくつかの属性値の最大値または最小値に基づいてプロセスのグループの中でリーダー選挙。値の分布を知ることは、プロセスのグループは、グループを代表して行動するリーダー・プロセスまたはプロセスを選択することができるようになります。グループのサイズが非常に大きくなったときにリーダー選挙は、拡張性を促進することができます。

B.4. Distribution Sub-Report Creation at the Source


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.


1) The first method attempts to represent the data in as few bytes as possible.


2) The second method conveys all values without providing any savings in bandwidth.


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.


The distribution type field of this packet would be value 1 since it represents loss data.


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


Can we split the range (0 - 39) into 16 4-bit values? The largest bucket value would, in this case, be the bucket for X values 5 - 7.5, the sum of which is 5970. An MF value of 9 will generate a multiplicative factor of 2^9, or 512 -- which, multiplied by the max bucket value, produces a maximum real value of 7680.

16の4ビットの値に - (39 0)私たちは、範囲を分割することはできますか?最大バケット値は、この場合には、X値5バケットであろう - を乗じ、 - 7.5、和は9の5970.アンMF値は2 ^ 9、または512の乗算係数を生成しています最大バケット値は、7680の最大真の値を生成します。

The packet fields will contain the values:


Header distribution Block Distribution Type: 1 Number of Data Buckets: 16 Multiplicative Factor: 9 Packet Length field: 5 (5 * 4 => 20 bytes) Minimum Data Value: 0 Maximum Data Value: 39 Data Bucket values: (each value is 16-bits)

ヘッダ分配ブロック分布型:データバケットの1数:16乗算係数:9パケット長フィールド:5(5 * 4 => 20バイト)最小データ値:0最大データ値:39のデータバケット値(各値は16であります-bits)

Results, 4-bit buckets:


X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL Y - 4 | 9 | 12 | 2

X - 0から2.5 | 2.5から5 | 5から7.5 | 7.5から10(Y - 1803 | 4403 | 5970 | 853)は、実際のY - 4 | 9 | 12 | 2

X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL Y - 0 | 0 | 0 | 0

X - 10から12.5 | 12.5から15 | 15から17.5 | 20(Y - - 110 | 140 | 89.5 | 12.5)17.5 ACTUAL Y - 0 | 0 | 0 | 0

X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL Y - 1 | 8 | 1 | 1

X - 20から22.5 | 22.5から25 | 25から27.5 | 30(Y - - 447 | 3897 | 609.5 | 506.5)27.5 CURRENT Y - 1 | 8 | 1 | 1

X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL Y - 1 | 0 | 0 | 0

X - 30から32.5 | 32.5から35 | 35から37.5 | 40(Y - - 388.5 | 221.5 | 159.5 | 85.5)37.5現在のy - 1 | 0 | 0 | 0

Example: 2nd Method


Description This demonstrates the most accurate method for representing the data set. This method doesn't attempt to optimise any values.


Algorithm Identify the highest value and select buckets large enough to convey the exact values, i.e., no multiplicative factor.


The highest value is 3120. This requires 12 bits (closest 2 bit boundary) to represent, therefore it will use 60 bytes to represent the entire distribution. This is within the max packet size; therefore, all data will fit within one sub-report block. The multiplicative value will be 1.


The packet fields will contain the values:


Header Distribution Block Distribution Type: 1 Number of Data Buckets: 40 Multiplicative Factor: 0 Packet Length field: 18 (18 * 4 => 72 bytes) Minimum Loss Value: 0 Maximum Loss Value: 39

ヘッダ分配ブロック分布型:データバケットの1数:40乗算係数:0パケット長フィールド:18(18 * 4 => 72バイト)の最小損失値:0最大損失値:39

Bucket values are the same as the initial data set.


Result Selecting one of the three methods outlined above might be done by a congestion parameter or by user preference. The overhead associated with processing the packets is likely to differ very little between the techniques. The savings in bandwidth are apparent, however, using 20, 52, and 72 octets respectively. These values would vary more widely for a larger data set with less correlation between results.




The authors would like to thank Magnus Westerlund, Dave Oran, Tom Taylor, and Colin Perkins for detailed reviews and valuable comments.


Authors' Addresses


Joerg Ott Aalto University School of Science and Technology Department of Communications and Networking PO Box 13000 FIN-00076 Aalto

科学コミュニケーションの技術部門とネットワーク私書箱13000 FIN-00076アアルトのイェルクオットアアルト大学



Julian Chesterfield University of Cambridge Computer Laboratory, 15 JJ Thompson Avenue Cambridge CB3 0FD UK

ケンブリッジ大学コンピュータ研究所のジュリアン・チェスター大学、15 JJトムソンアベニューケンブリッジCB3 0FD英国



Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd. Santa Clara, CA, USA 95054-1537

イブ学生はインテル・リサーチ/ CTL MS RNB6-61 2200ミッション・カレッジブルバードサンタクララ、CA、USA 95054-1537