[要約] RFC 3550は、リアルタイムアプリケーションのための輸送プロトコルであるRTPに関する規格です。このRFCの目的は、リアルタイム通信におけるデータ転送の信頼性と効率性を向上させることです。
Network Working Group H. Schulzrinne
Request for Comments: 3550 Columbia University
Obsoletes: 1889 S. Casner
Category: Standards Track Packet Design
R. Frederick
Blue Coat Systems Inc.
V. Jacobson
Packet Design
July 2003
RTP: A Transport Protocol for Real-Time Applications
RTP：リアルタイムアプリケーション用のトランスポートプロトコル
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
この覚書では、リアルタイム転送プロトコルであるRTPについて説明します。 RTPは、マルチキャスト、ユニキャストネットワークサービスを介して、オーディオ、ビデオ、シミュレーションデータなどのリアルタイムデータを送信するアプリケーションに適したエンドツーエンドのネットワーク転送機能を提供します。 RTPはリソース予約に対応しておらず、リアルタイムサービスのサービス品質を保証していません。データトランスポートは、制御プロトコル（RTCP）によって拡張され、大規模なマルチキャストネットワークに拡張可能な方法でデータ配信の監視を可能にし、最小限の制御および識別機能を提供します。 RTPとRTCPは、基になるトランスポート層とネットワーク層から独立するように設計されています。このプロトコルは、RTPレベルのトランスレータとミキサーの使用をサポートしています。
Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.
このメモのテキストのほとんどは、廃止されたRFC 1889と同一です。ワイヤ上のパケット形式に変更はなく、プロトコルの使用方法を制御するルールとアルゴリズムに変更が加えられます。最大の変更は、RTCPパケットを送信するタイミングを計算するスケーラブルタイマーアルゴリズムの拡張で、多数の参加者が同時にセッションに参加する場合に、意図したレートを超える送信を最小限に抑えます。
Table of Contents
目次
1. Introduction ................................................ 4
1.1 Terminology ............................................ 5
2. RTP Use Scenarios ........................................... 5
2.1 Simple Multicast Audio Conference ...................... 6
2.2 Audio and Video Conference ............................. 7
2.3 Mixers and Translators ................................. 7
2.4 Layered Encodings ...................................... 8
3. Definitions ................................................. 8
4. Byte Order, Alignment, and Time Format ...................... 12
5. RTP Data Transfer Protocol .................................. 13
5.1 RTP Fixed Header Fields ................................ 13
5.2 Multiplexing RTP Sessions .............................. 16
5.3 Profile-Specific Modifications to the RTP Header ....... 18
5.3.1 RTP Header Extension ............................ 18
6. RTP Control Protocol -- RTCP ................................ 19
6.1 RTCP Packet Format ..................................... 21
6.2 RTCP Transmission Interval ............................. 24
6.2.1 Maintaining the Number of Session Members ....... 28
6.3 RTCP Packet Send and Receive Rules ..................... 28
6.3.1 Computing the RTCP Transmission Interval ........ 29
6.3.2 Initialization .................................. 30
6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
6.3.4 Receiving an RTCP BYE Packet .................... 31
6.3.5 Timing Out an SSRC .............................. 32
6.3.6 Expiration of Transmission Timer ................ 32
6.3.7 Transmitting a BYE Packet ....................... 33
6.3.8 Updating we_sent ................................ 34
6.3.9 Allocation of Source Description Bandwidth ...... 34
6.4 Sender and Receiver Reports ............................ 35
6.4.1 SR: Sender Report RTCP Packet ................... 36
6.4.2 RR: Receiver Report RTCP Packet ................. 42
6.4.3 Extending the Sender and Receiver Reports ....... 42
6.4.4 Analyzing Sender and Receiver Reports ........... 43
6.5 SDES: Source Description RTCP Packet ................... 45
6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
6.5.2 NAME: User Name SDES Item ....................... 48
6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
6.5.4 PHONE: Phone Number SDES Item ................... 49
6.5.5 LOC: Geographic User Location SDES Item ......... 49
6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
6.5.7 NOTE: Notice/Status SDES Item ................... 50
6.5.8 PRIV: Private Extensions SDES Item .............. 50
6.6 BYE: Goodbye RTCP Packet ............................... 51
6.7 APP: Application-Defined RTCP Packet ................... 52
7. RTP Translators and Mixers .................................. 53
7.1 General Description .................................... 53
7.2 RTCP Processing in Translators ......................... 55
7.3 RTCP Processing in Mixers .............................. 57
7.4 Cascaded Mixers ........................................ 58
8. SSRC Identifier Allocation and Use .......................... 59
8.1 Probability of Collision ............................... 59
8.2 Collision Resolution and Loop Detection ................ 60
8.3 Use with Layered Encodings ............................. 64
9. Security .................................................... 65
9.1 Confidentiality ........................................ 65
9.2 Authentication and Message Integrity ................... 67
10. Congestion Control .......................................... 67
11. RTP over Network and Transport Protocols .................... 68
12. Summary of Protocol Constants ............................... 69
12.1 RTCP Packet Types ...................................... 70
12.2 SDES Types ............................................. 70
13. RTP Profiles and Payload Format Specifications .............. 71
14. Security Considerations ..................................... 73
15. IANA Considerations ......................................... 73
16. Intellectual Property Rights Statement ...................... 74
17. Acknowledgments ............................................. 74
Appendix A. Algorithms ........................................ 75
Appendix A.1 RTP Data Header Validity Checks ................... 78
Appendix A.2 RTCP Header Validity Checks ....................... 82
Appendix A.3 Determining Number of Packets Expected and Lost ... 83
Appendix A.4 Generating RTCP SDES Packets ...................... 84
Appendix A.5 Parsing RTCP SDES Packets ......................... 85
Appendix A.6 Generating a Random 32-bit Identifier ............. 85
Appendix A.7 Computing the RTCP Transmission Interval .......... 87
Appendix A.8 Estimating the Interarrival Jitter ................ 94
Appendix B. Changes from RFC 1889 ............................. 95
References ...................................................... 100
Normative References ............................................ 100
Informative References .......................................... 100
Authors' Addresses .............................................. 103
Full Copyright Statement ........................................ 104
This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 11). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.
このメモは、リアルタイムトランスポートプロトコル（RTP）を指定します。RTPは、インタラクティブなオーディオやビデオなどのリアルタイムの特性を持つデータのエンドツーエンドの配信サービスを提供します。これらのサービスには、ペイロードタイプの識別、シーケンス番号付け、タイムスタンプ、および配信監視が含まれます。アプリケーションは通常、UDP上でRTPを実行して、その多重化およびチェックサムサービスを利用します。どちらのプロトコルも、トランスポートプロトコル機能の一部を提供します。ただし、RTPは他の適切な基盤となるネットワークまたはトランスポートプロトコルで使用できます（セクション11を参照）。 RTPは、基盤となるネットワークによって提供されている場合、マルチキャスト配信を使用して複数の宛先へのデータ転送をサポートします。
Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.
RTP自体は、タイムリーな配信を保証するメカニズムやその他のサービス品質保証を提供しませんが、下位層のサービスに依存していることに注意してください。配信を保証したり、順序どおりの配信を防止したりすることはなく、基盤となるネットワークが信頼性があり、パケットを順番に配信することも想定していません。 RTPに含まれるシーケンス番号を使用すると、受信者は送信者のパケットシーケンスを再構築できますが、シーケンス番号は、必ずしもビデオをデコードする場合など、パケットを順番にデコードする必要はなく、パケットの適切な場所を特定するためにも使用できます。
While RTP is primarily designed to satisfy the needs of multi-participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.
RTPは主に複数参加者のマルチメディア会議のニーズを満たすように設計されていますが、特定のアプリケーションに限定されません。連続データの保存、インタラクティブな分散シミュレーション、アクティブバッジ、制御および測定アプリケーションも、RTPを適用できる場合があります。
This document defines RTP, consisting of two closely-linked parts:
このドキュメントでは、密接に関連する2つの部分で構成されるRTPを定義しています。
o the real-time transport protocol (RTP), to carry data that has real-time properties.
o リアルタイム転送プロトコル（RTP）。リアルタイムプロパティを持つデータを伝送します。
o the RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application's control communication requirements. This functionality may be fully or partially subsumed by a separate session control protocol, which is beyond the scope of this document.
o RTP制御プロトコル（RTCP）。サービスの品質を監視し、進行中のセッションの参加者に関する情報を伝えます。 RTCPの後者の側面は、「緩やかに制御された」セッション、つまり明示的なメンバーシップ制御とセットアップがない場合に十分ですが、アプリケーションの制御通信要件のすべてをサポートすることを必ずしも意図していません。この機能は、このドキュメントの範囲を超える個別のセッション制御プロトコルによって完全にまたは部分的に包含される場合があります。
RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [10]. That is, RTP is intended to be malleable
RTPは、クラークとテネンハウスによって提案されたアプリケーションレベルのフレーミングと統合レイヤー処理の原則に従う新しいプロトコルのスタイルを表します[10]。つまり、RTPは柔軟であることを目的としています
to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.4.3.
特定のアプリケーションが必要とする情報を提供し、多くの場合、個別のレイヤーとして実装されるのではなく、アプリケーション処理に統合されます。 RTPは、意図的に完全ではないプロトコルフレームワークです。このドキュメントでは、RTPが適切であるすべてのアプリケーションで共通であると予想される機能を指定します。プロトコルをより一般的にしたり、解析を必要とするオプションメカニズムを追加したりすることで追加機能に対応できる従来のプロトコルとは異なり、RTPは、必要に応じてヘッダーを変更または追加して調整することを目的としています。セクション5.3および6.4.3に例を示します。
Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or more companion documents (see Section 13):
したがって、このドキュメントに加えて、特定のアプリケーションのRTPの完全な仕様には、1つ以上の関連ドキュメントが必要です（セクション13を参照）。
o a profile specification document, which defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). A profile may also define extensions or modifications to RTP that are specific to a particular class of applications. Typically an application will operate under only one profile. A profile for audio and video data may be found in the companion RFC 3551 [1].
o 一連のペイロードタイプコードとそれらのペイロードフォーマット（メディアエンコーディングなど）へのマッピングを定義するプロファイル仕様ドキュメント。プロファイルは、特定のクラスのアプリケーションに固有のRTPの拡張または変更を定義することもできます。通常、アプリケーションは1つのプロファイルでのみ動作します。オーディオおよびビデオデータのプロファイルは、関連するRFC 3551 [1]にあります。
o payload format specification documents, which define how a particular payload, such as an audio or video encoding, is to be carried in RTP.
o ペイロードまたはオーディオのエンコーディングなどの特定のペイロードがRTPでどのように伝送されるかを定義するペイロード形式仕様ドキュメント。
A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in [11].
リアルタイムサービスとその実装のためのアルゴリズム、およびRTP設計の決定のいくつかに関する背景的な議論については、[11]を参照してください。
1.1 Terminology
1.1用語
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 BCP 14, RFC 2119 [2] and indicate requirement levels for compliant RTP implementations.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [2]で説明されているように解釈され、準拠したRTP実装の要件レベルを示します。
The following sections describe some aspects of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to limit what RTP may be used for. In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion RFC 3551.
次のセクションでは、RTPの使用のいくつかの側面について説明します。例は、RTPの用途を制限するためではなく、RTPを使用するアプリケーションの基本的な操作を説明するために選択されました。これらの例では、RTPはIPおよびUDPの上で実行され、関連するRFC 3551で指定されたオーディオおよびビデオのプロファイルによって確立された規則に従います。
2.1 Simple Multicast Audio Conference
2.1シンプルなマルチキャスト音声会議
A working group of the IETF meets to discuss the latest protocol document, using the IP multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.
IETFのワーキンググループは、音声通信にインターネットのIPマルチキャストサービスを使用して、最新のプロトコルドキュメントについて話し合うために会合します。いくつかの割り当てメカニズムによって、ワーキンググループの議長はマルチキャストグループアドレスとポートのペアを取得します。 1つのポートはオーディオデータに使用され、もう1つのポートは制御（RTCP）パケットに使用されます。このアドレスとポート情報は、対象となる参加者に配布されます。プライバシーが必要な場合は、セクション9.1で指定されているようにデータと制御パケットを暗号化できます。その場合、暗号化キーも生成して配布する必要があります。これらの割り当ておよび配布メカニズムの正確な詳細は、RTPの範囲を超えています。
The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.
各会議参加者が使用する音声会議アプリケーションは、音声データを、たとえば20ミリ秒の小さなチャンクで送信します。オーディオデータの各チャンクの前には、RTPヘッダーが付いています。 RTPヘッダーとデータは、UDPパケットに含まれています。 RTPヘッダーは、各パケットに含まれているオーディオエンコーディングのタイプ（PCM、ADPCM、LPCなど）を示します。これにより、送信者は会議中にエンコーディングを変更して、たとえば、低帯域幅で接続されている新しい参加者に対応できます。ネットワークの輻輳の表示にリンクまたは対応します。
The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.
インターネットは、他のパケットネットワークと同様に、パケットを失ったり、並べ替えたり、さまざまな時間だけパケットを遅延させたりすることがあります。これらの障害に対処するために、RTPヘッダーにはタイミング情報とシーケンス番号が含まれており、レシーバーがソースによって生成されたタイミングを再構築できるため、この例では、オーディオのチャンクが20 msごとにスピーカーから連続して再生されます。このタイミングの再構築は、会議のRTPパケットのソースごとに個別に実行されます。シーケンス番号は、失われたパケットの数を推定するために受信側でも使用できます。
Since members of the working group join and leave during the conference, it is useful to know who is participating at any moment and how well they are receiving the audio data. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings. In addition to the user name, other identifying information may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet (Section 6.6) when it leaves the conference.
ワーキンググループのメンバーは会議中に参加したり退席したりするので、いつ誰が参加しているか、また彼らがオーディオデータをどれだけうまく受信しているかを知ることは役に立ちます。そのために、会議内のオーディオアプリケーションの各インスタンスは、受信レポートとRTCP（制御）ポート上のユーザーの名前を定期的にマルチキャストします。受信レポートは、現在のスピーカーがどれだけうまく受信されているかを示し、適応エンコーディングの制御に使用できます。ユーザー名に加えて、他の識別情報も制御帯域幅制限の対象として含めることができます。サイトは、会議を離れるときにRTCP BYEパケット（セクション6.6）を送信します。
2.2 Audio and Video Conference
2.2音声およびビデオ会議
If both audio and video media are used in a conference, they are transmitted as separate RTP sessions. That is, separate RTP and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated.
オーディオメディアとビデオメディアの両方が会議で使用される場合、それらは個別のRTPセッションとして送信されます。つまり、2つの異なるUDPポートペアまたはマルチキャストアドレス、あるいはその両方を使用して、メディアごとに個別のRTPおよびRTCPパケットが送信されます。オーディオセッションとビデオセッションの間にRTPレベルで直接結合することはありません。ただし、両方のセッションに参加しているユーザーは、セッションを関連付けることができるように、両方のRTCPパケットで同じ識別（正規）名を使用する必要があります。
One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. Further explanation is given in Section 5.2. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.
この分離の1つの動機は、会議の一部の参加者が選択した場合に1つのメディアのみを受信できるようにすることです。詳細については、セクション5.2を参照してください。分離にもかかわらず、両方のセッションのRTCPパケットで運ばれるタイミング情報を使用して、ソースのオーディオとビデオの同期再生を実現できます。
2.3 Mixers and Translators
2.3ミキサーとトランスレータ
So far, we have assumed that all sites want to receive media data in the same format. However, this may not always be appropriate. Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower-bandwidth, reduced-quality audio encoding, an RTP-level relay called a mixer may be placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower-bandwidth packet stream across the low-speed link. These packets might be unicast to a single recipient or multicast on a different address to multiple recipients. The RTP header includes a means for mixers to identify the sources that contributed to a mixed packet so that correct talker indication can be provided at the receivers.
これまでのところ、すべてのサイトが同じ形式のメディアデータを受信することを望んでいると想定しています。ただし、これが常に適切であるとは限りません。 1つのエリアの参加者が、高速ネットワークアクセスを楽しむ会議参加者の大部分に低速リンクを介して接続されている場合を考えます。低帯域幅で低品質のオーディオエンコーディングを使用するように全員を強制する代わりに、ミキサーと呼ばれるRTPレベルのリレーを低帯域幅領域の近くに配置することができます。このミキサーは、着信オーディオパケットを再同期して、送信者によって生成された一定の20 ms間隔を再構築し、これらの再構築されたオーディオストリームを単一のストリームに混合し、オーディオエンコーディングを低帯域幅のものに変換し、低帯域幅パケットストリームを低帯域幅に転送します。スピードリンク。これらのパケットは、単一の受信者へのユニキャスト、または複数の受信者への異なるアドレスでのマルチキャストの場合があります。 RTPヘッダーには、混合されたパケットの原因となったソースをミキサーが識別するための手段が含まれているため、レシーバーで正しいトーカー表示を提供できます。
Some of the intended participants in the audio conference may be connected with high bandwidth links but might not be directly reachable via IP multicast. For example, they might be behind an application-level firewall that will not let any IP packets pass. For these sites, mixing may not be necessary, in which case another type of RTP-level relay called a translator may be used. Two translators are installed, one on either side of the firewall, with the outside one funneling all multicast packets received through a secure connection to the translator inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group restricted to the site's internal network.
オーディオ会議の対象となる参加者の一部は、高帯域幅リンクに接続されている可能性がありますが、IPマルチキャストを介して直接到達できない場合があります。たとえば、IPパケットを通過させないアプリケーションレベルのファイアウォールの背後にある可能性があります。これらのサイトでは、ミキシングは必要ない場合があります。その場合、トランスレータと呼ばれる別のタイプのRTPレベルのリレーを使用できます。 2つのトランスレータがインストールされており、1つはファイアウォールの両側にあり、1つはファイアウォールの内側のトランスレータへの安全な接続を通じて受信されたすべてのマルチキャストパケットを外部に送ります。ファイアウォールの内側のトランスレータは、サイトの内部ネットワークに制限されたマルチキャストグループにマルチキャストパケットとして再度それらを送信します。
Mixers and translators may be designed for a variety of purposes. An example is a video mixer that scales the images of individual people in separate video streams and composites them into one video stream to simulate a group scene. Other examples of translation include the connection of a group of hosts speaking only IP/UDP to a group of hosts that understand only ST-II, or the packet-by-packet encoding translation of video streams from individual sources without resynchronization or mixing. Details of the operation of mixers and translators are given in Section 7.
ミキサとトランスレータは、さまざまな目的で設計できます。例は、個別のビデオストリームで個々の人々の画像をスケーリングし、それらを1つのビデオストリームに合成してグループシーンをシミュレートするビデオミキサーです。その他の変換の例には、IP / UDPのみを話すホストのグループと、ST-IIのみを理解するホストのグループへの接続、または再同期やミキシングなしの個々のソースからのビデオストリームのパケットごとのエンコード変換が含まれます。ミキサーとトランスレーターの操作の詳細は、セクション7に記載されています。
2.4 Layered Encodings
2.4階層化エンコーディング
Multimedia applications should be able to adjust the transmission rate to match the capacity of the receiver or to adapt to network congestion. Many implementations place the responsibility of rate-adaptivity at the source. This does not work well with multicast transmission because of the conflicting bandwidth requirements of heterogeneous receivers. The result is often a least-common denominator scenario, where the smallest pipe in the network mesh dictates the quality and fidelity of the overall live multimedia "broadcast".
マルチメディアアプリケーションは、受信機の容量に一致するように、またはネットワークの輻輳に適応するように伝送速度を調整できる必要があります。多くの実装では、レート適応性の責任はソースにあります。異種受信機の帯域幅要件が競合するため、これはマルチキャスト送信ではうまく機能しません。結果は、ネットワークメッシュ内の最小のパイプがライブマルチメディア「ブロードキャスト」全体の品質と忠実度を決定する、最も一般的でない分母シナリオです。
Instead, responsibility for rate-adaptation can be placed at the receivers by combining a layered encoding with a layered transmission system. In the context of RTP over IP multicast, the source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions each carried on its own multicast group. Receivers can then adapt to network heterogeneity and control their reception bandwidth by joining only the appropriate subset of the multicast groups.
代わりに、階層化されたエンコーディングを階層化された伝送システムと組み合わせることにより、レート適応の責任をレシーバーに課すことができます。 RTP over IPマルチキャストのコンテキストでは、ソースは、それぞれが独自のマルチキャストグループで実行される複数のRTPセッションに階層的に表された信号のプログレッシブレイヤーをストライプ化できます。レシーバーは、マルチキャストグループの適切なサブセットのみに参加することで、ネットワークの異質性に適応し、受信帯域幅を制御できます。
Details of the use of RTP with layered encodings are given in Sections 6.3.9, 8.3 and 11.
レイヤードエンコーディングでのRTPの使用の詳細については、セクション6.3.9、8.3、11を参照してください。
RTP payload: The data transported by RTP in a packet, for example audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.
RTPペイロード：オーディオサンプルや圧縮ビデオデータなど、RTPによってパケットで転送されるデータ。ペイロードの形式と解釈は、このドキュメントの範囲外です。
RTP packet: A data packet consisting of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically one packet of the underlying protocol contains a single RTP packet, but several RTP packets MAY be contained if permitted by the encapsulation method (see Section 11).
RTPパケット：固定RTPヘッダー、おそらく空のソースのリスト（以下を参照）、およびペイロードデータで構成されるデータパケット。一部の基本的なプロトコルでは、RTPパケットのカプセル化を定義する必要がある場合があります。通常、基礎となるプロトコルの1つのパケットには単一のRTPパケットが含まれますが、カプセル化方式で許可されている場合は、複数のRTPパケットが含まれる場合があります（セクション11を参照）。
RTCP packet: A control packet consisting of a fixed header part similar to that of RTP data packets, followed by structured elements that vary depending upon the RTCP packet type. The formats are defined in Section 6. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet.
RTCPパケット：RTPデータパケットと同様の固定ヘッダー部分と、それに続くRTCPパケットタイプによって異なる構造化要素で構成される制御パケット。形式はセクション6で定義されています。通常、複数のRTCPパケットは、基礎となるプロトコルの単一のパケットで複合RTCPパケットとして一緒に送信されます。これは、各RTCPパケットの固定ヘッダーの長さフィールドによって有効になります。
Port: The "abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers." [12] The transport selectors (TSEL) used by the OSI transport layer are equivalent to ports. RTP depends upon the lower-layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session.
ポート：「トランスポートプロトコルが特定のホストコンピュータ内の複数の宛先を区別するために使用する抽象化。TCP/ IPプロトコルは、小さな正の整数を使用してポートを識別します。」 [12] OSIトランスポート層で使用されるトランスポートセレクター（TSEL）はポートに相当します。 RTPは、セッションのRTPパケットとRTCPパケットを多重化するポートなどのメカニズムを提供するために、下位層プロトコルに依存しています。
Transport address: The combination of a network address and port that identifies a transport-level endpoint, for example an IP address and a UDP port. Packets are transmitted from a source transport address to a destination transport address.
トランスポートアドレス：ネットワークアドレスと、トランスポートレベルのエンドポイントを識別するポートの組み合わせ（IPアドレスやUDPポートなど）。パケットは、ソーストランスポートアドレスから宛先トランスポートアドレスに送信されます。
RTP media type: An RTP media type is the collection of payload types which can be carried within a single RTP session. The RTP Profile assigns RTP media types to RTP payload types.
RTPメディアタイプ：RTPメディアタイプは、単一のRTPセッション内で伝送できるペイロードタイプのコレクションです。 RTPプロファイルは、RTPメディアタイプをRTPペイロードタイプに割り当てます。
Multimedia session: A set of concurrent RTP sessions among a common group of participants. For example, a videoconference (which is a multimedia session) may contain an audio RTP session and a video RTP session.
マルチメディアセッション：参加者の共通グループ間の同時RTPセッションのセット。たとえば、ビデオ会議（マルチメディアセッション）には、オーディオRTPセッションとビデオRTPセッションが含まれる場合があります。
RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each.
RTPセッション：RTPと通信する一連の参加者間の関連付け。参加者は、複数のRTPセッションに同時に関与する場合があります。マルチメディアセッションでは、エンコード自体が複数のメディアを単一のデータストリームに多重化しない限り、通常、各メディアは独自のRTCPパケットを使用して個別のRTPセッションで伝送されます。参加者は、宛先トランスポートアドレスの異なるペアを使用して異なるセッションを受信することにより、複数のRTPセッションを区別します。トランスポートアドレスのペアは、1つのネットワークアドレスとRTPおよびRTCPのポートのペアで構成されます。 RTPセッションのすべての参加者は、IPマルチキャストの場合のように、共通の宛先トランスポートアドレスのペアを共有するか、個々のユニキャストネットワークアドレスとポートのペアの場合のように、参加者ごとにペアが異なる場合があります。ユニキャストの場合、参加者は同じペアのポートを使用してセッションの他のすべての参加者から受信するか、それぞれに異なるペアのポートを使用します。
The distinguishing feature of an RTP session is that each maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants.
RTPセッションの際立った特徴は、それぞれがSSRC識別子の完全な個別のスペースを維持することです（次に定義）。 1つのRTPセッションに含まれる参加者のセットは、参加者のいずれかが送信したSSRC識別子をRTPでSSRCまたはCSRC（以下でも定義）またはRTCPで受信できる参加者で構成されます。たとえば、各参加者が別のポートペアで他の2つから受信するユニキャストUDPを使用して実装された3者間会議について考えてみます。各参加者が他の1人の参加者から受信したデータに関するRTCPフィードバックをその参加者にのみ送信する場合、会議は3つの個別のポイントツーポイントRTPセッションで構成されます。各参加者が他の1人の参加者の受信に関するRTCPフィードバックを他の参加者の両方に提供する場合、会議は1つのマルチパーティRTPセッションで構成されます。後者のケースは、3人の参加者間のIPマルチキャスト通信で発生する動作をシミュレートします。
The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations.
RTPフレームワークはここで定義されたバリエーションを許可しますが、特定の制御プロトコルまたはアプリケーション設計は通常これらのバリエーションに制約を課します。
Synchronization source (SSRC): The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera, or an RTP mixer (see below). A synchronization source may change its data format, e.g., audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session (see Section 8). A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session; the binding of the SSRC identifiers is provided through RTCP (see Section 6.5.1). If a participant generates multiple streams in one RTP session, for example from separate video cameras, each MUST be identified as a different SSRC.
同期ソース（SSRC）：RTPパケットのストリームのソース。ネットワークアドレスに依存しないように、RTPヘッダーで運ばれる32ビットの数値SSRC識別子によって識別されます。同期ソースからのすべてのパケットは、同じタイミングとシーケンス番号空間の一部を形成するため、レシーバーは再生のために同期ソースごとにパケットをグループ化します。同期ソースの例には、マイクやカメラなどの信号ソースから派生したパケットストリームの送信者、またはRTPミキサーが含まれます（以下を参照）。同期ソースは、時間の経過とともにそのデータ形式（オーディオエンコーディングなど）を変更する場合があります。 SSRC IDは、特定のRTPセッション内でグローバルに一意になるようにランダムに選択された値です（セクション8を参照）。参加者は、マルチメディアセッションのすべてのRTPセッションに同じSSRC識別子を使用する必要はありません。 SSRC識別子のバインディングは、RTCPを通じて提供されます（6.5.1を参照）。参加者が1つのRTPセッションで、たとえば別々のビデオカメラから複数のストリームを生成する場合、それぞれを異なるSSRCとして識別する必要があります。
Contributing source (CSRC): A source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer (see below). The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. An example application is audio conferencing where a mixer indicates all the talkers whose speech was combined to produce the outgoing packet, allowing the receiver to indicate the current talker, even though all the audio packets contain the same SSRC identifier (that of the mixer).
寄与ソース（CSRC）：RTPミキサーによって生成された結合ストリームに寄与したRTPパケットのストリームのソース（以下を参照）。ミキサーは、特定のパケットの生成に関与したソースのSSRC識別子のリストを、そのパケットのRTPヘッダーに挿入します。このリストはCSRCリストと呼ばれます。アプリケーションの例としては、音声会議が挙げられます。ミキサーは、音声が結合されて発信パケットを生成したすべてのトーカーを示し、すべてのオーディオパケットに同じSSRC識別子（ミキサーのもの）が含まれていても、レシーバーが現在のトーカーを示すことができます。
End system: An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets. An end system can act as one or more synchronization sources in a particular RTP session, but typically only one.
エンドシステム：RTPパケットで送信されるコンテンツを生成したり、受信したRTPパケットのコンテンツを消費したりするアプリケーション。エンドシステムは、特定のRTPセッションで1つ以上の同期ソースとして機能できますが、通常は1つだけです。
Mixer: An intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source.
ミキサー：1つ以上のソースからRTPパケットを受信し、おそらくデータ形式を変更し、何らかの方法でパケットを結合してから、新しいRTPパケットを転送する中間システム。複数の入力ソース間のタイミングは一般に同期されないため、ミキサーはストリーム間のタイミング調整を行い、結合されたストリームに対して独自のタイミングを生成します。したがって、ミキサーから発信されたすべてのデータパケットは、同期ソースとしてミキサーを持っているものとして識別されます。
Translator: An intermediate system that forwards RTP packets with their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application-level filters in firewalls.
トランスレータ：同期ソース識別子をそのままにしてRTPパケットを転送する中間システム。トランスレータの例には、ミキシングせずにエンコーディングを変換するデバイス、マルチキャストからユニキャストへのレプリケータ、ファイアウォール内のアプリケーションレベルのフィルタなどがあります。
Monitor: An application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current quality of service for distribution monitoring, fault diagnosis and long-term statistics. The monitor function is likely to be built into the application(s) participating in the session, but may also be a separate application that does not otherwise participate and does not send or receive the RTP data packets (since they are on a separate port). These are called third-party monitors. It is also acceptable for a third-party monitor to receive the RTP data packets but not send RTCP packets or otherwise be counted in the session.
モニター：RTPセッションの参加者によって送信されたRTCPパケット、特に受信レポートを受信し、配信の監視、障害診断、および長期統計のために現在のサービス品質を推定するアプリケーション。モニター機能は、セッションに参加しているアプリケーションに組み込まれている可能性がありますが、他の方法では参加せず、RTPデータパケットを送信または受信しない別のアプリケーションである可能性があります（これらは別のポートにあるため） 。これらはサードパーティのモニターと呼ばれます。また、サードパーティのモニターがRTPデータパケットを受信しても、RTCPパケットを送信したり、セッションでカウントされないようにすることもできます。
Non-RTP means: Protocols and mechanisms that may be needed in addition to RTP to provide a usable service. In particular, for multimedia conferences, a control protocol may distribute multicast addresses and keys for encryption, negotiate the encryption algorithm to be used, and define dynamic mappings between RTP payload type values and the payload formats they represent for formats that do not have a predefined payload type value. Examples of such protocols include the Session Initiation Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326 [16]). For simple
非RTPとは、RTPに加えて、使用可能なサービスを提供するために必要となる可能性のあるプロトコルとメカニズムを意味します。特に、マルチメディア会議の場合、制御プロトコルは、暗号化のためにマルチキャストアドレスとキーを配布し、使用する暗号化アルゴリズムをネゴシエートし、RTPペイロードタイプの値と、事前定義されていない形式に対してそれらが表すペイロード形式の間の動的マッピングを定義しますペイロードタイプの値。そのようなプロトコルの例には、セッション開始プロトコル（SIP）（RFC 3261 [13]）、ITU勧告H.323 [14]、およびRTSP（RFC 2326 [16]）などのSDP（RFC 2327 [15]）を使用するアプリケーションが含まれます。 。単純な
applications, electronic mail or a conference database may also be used. The specification of such protocols and mechanisms is outside the scope of this document.
アプリケーション、電子メール、または会議データベースも使用できます。そのようなプロトコルとメカニズムの仕様は、このドキュメントの範囲外です。
All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [3]. Unless otherwise noted, numeric constants are in decimal (base 10).
すべての整数フィールドは、ネットワークバイトオーダーで運ばれます。つまり、最上位バイト（オクテット）が最初です。このバイトオーダーは、一般にビッグエンディアンと呼ばれます。送信順序については、[3]で詳しく説明しています。特に明記しない限り、数値定数は10進数（基数10）です。
All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero.
すべてのヘッダーデータは自然な長さに揃えられます。つまり、16ビットのフィールドは偶数のオフセットに揃えられ、32ビットのフィールドは4で割り切れるオフセットに揃えられます。パディングとして指定されたオクテットの値はゼロです。
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 [4]. The full resolution NTP timestamp 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. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently.
ウォールクロック時間（絶対日時）は、Network Time Protocol（NTP）のタイムスタンプ形式を使用して表されます。これは、1900年1月1日の0h UTCを基準とした秒単位です[4]。フル解像度のNTPタイムスタンプは、64ビットの符号なし固定小数点数であり、最初の32ビットに整数部分があり、最後の32ビットに小数部分があります。よりコンパクトな表現が適切な一部のフィールドでは、中央の32ビットのみが使用されます。つまり、整数部の下位16ビットと小数部の上位16ビットです。整数部分の上位16ビットは個別に決定する必要があります。
An implementation is not required to run the Network Time Protocol in order to use RTP. Other time sources, or none at all, may be used (see the description of the NTP timestamp field in Section 6.4.1). However, running NTP may be useful for synchronizing streams transmitted from separate hosts.
RTPを使用するために、ネットワークタイムプロトコルを実行するための実装は必要ありません。他の時間ソースを使用することも、まったく使用しないこともできます（セクション6.4.1のNTPタイムスタンプフィールドの説明を参照）。ただし、NTPの実行は、別のホストから送信されたストリームの同期に役立つ場合があります。
The NTP timestamp will wrap around to zero some time in the year 2036, but for RTP purposes, only differences between pairs of NTP timestamps are used. So long as the pairs of timestamps can be assumed to be within 68 years of each other, using modular arithmetic for subtractions and comparisons makes the wraparound irrelevant.
NTPタイムスタンプは2036年のある時点で循環してゼロになりますが、RTPの目的では、NTPタイムスタンプのペア間の違いのみが使用されます。タイムスタンプのペアが互いに68年以内であると想定できる限り、減算と比較にモジュラー算術を使用すると、ラップアラウンドは無関係になります。
5.1 RTP Fixed Header Fields
5.1 RTP固定ヘッダーフィールド
The RTP header has the following format:
RTPヘッダーの形式は次のとおりです。
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|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer. The fields have the following meaning:
最初の12オクテットはすべてのRTPパケットに存在しますが、CSRC識別子のリストはミキサーによって挿入された場合にのみ存在します。フィールドの意味は次のとおりです。
version (V): 2 bits This field identifies the version of RTP. The version defined by this specification is two (2). (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol initially implemented in the "vat" audio tool.)
バージョン（V）：2ビットこのフィールドは、RTPのバージョンを識別します。この仕様で定義されているバージョンは2です。 （値1はRTPの最初のドラフトバージョンで使用され、値0は「バット」オーディオツールで最初に実装されたプロトコルで使用されます。
padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit.
パディング（P）：1ビットパディングビットが設定されている場合、パケットの末尾には、ペイロードの一部ではない1つ以上の追加のパディングオクテットが含まれます。パディングの最後のオクテットには、無視されるパディングオクテットの数が含まれます。固定ブロックサイズの一部の暗号化アルゴリズムや、下位層のプロトコルデータユニットで複数のRTPパケットを伝送するために、パディングが必要になる場合があります。
extension (X): 1 bit If the extension bit is set, the fixed header MUST be followed by exactly one header extension, with a format defined in Section 5.3.1.
拡張（X）：1ビット拡張ビットが設定されている場合、固定ヘッダーの後には、セクション5.3.1で定義されている形式のヘッダー拡張が1つだけ続く必要があります。
CSRC count (CC): 4 bits The CSRC count contains the number of CSRC identifiers that follow the fixed header.
CSRCカウント（CC）：4ビットCSRCカウントには、固定ヘッダーに続くCSRC識別子の数が含まれます。
marker (M): 1 bit The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field (see Section 5.3).
マーカー（M）：1ビットマーカーの解釈はプロファイルによって定義されます。これは、フレーム境界などの重要なイベントをパケットストリームでマークできるようにすることを目的としています。プロファイルは、ペイロードタイプフィールドのビット数を変更することにより、追加のマーカービットを定義するか、マーカービットがないことを指定できます（セクション5.3を参照）。
payload type (PT): 7 bits This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2).
ペイロードタイプ（PT）：7ビットこのフィールドは、RTPペイロードの形式を識別し、アプリケーションによる解釈を決定します。プロファイルは、ペイロードタイプコードのペイロード形式へのデフォルトの静的マッピングを指定する場合があります。追加のペイロードタイプコードは、RTP以外の方法で動的に定義できます（セクション3を参照）。オーディオとビデオのデフォルトのマッピングのセットは、関連するRFC 3551 [1]で指定されています。 RTPソースは、セッション中にペイロードタイプを変更してもかまいませんが、このフィールドは、個別のメディアストリームの多重化には使用しないでください（セクション5.2を参照）。
A receiver MUST ignore packets with payload types that it does not understand.
レシーバーは、理解できないペイロードタイプのパケットを無視する必要があります。
sequence number: 16 bits The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may flow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [17].
シーケンス番号：16ビットシーケンス番号は、送信されるRTPデータパケットごとに1ずつ増加し、パケット損失を検出してパケットシーケンスを復元するために受信者が使用できます。シーケンス番号の初期値はランダム（予測不可能）である必要があり（SHOULD）、ソース自体がセクション9.1の方法に従って暗号化しない場合でも、暗号化に対する既知の平文攻撃をより困難にします。 。予測できない数値を選択する手法は、[17]で説明されています。
timestamp: 32 bits The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution of the clock MUST be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or MAY be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for fixed-rate audio the timestamp clock would likely increment by one for each sampling period. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent.
タイムスタンプ：32ビットタイムスタンプは、RTPデータパケットの最初のオクテットのサンプリングの瞬間を反映しています。サンプリングの瞬間は、同期とジッターの計算を可能にするために、時間とともに単調かつ線形に増加するクロックから派生しなければなりません（セクション6.4.1を参照）。クロックの分解能は、必要な同期精度とパケット到着ジッターの測定に十分でなければなりません（ビデオフレームごとに1ティックでは通常十分ではありません）。クロック周波数は、ペイロードとして伝送されるデータのフォーマットに依存し、フォーマットを定義するプロファイルまたはペイロードフォーマット仕様で静的に指定されるか、非RTP手段で定義されたペイロードフォーマットに対して動的に指定される場合があります。 RTPパケットが定期的に生成される場合、システムクロックの読み取り値ではなく、サンプリングクロックから決定された公称サンプリングインスタントが使用されます。例として、固定レートのオーディオの場合、タイムスタンプクロックは、サンプリング期間ごとに1ずつ増加する可能性があります。オーディオアプリケーションが160のサンプリング期間をカバーするブロックを入力デバイスから読み取る場合、ブロックがパケットで送信されるかサイレントとしてドロップされるかに関係なく、タイムスタンプはそのようなブロックごとに160ずつ増加します。
The initial value of the timestamp SHOULD be random, as for the sequence number. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.)
シーケンス番号と同様に、タイムスタンプの初期値はランダムである必要があります（SHOULD）。いくつかの連続したRTPパケットは、それらが（論理的に）一度に生成される場合、たとえば同じビデオフレームに属する場合、タイムスタンプが等しくなります。 MPEG補間ビデオフレームの場合のように、データがサンプリングされた順序で送信されない場合、連続するRTPパケットには単調でないタイムスタンプが含まれる場合があります。 （送信されたパケットのシーケンス番号は依然として単調です。）
RTP timestamps from different media streams may advance at different rates and usually have independent, random offsets. Therefore, although these timestamps are sufficient to reconstruct the timing of a single stream, directly comparing RTP timestamps from different media is not effective for synchronization. Instead, for each medium the RTP timestamp is related to the sampling instant by pairing it with a timestamp from a reference clock (wallclock) that represents the time when the data corresponding to the RTP timestamp was sampled. The reference clock is shared by all media to be synchronized. The timestamp pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as described in Section 6.4.
異なるメディアストリームからのRTPタイムスタンプは異なる速度で進む可能性があり、通常は独立したランダムオフセットがあります。したがって、これらのタイムスタンプは単一のストリームのタイミングを再構築するには十分ですが、異なるメディアからのRTPタイムスタンプを直接比較しても同期には効果的ではありません。代わりに、各メディアのRTPタイムスタンプは、RTPタイムスタンプに対応するデータがサンプリングされた時刻を表す参照クロック（ウォールクロック）からのタイムスタンプとペアにすることで、サンプリングインスタントに関連付けられます。基準クロックは、同期されるすべてのメディアで共有されます。タイムスタンプのペアは、すべてのデータパケットで送信されるわけではありませんが、セクション6.4で説明されているように、RTCP SRパケットではより低いレートで送信されます。
The sampling instant is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common definition for all media, independent of encoding delays or other processing. The purpose is to allow synchronized presentation of all media sampled at the same time.
サンプリングインスタントはRTPタイムスタンプの参照ポイントとして選択されます。これは、RTPタイムスタンプが送信エンドポイントに認識され、エンコーディング遅延やその他の処理とは無関係に、すべてのメディアに共通の定義があるためです。目的は、同時にサンプリングされたすべてのメディアを同期して提示できるようにすることです。
Applications transmitting stored data rather than data sampled in real time typically use a virtual presentation timeline derived from wallclock time to determine when the next frame or other unit of each medium in the stored data should be presented. In this case, the RTP timestamp would reflect the presentation time for each unit. That is, the RTP timestamp for each unit would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. Actual presentation occurs some time later as determined by the receiver.
リアルタイムでサンプリングされたデータではなく、格納されたデータを送信するアプリケーションは、通常、実時間から導出された仮想プレゼンテーションタイムラインを使用して、格納されたデータ内の各メディアの次のフレームまたは他のユニットをいつ表示するかを決定します。この場合、RTPタイムスタンプは各ユニットのプレゼンテーション時間を反映します。つまり、各ユニットのRTPタイムスタンプは、仮想プレゼンテーションタイムラインでユニットが最新になるウォールクロック時間に関連付けられます。実際のプレゼンテーションは、受信者の判断により、しばらくして発生します。
An example describing live audio narration of prerecorded video illustrates the significance of choosing the sampling instant as the reference point. In this scenario, the video would be presented locally for the narrator to view and would be simultaneously transmitted using RTP. The "sampling instant" of a video frame transmitted in RTP would be established by referencing its timestamp to the wallclock time when that video frame was presented to the narrator. The sampling instant for the audio RTP packets containing the narrator's speech would be established by referencing the same wallclock time when the audio was sampled. The audio and video may even be transmitted by different hosts if the reference clocks on the two hosts are synchronized by some means such as NTP. A receiver can then synchronize presentation of the audio and video packets by relating their RTP timestamps using the timestamp pairs in RTCP SR packets.
事前に記録されたビデオのライブオーディオナレーションを説明する例は、基準点としてサンプリングの瞬間を選択することの重要性を示しています。このシナリオでは、ナレーターが見るためにビデオがローカルに提示され、RTPを使用して同時に送信されます。 RTPで送信されたビデオフレームの「サンプリングインスタント」は、そのビデオフレームがナレーターに提示されたときの実時間にタイムスタンプを参照することによって確立されます。ナレーターのスピーチを含むオーディオRTPパケットのサンプリングインスタントは、オーディオがサンプリングされたときと同じ壁時計時間を参照することによって確立されます。 2つのホストの基準クロックがNTPなどの手段によって同期されている場合、オーディオとビデオは異なるホストによって送信されることもあります。次に、受信者は、RTCP SRパケットのタイムスタンプペアを使用してRTPタイムスタンプを関連付けることにより、オーディオパケットとビデオパケットのプレゼンテーションを同期できます。
SSRC: 32 bits The SSRC field identifies the synchronization source. This identifier SHOULD be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. An example algorithm for generating a random identifier is presented in Appendix A.6. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. Section 8 describes the probability of collision along with a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source (see Section 8.2).
SSRC：32ビットSSRCフィールドは同期ソースを識別します。この識別子は、同じRTPセッション内の2つの同期ソースが同じSSRC識別子を持たないように、ランダムに選択する必要があります（SHOULD）。ランダムな識別子を生成するためのアルゴリズムの例を付録A.6に示します。複数のソースが同じ識別子を選択する可能性は低いですが、衝突を検出して解決するために、すべてのRTP実装を準備する必要があります。セクション8では、SSRC識別子の一意性に基づいて、衝突を解決し、RTPレベルの転送ループを検出するメカニズムとともに、衝突の確率について説明します。ソースがそのソーストランスポートアドレスを変更する場合、ループしたソースとして解釈されないように、新しいSSRC識別子を選択する必要もあります（セクション8.2を参照）。
CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. CSRC identifiers are inserted by mixers (see Section 7.1), using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.
CSRCリスト：0〜15項目、各32ビットCSRCリストは、このパケットに含まれるペイロードの原因となっているソースを識別します。識別子の数はCCフィールドで指定されます。 15を超えるソースがある場合、特定できるのは15のみです。 CSRC識別子は、提供元のSSRC識別子を使用して、ミキサー（セクション7.1を参照）によって挿入されます。たとえば、オーディオパケットの場合、パケットを作成するために混合されたすべてのソースのSSRC識別子がリストされ、レシーバーで正しいトーカーを示すことができます。
5.2 Multiplexing RTP Sessions
5.2 RTPセッションの多重化
For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address.
効率的なプロトコル処理のために、統合層処理の設計原理[10]で説明されているように、多重化ポイントの数を最小限に抑える必要があります。 RTPでは、多重化は、RTPセッションごとに異なる宛先トランスポートアドレス（ネットワークアドレスとポート番号）によって提供されます。たとえば、別々にエンコードされたオーディオおよびビデオメディアで構成される電話会議では、各メディアは独自の宛先トランスポートアドレスを持つ個別のRTPセッションで伝送される必要があります（SHOULD）。
Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems:
個別のオーディオストリームとビデオストリームは、単一のRTPセッションで伝送されるべきではなく、ペイロードタイプまたはSSRCフィールドに基づいて逆多重化されるべきではありません。 RTPメディアタイプが異なるが同じSSRCを使用してパケットをインターリーブすると、いくつかの問題が発生します。
1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings.
1. たとえば、2つのオーディオストリームが同じRTPセッションと同じSSRC値を共有し、1つがエンコーディングを変更して異なるRTPペイロードタイプを取得する場合、どのストリームがエンコーディングを変更したかを識別する一般的な方法はありません。
2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss.
2. SSRCは、単一のタイミングおよびシーケンス番号スペースを識別するために定義されています。メディアクロックレートが異なる場合、複数のペイロードタイプをインターリーブするには異なるタイミングスペースが必要であり、パケット損失が発生したペイロードタイプを通知するために異なるシーケンス番号スペースが必要になります。
3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field.
3. RTCP送信者および受信者レポート（セクション6.4を参照）は、SSRCごとに1つのタイミングおよびシーケンス番号スペースのみを記述でき、ペイロードタイプフィールドを伝送しません。
4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream.
4. RTPミキサーは、互換性のないメディアのインターリーブされたストリームを1つのストリームに結合できません。
5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations.
5. 1つのRTPセッションで複数のメディアを伝送すると、以下が排除されます。適切な場合、異なるネットワークパスまたはネットワークリソース割り当ての使用。必要に応じてメディアのサブセットを受信します。たとえば、ビデオが使用可能な帯域幅を超える場合はオーディオのみ。異なるメディアに対して個別のプロセスを使用するレシーバーの実装。個別のRTPセッションを使用すると、単一プロセスまたは複数プロセスの実装が可能になります。
Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two.
メディアごとに異なるSSRCを使用し、同じRTPセッションでそれらを送信すると、最初の3つの問題は回避できますが、最後の2つの問題は回避できません。
On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply.
一方、異なるSSRC値を使用して1つのRTPセッションで同じメディアの複数の関連するソースを多重化することは、マルチキャストセッションの標準です。上記の問題は当てはまりません。たとえば、RTPミキサーは複数のオーディオソースを組み合わせることができ、同じ処理をそれらすべてに適用できます。最後の2つの問題が当てはまらない他のシナリオでは、異なるSSRC値を使用して同じメディアのストリームを多重化することも適切な場合があります。
5.3 Profile-Specific Modifications to the RTP Header
5.3 RTPヘッダーに対するプロファイル固有の変更
The existing RTP data packet header is believed to be complete for the set of functions required in common across all the application classes that RTP might support. However, in keeping with the ALF design principle, the header MAY be tailored through modifications or additions defined in a profile specification while still allowing profile-independent monitoring and recording tools to function.
既存のRTPデータパケットヘッダーは、RTPがサポートする可能性のあるすべてのアプリケーションクラスに共通して必要な一連の機能に対して完全であると考えられています。ただし、ALFの設計原則に従って、ヘッダーは、プロファイルに依存しない監視および記録ツールを機能させながら、プロファイル仕様で定義された変更または追加によって調整できます（MAY）。
o The marker bit and payload type field carry profile-specific information, but they are allocated in the fixed header since many applications are expected to need them and might otherwise have to add another 32-bit word just to hold them. The octet containing these fields MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits. If there are any marker bits, one SHOULD be located in the most significant bit of the octet since profile-independent monitors may be able to observe a correlation between packet loss patterns and the marker bit.
o マーカービットとペイロードタイプフィールドにはプロファイル固有の情報が含まれますが、多くのアプリケーションではそれらが必要であり、保持するためだけに別の32ビットワードを追加する必要があるため、固定ヘッダーに割り当てられます。これらのフィールドを含むオクテットは、たとえばマーカービットの増減など、さまざまな要件に適合するようにプロファイルによって再定義される場合があります。マーカービットがある場合は、プロファイルに依存しないモニターがパケット損失パターンとマーカービット間の相関を観察できる可能性があるため、オクテットの最上位ビットに1つを配置する必要があります（SHOULD）。
o Additional information that is required for a particular payload format, such as a video encoding, SHOULD be carried in the payload section of the packet. This might be in a header that is always present at the start of the payload section, or might be indicated by a reserved value in the data pattern.
o ビデオエンコーディングなど、特定のペイロード形式に必要な追加情報は、パケットのペイロードセクションで伝送する必要があります（SHOULD）。これは、ペイロードセクションの先頭に常に存在するヘッダーに含まれている場合と、データパターンの予約値で示されている場合があります。
o If a particular class of applications needs additional functionality independent of payload format, the profile under which those applications operate SHOULD define additional fixed fields to follow immediately after the SSRC field of the existing fixed header. Those applications will be able to quickly and directly access the additional fields while profile-independent monitors or recorders can still process the RTP packets by interpreting only the first twelve octets.
o アプリケーションの特定のクラスがペイロード形式とは関係なく追加の機能を必要とする場合、それらのアプリケーションが動作するプロファイルは、既存の固定ヘッダーのSSRCフィールドの直後に続く追加の固定フィールドを定義する必要があります。これらのアプリケーションは、追加のフィールドにすばやく直接アクセスできますが、プロファイルに依存しないモニターまたはレコーダーは、最初の12オクテットのみを解釈してRTPパケットを処理できます。
If it turns out that additional functionality is needed in common across all profiles, then a new version of RTP should be defined to make a permanent change to the fixed header.
すべてのプロファイルに共通の追加機能が必要であることが判明した場合は、新しいバージョンのRTPを定義して、固定ヘッダーに永続的な変更を加える必要があります。
5.3.1 RTP Header Extension
5.3.1 RTPヘッダー拡張
An extension mechanism is provided to allow individual implementations to experiment with new payload-format-independent functions that require additional information to be carried in the RTP data packet header. This mechanism is designed so that the header extension may be ignored by other interoperating implementations that have not been extended.
RTPデータパケットヘッダーで追加情報を伝達する必要がある新しいペイロード形式に依存しない関数を個々の実装で実験できるように、拡張メカニズムが提供されています。このメカニズムは、ヘッダー拡張が、拡張されていない他の相互運用実装によって無視されるように設計されています。
Note that this header extension is intended only for limited use. Most potential uses of this mechanism would be better done another way, using the methods described in the previous section. For example, a profile-specific extension to the fixed header is less expensive to process because it is not conditional nor in a variable location. Additional information required for a particular payload format SHOULD NOT use this header extension, but SHOULD be carried in the payload section of the packet.
このヘッダー拡張は、限られた使用のみを目的としています。このメカニズムを使用する可能性が最も高いのは、前のセクションで説明した方法を使用する別の方法のほうが適しています。たとえば、固定ヘッダーに対するプロファイル固有の拡張は、条件付きでも可変位置でもないため、処理コストが低くなります。特定のペイロード形式に必要な追加情報は、このヘッダー拡張を使用してはいけません（SHOULD NOT）。ただし、パケットのペイロードセクションで運ぶ必要があります（SHOULD）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself.
RTPヘッダーのXビットが1の場合、可変長ヘッダー拡張をRTPヘッダーに付加する必要があります（存在する場合はCSRCリストに従います）。ヘッダー拡張には、拡張内の32ビットワードの数をカウントする16ビットの長さフィールドが含まれます（4オクテット拡張ヘッダーを除く）（したがって、ゼロは有効な長さです）。 RTPデータヘッダーに追加できる拡張子は1つだけです。複数の相互運用実装が異なるヘッダー拡張を使用して独立して各実験を行えるようにするか、特定の実装が複数の種類のヘッダー拡張を実験できるようにするには、ヘッダー拡張の最初の16ビットを識別子またはパラメーターを区別するために開いたままにします。これらの16ビットのフォーマットは、実装が動作しているプロファイル仕様によって定義されます。このRTP仕様では、ヘッダー拡張自体は定義されていません。
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions:
RTP制御プロトコル（RTCP）は、データパケットと同じ配布メカニズムを使用して、セッションのすべての参加者への制御パケットの定期的な送信に基づいています。基になるプロトコルは、データと制御パケットの多重化を提供する必要があります。たとえば、UDPで個別のポート番号を使用します。 RTCPは4つの機能を実行します。
1. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols (see Section 10 on the requirement for congestion control). The feedback may be directly useful for control of adaptive encodings [18,19], but experiments with IP multicasting have shown that it is also critical to get feedback from the receivers to diagnose faults in the distribution. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. With a distribution mechanism like IP multicast, it is also possible for an entity such as a network service provider who is not otherwise involved in the session to receive the feedback information and act as a third-party monitor to diagnose network problems. This feedback function is performed by the RTCP sender and receiver reports, described below in Section 6.4.
1. 主な機能は、データ配信の品質に関するフィードバックを提供することです。これは、トランスポートプロトコルとしてのRTPの役割の不可欠な部分であり、他のトランスポートプロトコルのフローおよび輻輳制御機能に関連しています（輻輳制御の要件については、セクション10を参照）。フィードバックはアダプティブエンコーディングの制御に直接役立つ場合がありますが[18,19]、IPマルチキャストの実験では、配信の障害を診断するためにレシーバーからフィードバックを取得することも重要であることが示されています。受信フィードバックレポートをすべての参加者に送信することで、問題を観察している人は、それらの問題がローカルであるかグローバルであるかを評価できます。 IPマルチキャストのような配信メカニズムを使用すると、セッションに関与していないネットワークサービスプロバイダーなどのエンティティがフィードバック情報を受信し、サードパーティのモニターとして機能してネットワークの問題を診断することもできます。このフィードバック機能は、RTCPの送信者と受信者のレポートによって実行されます（セクション6.4を参照）。
2. RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME, Section 6.5.1. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. Receivers may also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. Inter-media synchronization also requires the NTP and RTP timestamps included in RTCP packets by data senders.
2. RTCPは、正規名またはCNAMEと呼ばれるRTPソースの永続的なトランスポートレベルの識別子を運びます（セクション6.5.1）。競合が発見された場合、またはプログラムが再起動された場合、SSRC識別子が変更される可能性があるため、受信者は各参加者を追跡するためにCNAMEを必要とします。また、受信者は、CNAMEに、関連するRTPセッションのセットの特定の参加者からの複数のデータストリームを関連付けて、たとえばオーディオとビデオを同期させるよう要求する場合もあります。メディア間の同期には、データ送信者がRTCPパケットに含めるNTPおよびRTPタイムスタンプも必要です。
3. The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent, as explained in Section 6.2.
3. 最初の2つの機能では、すべての参加者がRTCPパケットを送信する必要があるため、RTPを多数の参加者にスケールアップするには、レートを制御する必要があります。各参加者に制御パケットを他のすべての参加者に送信させることにより、参加者の数を個別に監視できます。この数値は、セクション6.2で説明されているように、パケットが送信される速度を計算するために使用されます。
4. A fourth, OPTIONAL function is to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation. RTCP serves as a convenient channel to reach all the participants, but it is not necessarily expected to support all the control communication requirements of an application. A higher-level session control protocol, which is beyond the scope of this document, may be needed.
4. 4番目のOPTIONAL機能は、最小限のセッション制御情報、たとえばユーザーインターフェースに表示される参加者の識別情報を伝えることです。これは、メンバーシップの制御やパラメーターのネゴシエーションなしで参加者が出入りする「緩やかに制御された」セッションで役立つ可能性が最も高くなります。 RTCPは、すべての参加者に到達するための便利なチャネルとして機能しますが、アプリケーションのすべての制御通信要件をサポートするとは限りません。このドキュメントの範囲を超える、より高レベルのセッション制御プロトコルが必要になる場合があります。
Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. Transmission of RTCP MAY be controlled separately for senders and receivers, as described in Section 6.2, for cases such as unidirectional links where feedback from receivers is not possible.
機能1〜3はすべての環境で使用する必要がありますが、特にIPマルチキャスト環境では使用してください。 RTPアプリケーション設計者は、ユニキャストモードでのみ機能し、より大きな数にスケーリングしないメカニズムを回避する必要があります（SHOULD）。 RTCPの送信は、セクション6.2で説明されているように、レシーバーからのフィードバックが不可能な単一方向リンクの場合など、センダーとレシーバーに対して個別に制御できます。
Non-normative note: In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (a source address, group address pair), and receivers (except for the channel source) cannot use multicast to communicate directly with other channel members. The recommendations here accommodate SSM only through Section 6.2's option of turning off receivers' RTCP entirely. Future work will specify adaptation of RTCP for SSM so that feedback from receivers can be maintained.
非規範的な注記：Source-Specific Multicast（SSM）と呼ばれるマルチキャストルーティングアプローチでは、「チャネル」ごとに1つの送信者（送信元アドレス、グループアドレスのペア）のみがあり、受信者（チャネル送信元を除く）はマルチキャストを使用できません。他のチャンネルメンバーと直接通信する。ここでの推奨事項は、レシーバーのRTCPを完全にオフにするセクション6.2のオプションを通じてのみSSMに対応します。将来の作業では、受信者からのフィードバックを維持できるように、SSMに対するRTCPの適応を指定します。
6.1 RTCP Packet Format
6.1 RTCPパケット形式
This specification defines several RTCP packet types to carry a variety of control information:
この仕様では、さまざまな制御情報を伝送するためにいくつかのRTCPパケットタイプを定義しています。
SR: Sender report, for transmission and reception statistics from participants that are active senders
SR：送信者レポート、アクティブな送信者である参加者からの送受信統計
RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources
RR：受信者レポート、アクティブな送信者ではない参加者からの受信統計、および31を超えるソースでレポートするアクティブな送信者のSRとの組み合わせ
SDES: Source description items, including CNAME
SDES：CNAMEを含むソース記述アイテム
BYE: Indicates end of participation
BYE：参加の終了を示します
APP: Application-specific functions
APP：アプリケーション固有の機能
Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that MAY be of variable length according to the packet type but MUST end on a 32-bit boundary. The alignment requirement and a length field in the fixed part of each packet are included to make RTCP packets "stackable". Multiple RTCP packets can be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet.
各RTCPパケットは、RTPデータパケットと同様の固定部分で始まり、パケットタイプに応じて可変長である可能性がありますが、32ビット境界で終了する必要がある構造化要素が続きます。各パケットの固定部分のアライメント要件と長さフィールドは、RTCPパケットを「スタック可能」にするために含まれています。複数のRTCPパケットをセパレータを介さずに連結して、UDPなどの下位層プロトコルの単一パケットで送信される複合RTCPパケットを形成できます。下位層プロトコルは、複合パケットの終わりを決定するために全体の長さを提供することが期待されるため、複合パケット内の個々のRTCPパケットの明示的なカウントはありません。
Each individual RTCP packet in the compound packet may be processed independently with no requirements upon the order or combination of packets. However, in order to perform the functions of the protocol, the following constraints are imposed: o Reception statistics (in SR or RR) should be sent as often as bandwidth constraints will allow to maximize the resolution of the statistics, therefore each periodically transmitted compound RTCP packet MUST include a report packet.
複合パケット内の個々のRTCPパケットは、パケットの順序や組み合わせを必要とせずに独立して処理できます。ただし、プロトコルの機能を実行するために、次の制約が課されます：o受信統計（SRまたはRRで）は、帯域幅の制約により統計の解像度を最大化できるのと同じ頻度で送信する必要があるため、定期的に送信される複合RTCPパケットにはレポートパケットを含める必要があります。
o New receivers need to receive the CNAME for a source as soon as possible to identify the source and to begin associating media for purposes such as lip-sync, so each compound RTCP packet MUST also include the SDES CNAME except when the compound RTCP packet is split for partial encryption as described in Section 9.1.
o 新しいレシーバーは、ソースを識別し、リップシンクなどの目的でメディアの関連付けを開始するために、ソースのCNAMEをできるだけ早く受信する必要があるため、複合RTCPパケットが分割される場合を除き、各複合RTCPパケットにはSDES CNAMEも含める必要があります。セクション9.1で説明されている部分的な暗号化。
o The number of packet types that may appear first in the compound packet needs to be limited to increase the number of constant bits in the first word and the probability of successfully validating RTCP packets against misaddressed RTP data packets or other unrelated packets.
o 複合パケットの最初に現れるパケットタイプの数を制限して、最初のワードの定数ビットの数と、誤ってアドレス指定されたRTPデータパケットまたは他の無関係なパケットに対してRTCPパケットを正常に検証する確率を増やす必要があります。
Thus, all RTCP packets MUST be sent in a compound packet of at least two individual packets, with the following format:
したがって、すべてのRTCPパケットは、次の形式で、少なくとも2つの個別のパケットの複合パケットで送信する必要があります。
Encryption prefix: If and only if the compound packet is to be encrypted according to the method in Section 9.1, it MUST be prefixed by a random 32-bit quantity redrawn for every compound packet transmitted. If padding is required for the encryption, it MUST be added to the last packet of the compound packet.
暗号化接頭辞：複合パケットがセクション9.1の方法に従って暗号化される場合に限り、送信される複合パケットごとに再描画されるランダムな32ビット量を前に付ける必要があります。暗号化にパディングが必要な場合は、複合パケットの最後のパケットに追加する必要があります。
SR or RR: The first RTCP packet in the compound packet MUST always be a report packet to facilitate header validation as described in Appendix A.2. This is true even if no data has been sent or received, in which case an empty RR MUST be sent, and even if the only other RTCP packet in the compound packet is a BYE.
SRまたはRR：付録A.2で説明されているように、ヘッダー検証を容易にするために、複合パケットの最初のRTCPパケットは常にレポートパケットである必要があります。これは、データが送受信されていない場合でも当てはまります。その場合、空のRRを送信する必要があり、複合パケット内の他のRTCPパケットがBYEである場合でも同様です。
Additional RRs: If the number of sources for which reception statistics are being reported exceeds 31, the number that will fit into one SR or RR packet, then additional RR packets SHOULD follow the initial report packet.
追加のRR：受信統計が報告されているソースの数が31を超える場合、1つのSRまたはRRパケットに収まる数の場合、追加のRRパケットは最初のレポートパケットに従う必要があります（SHOULD）。
SDES: An SDES packet containing a CNAME item MUST be included in each compound RTCP packet, except as noted in Section 9.1. Other source description items MAY optionally be included if required by a particular application, subject to bandwidth constraints (see Section 6.3.9).
SDES：セクション9.1に記載されている場合を除き、CNAMEアイテムを含むSDESパケットは、各複合RTCPパケットに含まれている必要があります。帯域幅の制約に従い、特定のアプリケーションで必要な場合、他のソース記述アイテムをオプションで含めることができます（セクション6.3.9を参照）。
BYE or APP: Other RTCP packet types, including those yet to be defined, MAY follow in any order, except that BYE SHOULD be the last packet sent with a given SSRC/CSRC. Packet types MAY appear more than once.
BYEまたはAPP：まだ定義されていないものを含む他のRTCPパケットタイプは、BYEが特定のSSRC / CSRCで送信された最後のパケットであることを除いて、任意の順序で続くことができます。パケットタイプは複数回表示される場合があります。
An individual RTP participant SHOULD send only one compound RTCP packet per report interval in order for the RTCP bandwidth per participant to be estimated correctly (see Section 6.2), except when the compound RTCP packet is split for partial encryption as described in Section 9.1. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the maximum transmission unit (MTU) of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
個々のRTP参加者は、参加者ごとのRTCP帯域幅を正確に見積もるために（セクション6.2を参照）、レポート間隔ごとに1つの複合RTCPパケットのみを送信する必要があります（セクション6.2を参照）。ソースが多すぎて、ネットワークパスの最大伝送単位（MTU）を超えずに、必要なすべてのRRパケットを1つの複合RTCPパケットに収めるには、1つのMTUに適合するサブセットのみを各間隔に含める必要があります（SHOULD）。すべてのソースが報告されるように、サブセットは複数の間隔でラウンドロビンで選択する必要があります（SHOULD）。
It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.
トランスレータとミキサは、転送する複数のソースからの個々のRTCPパケットを、可能な場合は常に1つの複合パケットに結合して、パケットのオーバーヘッドを償却することをお勧めします（セクション7を参照）。ミキサーによって生成されるRTCP複合パケットの例を図1に示します。複合パケットの全長がネットワークパスのMTUを超える場合は、複数の短い複合パケットに分割して、個別に送信する必要があります（SHOULD）。基礎となるプロトコルのパケット。各複合パケットは少なくとも1つの異なる参加者を表すため、これはRTCP帯域幅の推定を損なうことはありません。複合パケットのそれぞれは、SRまたはRRパケットで始まる必要があることに注意してください。
An implementation SHOULD ignore incoming RTCP packets with types unknown to it. Additional RTCP packet types may be registered with the Internet Assigned Numbers Authority (IANA) as described in Section 15.
実装は、タイプが不明な着信RTCPパケットを無視する必要があります（SHOULD）。セクション15で説明されているように、追加のRTCPパケットタイプをInternet Assigned Numbers Authority（IANA）に登録できます。
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet
図1：RTCP複合パケットの例
6.2 RTCP Transmission Interval
6.2 RTCP送信間隔
RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. For example, in an audio conference the data traffic is inherently self-limiting because only one or two people will speak at a time, so with multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. However, the control traffic is not self-limiting. If the reception reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants. Therefore, the rate must be scaled down by dynamically calculating the interval between RTCP packet transmissions.
RTPは、参加者が数人から数千人までの範囲のセッションサイズでアプリケーションを自動的に拡張できるように設計されています。たとえば、オーディオ会議では、一度に1人または2人しか話せないため、データトラフィックは本質的に自己制限的であり、マルチキャスト配信では、特定のリンクのデータレートは参加者の数に関係なく比較的一定のままです。ただし、制御トラフィックは自己制限的ではありません。各参加者からの受信レポートが一定のレートで送信された場合、制御トラフィックは参加者の数に比例して増加します。したがって、RTCPパケット送信間の間隔を動的に計算することにより、レートを縮小する必要があります。
For each session, it is assumed that the data traffic is subject to an aggregate limit called the "session bandwidth" to be divided among the participants. This bandwidth might be reserved and the limit enforced by the network. If there is no reservation, there may be other constraints, depending on the environment, that establish the "reasonable" maximum for the session to use, and that would be the session bandwidth. The session bandwidth may be chosen based on some cost or a priori knowledge of the available network bandwidth for the session. It is somewhat independent of the media encoding, but the encoding choice may be limited by the session bandwidth. Often, the session bandwidth is the sum of the nominal bandwidths of the senders expected to be concurrently active. For teleconference audio, this number would typically be one sender's bandwidth. For layered encodings, each layer is a separate RTP session with its own session bandwidth parameter.
セッションごとに、データトラフィックは、「セッション帯域幅」と呼ばれる総制限の影響を受け、参加者間で分割されると想定されています。この帯域幅は予約されている場合があり、ネットワークによって制限が適用されます。予約がない場合、環境に応じて、使用するセッションの「妥当な」最大値を確立する他の制約があり、それがセッションの帯域幅になります。セッション帯域幅は、セッションに使用可能なネットワーク帯域幅のコストまたはアプリオリな知識に基づいて選択できます。メディアのエンコーディングとは多少独立していますが、エンコーディングの選択はセッションの帯域幅によって制限される場合があります。多くの場合、セッション帯域幅は、同時にアクティブになると予想される送信者の公称帯域幅の合計です。電話会議の音声の場合、この数は通常、1人の送信者の帯域幅になります。レイヤードエンコーディングの場合、各レイヤーは、独自のセッション帯域幅パラメーターを持つ個別のRTPセッションです。
The session bandwidth parameter is expected to be supplied by a session management application when it invokes a media application, but media applications MAY set a default based on the single-sender data bandwidth for the encoding selected for the session. The application MAY also enforce bandwidth limits based on multicast scope rules or other criteria. All participants MUST use the same value for the session bandwidth so that the same RTCP interval will be calculated.
セッション帯域幅パラメーターは、メディアアプリケーションを呼び出すときにセッション管理アプリケーションによって提供されることが期待されますが、メディアアプリケーションは、セッションに対して選択されたエンコーディングの単一送信者データ帯域幅に基づいてデフォルトを設定できます（MAY）。アプリケーションは、マルチキャストスコープルールまたは他の基準に基づいて、帯域幅制限を適用することもできます（MAY）。すべての参加者は、同じRTCP間隔が計算されるように、セッション帯域幅に同じ値を使用する必要があります。
Bandwidth calculations for control and data traffic include lower-layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
制御トラフィックとデータトラフィックの帯域幅の計算には、下位層のトランスポートとネットワークプロトコル（UDPやIPなど）が含まれます。これは、リソース予約システムが知る必要があることだからです。アプリケーションは、これらのプロトコルのどれが使用されているかを知ることも期待できます。パケットは移動するときに異なるリンクレベルヘッダーでカプセル化されるため、リンクレベルヘッダーは計算に含まれません。
The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. The control traffic bandwidth is in addition to the session bandwidth for the data traffic. It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. While the values of these and other constants in the interval calculation are not critical, all participants in the session MUST use the same values so the same interval will be calculated. Therefore, these constants SHOULD be fixed for a particular profile.
制御トラフィックは、セッション帯域幅の既知の小さな部分に制限する必要があります。データを伝送するためのトランスポートプロトコルの主要な機能が損なわれないように、小さくします。制御トラフィックをリソース予約プロトコルに指定された帯域幅仕様に含めることができ、各参加者が独自にシェアを計算できることが知られています。制御トラフィック帯域幅は、データトラフィックのセッション帯域幅に追加されます。 RTCPに追加されるセッション帯域幅の割合を5％に固定することをお勧めします。また、RTCP帯域幅の1/4をデータを送信する参加者専用にすることをお勧めします。これにより、多数の受信者と少数の送信者のセッションでは、新しく参加する参加者は送信サイトのCNAMEをより迅速に受信できます。 。送信者の比率が参加者の1/4より大きい場合、送信者はRTCP帯域幅全体の比率を取得します。間隔の計算におけるこれらの値やその他の定数は重要ではありませんが、同じ間隔が計算されるように、セッションのすべての参加者は同じ値を使用する必要があります。したがって、これらの定数は特定のプロファイル用に修正する必要があります（SHOULD）。
A profile MAY specify that the control traffic bandwidth may be a separate parameter of the session rather than a strict percentage of the session bandwidth. Using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter.
プロファイルは、制御トラフィック帯域幅が、セッション帯域幅の厳密なパーセンテージではなく、セッションの個別のパラメータである可能性があることを指定する場合があります。個別のパラメーターを使用すると、レート適応型アプリケーションが、セッション帯域幅パラメーターで指定された最大帯域幅よりも低い「通常の」データ帯域幅と一致するRTCP帯域幅を設定できます。
The profile MAY further specify that the control traffic bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not; let us call the parameters S and R. Following the recommendation that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. When the proportion of senders is greater than S/(S+R) of the participants, the senders get their proportion of the sum of these parameters. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is NOT RECOMMENDED because they are needed for the functions listed at the beginning of Section 6, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion.
プロファイルはさらに、制御トラフィックの帯域幅が、アクティブなデータ送信者である参加者とそうでない参加者の2つの別々のセッションパラメータに分割されることを指定できます。パラメータSとRを呼び出します。RTCP帯域幅の1/4をデータ送信者専用にするという推奨に従って、これら2つのパラメータの推奨されるデフォルト値は、それぞれ1.25％と3.75％になります。送信者の比率が参加者のS /（S + R）より大きい場合、送信者はこれらのパラメーターの合計の比率を取得します。 2つのパラメーターを使用すると、データ送信者のRTCP帯域幅をゼロ以外に維持しながら、非データ送信者のRTCP帯域幅をゼロに設定することにより、特定のセッションでRTCP受信レポートを完全にオフにできるため、送信者レポートをインターに送信できます-メディア同期。 RTCP受信レポートをオフにすることは、セクション6の冒頭に記載されている機能、特に受信品質のフィードバックと輻輳制御に必要であるため、推奨されません。ただし、そうすることは、単一方向リンクで動作するシステムや、受信品質や受信機の活性度に関するフィードバックを必要とせず、輻輳を回避する他の手段があるセッションに適している場合があります。
The calculated interval between transmissions of compound RTCP packets SHOULD also have a lower bound to avoid having bursts of packets exceed the allowed bandwidth when the number of participants is small and the traffic isn't smoothed according to the law of large numbers. It also keeps the report interval from becoming too small during transient outages like a network partition such that adaptation is delayed when the partition heals. At application startup, a delay SHOULD be imposed before the first compound RTCP packet is sent to allow time for RTCP packets to be received from other participants so the report interval will converge to the correct value more quickly. This delay MAY be set to half the minimum interval to allow quicker notification that the new participant is present. The RECOMMENDED value for a fixed minimum interval is 5 seconds.
複合RTCPパケットの送信間の計算された間隔にも下限があり、参加者の数が少なく、トラフィックが多数の法則に従って平滑化されていない場合に、パケットのバーストが許容帯域幅を超えないようにする必要があります（SHOULD）。また、ネットワークパーティションのような一時的な停止中にレポートインターバルが小さくなりすぎないようにして、パーティションが回復したときに適応が遅れるようにします。アプリケーションの起動時に、最初の複合RTCPパケットが送信される前に遅延が課されるべきであり（SHOULD）、RTCPパケットが他の参加者から受信される時間を確保して、レポート間隔がより迅速に正しい値に収束するようにします。この遅延は最小間隔の半分に設定して、新しい参加者が存在することをより迅速に通知できるようにする場合があります。一定の最小間隔の推奨値は5秒です。
An implementation MAY scale the minimum RTCP interval to a smaller value inversely proportional to the session bandwidth parameter with the following limitations:
実装は、最小RTCP間隔を、以下の制限付きでセッション帯域幅パラメーターに反比例してより小さい値にスケーリングできます（MAY）。
o For multicast sessions, only active data senders MAY use the reduced minimum value to calculate the interval for transmission of compound RTCP packets.
o マルチキャストセッションの場合、アクティブなデータ送信者のみが最小値を使用して、複合RTCPパケットの送信間隔を計算できます。
o For unicast sessions, the reduced value MAY be used by participants that are not active data senders as well, and the delay before sending the initial compound RTCP packet MAY be zero.
o ユニキャストセッションの場合、削減された値は、アクティブなデータ送信者ではない参加者によっても使用される可能性があり、最初の複合RTCPパケットを送信する前の遅延はゼロになる場合があります。
o For all sessions, the fixed minimum SHOULD be used when calculating the participant timeout interval (see Section 6.3.5) so that implementations which do not use the reduced value for transmitting RTCP packets are not timed out by other participants prematurely.
o すべてのセッションについて、参加者のタイムアウト間隔（セクション6.3.5を参照）を計算するときに固定最小値を使用して（SHOULD）、RTCPパケットの送信に削減された値を使用しない実装が他の参加者によって時期尚早にタイムアウトしないようにします。
o The RECOMMENDED value for the reduced minimum in seconds is 360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s.
o 秒単位で削減された最小値の推奨値は、360をキロビット/秒単位のセッション帯域幅で割った値です。この最小値は、72 kb / sを超える帯域幅では5秒未満です。
The algorithm described in Section 6.3 and Appendix A.7 was designed to meet the goals outlined in this section. It calculates the interval between sending compound RTCP packets to divide the allowed control traffic bandwidth among the participants. This allows an application to provide fast response for small sessions where, for example, identification of all participants is important, yet automatically adapt to large sessions. The algorithm incorporates the following characteristics: o The calculated interval between RTCP packets scales linearly with the number of members in the group. It is this linear factor which allows for a constant amount of control traffic when summed across all members.
セクション6.3および付録A.7で説明されているアルゴリズムは、このセクションで概説されている目標を満たすように設計されています。参加者間で許可された制御トラフィック帯域幅を分割するために、複合RTCPパケットを送信する間隔を計算します。これにより、アプリケーションは、たとえば、すべての参加者の識別が重要でありながら、大きなセッションに自動的に適応するような、小さなセッションに対して高速な応答を提供できます。アルゴリズムには次の特性が組み込まれています。o RTCPパケット間の計算された間隔は、グループ内のメンバーの数に比例します。すべてのメンバーにわたって合計されたときに一定量の制御トラフィックを可能にするのは、この線形係数です。
o The interval between RTCP packets is varied randomly over the range [0.5,1.5] times the calculated interval to avoid unintended synchronization of all participants [20]. The first RTCP packet sent after joining a session is also delayed by a random variation of half the minimum RTCP interval.
o RTCPパケット間の間隔は、計算された間隔の[0.5,1.5]倍の範囲でランダムに変化し、すべての参加者の意図しない同期を回避します[20]。セッションに参加した後に送信された最初のRTCPパケットも、最小RTCP間隔の半分のランダムな変動によって遅延されます。
o A dynamic estimate of the average compound RTCP packet size is calculated, including all those packets received and sent, to automatically adapt to changes in the amount of control information carried.
o 運ばれる制御情報の量の変化に自動的に適応するために、送受信されるすべてのパケットを含む、平均の複合RTCPパケットサイズの動的な見積もりが計算されます。
o Since the calculated interval is dependent on the number of observed group members, there may be undesirable startup effects when a new user joins an existing session, or many users simultaneously join a new session. These new users will initially have incorrect estimates of the group membership, and thus their RTCP transmission interval will be too short. This problem can be significant if many users join the session simultaneously. To deal with this, an algorithm called "timer reconsideration" is employed. This algorithm implements a simple back-off mechanism which causes users to hold back RTCP packet transmission if the group sizes are increasing.
o 計算された間隔は観測されたグループメンバーの数に依存するため、新しいユーザーが既存のセッションに参加したり、多くのユーザーが同時に新しいセッションに参加したりすると、望ましくない起動効果が生じる可能性があります。これらの新しいユーザーは、最初はグループメンバーシップの推定が正しくないため、RTCP送信間隔が短すぎます。多くのユーザーが同時にセッションに参加する場合、この問題は重大になる可能性があります。これに対処するために、「タイマー再考」と呼ばれるアルゴリズムが採用されています。このアルゴリズムは、グループサイズが増加している場合にユーザーがRTCPパケット送信を保留するようにする単純なバックオフメカニズムを実装します。
o When users leave a session, either with a BYE or by timeout, the group membership decreases, and thus the calculated interval should decrease. A "reverse reconsideration" algorithm is used to allow members to more quickly reduce their intervals in response to group membership decreases.
o BYEまたはタイムアウトにより、ユーザーがセッションを終了すると、グループメンバーシップが減少するため、計算される間隔が短くなります。 「逆再検討」アルゴリズムを使用して、グループメンバーシップの減少に応じてメンバーが間隔をより迅速に短縮できるようにします。
o BYE packets are given different treatment than other RTCP packets. When a user leaves a group, and wishes to send a BYE packet, it may do so before its next scheduled RTCP packet. However, transmission of BYEs follows a back-off algorithm which avoids floods of BYE packets should a large number of members simultaneously leave the session.
o BYEパケットには、他のRTCPパケットとは異なる処理が行われます。ユーザーがグループを離れ、BYEパケットを送信したい場合は、次にスケジュールされているRTCPパケットの前に送信することがあります。ただし、BYEの送信は、多数のメンバーが同時にセッションを離れた場合にBYEパケットのフラッドを回避するバックオフアルゴリズムに従います。
This algorithm may be used for sessions in which all participants are allowed to send. In that case, the session bandwidth parameter is the product of the individual sender's bandwidth times the number of participants, and the RTCP bandwidth is 5% of that.
このアルゴリズムは、すべての参加者が送信を許可されているセッションに使用できます。その場合、セッション帯域幅パラメーターは、個々の送信者の帯域幅に参加者の数を掛けた積であり、RTCP帯域幅はその5％です。
Details of the algorithm's operation are given in the sections that follow. Appendix A.7 gives an example implementation.
アルゴリズムの動作の詳細については、以下のセクションで説明します。付録A.7に実装例を示します。
6.2.1 Maintaining the Number of Session Members
6.2.1セッションメンバーの数の維持
Calculation of the RTCP packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each SHOULD be created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries MAY be considered not valid until multiple packets carrying the new SSRC have been received (see Appendix A.1), or until an SDES RTCP packet containing a CNAME for that SSRC has been received. Entries MAY be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received, except that some straggler data packets might arrive after the BYE and cause the entry to be recreated. Instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay.
RTCPパケット間隔の計算は、セッションに参加しているサイト数の見積もりに依存します。新しいサイトが聞こえたときにカウントに追加され、SSRCまたはCSRC識別子（セクション8.2を参照）によってインデックスが付けられたテーブルに各サイトのエントリが作成され、それらを追跡する必要があります（SHOULD）。新しいSSRCを運ぶ複数のパケットが受信されるまで（付録A.1を参照）、またはそのSSRCのCNAMEを含むSDES RTCPパケットが受信されるまで、新しいエントリは無効と見なされる場合があります。対応するSSRC識別子を持つRTCP BYEパケットを受信すると、エントリがテーブルから削除される場合があります。ただし、一部のストラグラーデータパケットがBYEの後に到着し、エントリが再作成される場合があります。代わりに、エントリはBYEを受信したものとしてマークし、適切な遅延の後に削除する必要があります（SHOULD）。
A participant MAY mark another site inactive, or delete it if not yet valid, if no RTP or RTCP packet has been received for a small number of RTCP report intervals (5 is RECOMMENDED). This provides some robustness against packet loss. All sites must have the same value for this multiplier and must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile.
少数のRTCPレポート間隔でRTPまたはRTCPパケットが受信されなかった場合（5が推奨）、参加者は別のサイトを非アクティブとしてマークするか、まだ有効でない場合は削除することができます（MAY）。これにより、パケット損失に対する堅牢性が提供されます。このタイムアウトが適切に機能するためには、すべてのサイトでこの乗数に同じ値を設定し、RTCPレポート間隔にほぼ同じ値を計算する必要があります。したがって、この乗数は特定のプロファイルに対して修正する必要があります。
For sessions with a very large number of participants, it may be impractical to maintain a table to store the SSRC identifier and state information for all of them. An implementation MAY use SSRC sampling, as described in [21], to reduce the storage requirements. An implementation MAY use any other algorithm with similar performance. A key requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate.
非常に多数の参加者とのセッションの場合、SSRC識別子とそのすべての状態情報を格納するテーブルを維持することは非現実的です。 [21]で説明されているように、実装はSSRCサンプリングを使用して、ストレージ要件を減らすことができます（MAY）。実装は、同様のパフォーマンスを持つ他のアルゴリズムを使用してもよい（MAY）。重要な要件は、考慮されるアルゴリズムはグループサイズを大幅に過小評価してはならない（SHOULD NOT）ことですが、過大評価する場合があります。
6.3 RTCP Packet Send and Receive Rules
6.3 RTCPパケット送受信ルール
The rules for how to send, and what to do when receiving an RTCP packet are outlined here. An implementation that allows operation in a multicast environment or a multipoint unicast environment MUST meet the requirements in Section 6.2. Such an implementation MAY use the algorithm defined in this section to meet those requirements, or MAY use some other algorithm so long as it provides equivalent or better performance. An implementation which is constrained to two-party unicast operation SHOULD still use randomization of the RTCP transmission interval to avoid unintended synchronization of multiple instances operating in the same environment, but MAY omit the "timer reconsideration" and "reverse reconsideration" algorithms in Sections 6.3.3, 6.3.6 and 6.3.7.
ここでは、RTCPパケットの送信方法と受信時のルールについて説明します。マルチキャスト環境またはマルチポイントユニキャスト環境での操作を可能にする実装は、セクション6.2の要件を満たしている必要があります。そのような実装は、これらの要件を満たすためにこのセクションで定義されたアルゴリズムを使用してもよいし、同等またはより優れたパフォーマンスを提供する限り、他のアルゴリズムを使用してもよい（MAY）。 2パーティのユニキャスト操作に制限された実装では、RTCP送信間隔のランダム化を引き続き使用して、同じ環境で動作する複数のインスタンスの意図しない同期を回避する必要がありますが、セクション6.3の「タイマーの再検討」および「逆再検討」アルゴリズムを省略してもかまいません（MAY）。 .3、6.3.6、および6.3.7。
To execute these rules, a session participant must maintain several pieces of state:
これらのルールを実行するには、セッション参加者はいくつかの状態を維持する必要があります。
tp: the last time an RTCP packet was transmitted;
tp：RTCPパケットが最後に送信された時間。
tc: the current time;
tc：現在の時刻。
tn: the next scheduled transmission time of an RTCP packet;
tn：RTCPパケットの次のスケジュールされた送信時間。
pmembers: the estimated number of session members at the time tn was last recomputed;
pmembers：tnが最後に再計算された時点の推定セッションメンバー数。
members: the most current estimate for the number of session members;
メンバー：セッションメンバー数の最新の見積もり。
senders: the most current estimate for the number of senders in the session;
送信者：セッションの送信者数の最新の見積もり。
rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth that will be used for RTCP packets by all members of this session, in octets per second. This will be a specified fraction of the "session bandwidth" parameter supplied to the application at startup.
rtcp_bw：ターゲットRTCP帯域幅、つまり、このセッションのすべてのメンバーがRTCPパケットに使用する合計帯域幅（オクテット/秒）。これは、起動時にアプリケーションに提供される「セッション帯域幅」パラメータの指定された部分になります。
we_sent: Flag that is true if the application has sent data since the 2nd previous RTCP report was transmitted.
we_sent：2つ前のRTCPレポートが送信されてからアプリケーションがデータを送信した場合にtrueになるフラグ。
avg_rtcp_size: The average compound RTCP packet size, in octets, over all RTCP packets sent and received by this participant. The size includes lower-layer transport and network protocol headers (e.g., UDP and IP) as explained in Section 6.2.
avg_rtcp_size：この参加者が送受信したすべてのRTCPパケットの平均複合RTCPパケットサイズ（オクテット単位）。セクション6.2で説明したように、サイズには下位層のトランスポートおよびネットワークプロトコルヘッダー（UDPやIPなど）が含まれます。
initial: Flag that is true if the application has not yet sent an RTCP packet.
initial：アプリケーションがまだRTCPパケットを送信していない場合にtrueになるフラグ。
Many of these rules make use of the "calculated interval" between packet transmissions. This interval is described in the following section.
これらのルールの多くは、パケット送信間の「計算された間隔」を利用しています。この間隔については、次のセクションで説明します。
6.3.1 Computing the RTCP Transmission Interval
6.3.1 RTCP送信間隔の計算
To maintain scalability, the average interval between packets from a session participant should scale with the group size. This interval is called the calculated interval. It is obtained by combining a number of the pieces of state described above. The calculated interval T is then determined as follows: 1. If the number of senders is less than or equal to 25% of the membership (members), the interval depends on whether the participant is a sender or not (based on the value of we_sent). If the participant is a sender (we_sent true), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by 25% of the RTCP bandwidth (rtcp_bw), and the constant n is set to the number of senders. If we_sent is not true, the constant C is set to the average RTCP packet size divided by 75% of the RTCP bandwidth. The constant n is set to the number of receivers (members - senders). If the number of senders is greater than 25%, senders and receivers are treated together. The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth and n is set to the total number of members. As stated in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth may be explicitly defined by two separate parameters (call them S and R) for those participants which are senders and those which are not. In that case, the 25% fraction becomes S/(S+R) and the 75% fraction becomes R/(S+R). Note that if R is zero, the percentage of senders is never greater than S/(S+R), and the implementation must avoid division by zero.
スケーラビリティを維持するには、セッション参加者からのパケット間の平均間隔をグループサイズに合わせて調整する必要があります。この間隔は、計算された間隔と呼ばれます。上記の状態をいくつか組み合わせて得られます。次に、計算された間隔Tは次のように決定されます。1.送信者の数がメンバーシップ（メンバー）の25％以下の場合、間隔は、参加者が送信者であるかどうかに依存します（の値に基づく） we_sent）。参加者が送信者である場合（we_sent true）、定数Cは平均RTCPパケットサイズ（avg_rtcp_size）をRTCP帯域幅（rtcp_bw）の25％で割った値に設定され、定数nは送信者の数に設定されます。 we_sentがtrueでない場合、定数Cは、RTCP帯域幅の75％で割った平均RTCPパケットサイズに設定されます。定数nは、受信者（メンバー-送信者）の数に設定されます。送信者の数が25％を超える場合、送信者と受信者は一緒に扱われます。定数Cは、平均RTCPパケットサイズを合計RTCP帯域幅で割った値に設定され、nはメンバーの総数に設定されます。セクション6.2で述べたように、RTPプロファイルは、RTCP帯域幅が、送信者である参加者とそうでない参加者の2つの別々のパラメーター（SおよびRと呼ぶ）によって明示的に定義されることを指定できます（MAY）。その場合、25％の割合はS /（S + R）になり、75％の割合はR /（S + R）になります。 Rがゼロの場合、送信者のパーセンテージがS /（S + R）を超えることはなく、実装ではゼロによる除算を回避する必要があることに注意してください。
2. If the participant has not yet sent an RTCP packet (the variable initial is true), the constant Tmin is set to 2.5 seconds, else it is set to 5 seconds.
2. 参加者がまだRTCPパケットを送信していない場合（変数の初期値はtrue）、定数Tminは2.5秒に設定され、それ以外の場合は5秒に設定されます。
3. The deterministic calculated interval Td is set to max(Tmin, n*C).
3. 決定論的に計算された間隔Tdはmax（Tmin、n * C）に設定されます。
4. The calculated interval T is set to a number uniformly distributed between 0.5 and 1.5 times the deterministic calculated interval.
4. 計算された間隔Tは、決定論的に計算された間隔の0.5倍から1.5倍の間で均一に分布する数に設定されます。
5. The resulting value of T is divided by e-3/2=1.21828 to compensate for the fact that the timer reconsideration algorithm converges to a value of the RTCP bandwidth below the intended average.
5. 結果のTの値はe-3 / 2 = 1.21828で除算され、タイマーの再検討アルゴリズムがRTCP帯域幅の値に意図された平均を下回る値に収束するという事実を補正します。
This procedure results in an interval which is random, but which, on average, gives at least 25% of the RTCP bandwidth to senders and the rest to receivers. If the senders constitute more than one quarter of the membership, this procedure splits the bandwidth equally among all participants, on average.
この手順の結果、ランダムな間隔になりますが、平均して、RTCP帯域幅の少なくとも25％が送信側に、残りが受信側に割り当てられます。送信者がメンバーシップの4分の1を超える場合、この手順では、平均してすべての参加者間で帯域幅を均等に分割します。
6.3.2 Initialization
6.3.2初期化
Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet that the application will later construct. The calculated interval T is then computed, and the first packet is scheduled for time tn = T. This means that a transmission timer is set which expires at time T. Note that an application MAY use any desired approach for implementing this timer.
セッションに参加すると、参加者はtpを0に、tcを0に、sendersを0に、pmembersを1に、membersを1に、we_sentをfalseに、rtcp_bwをセッション帯域幅の指定された割合に、initialをtrueに、avg_rtcp_sizeをアプリケーションが後で構築する最初のRTCPパケットの推定サイズ。次に、計算された間隔Tが計算され、最初のパケットが時間tn = Tにスケジュールされます。これは、時間Tで期限切れになる送信タイマーが設定されることを意味します。アプリケーションは、このタイマーを実装するために任意の望ましいアプローチを使用できます。
The participant adds its own SSRC to the member table.
参加者は、独自のSSRCをメンバーテーブルに追加します。
6.3.3 Receiving an RTP or Non-BYE RTCP Packet
6.3.3 RTPまたはBYE以外のRTCPパケットの受信
When an RTP or RTCP packet is received from a participant whose SSRC is not in the member table, the SSRC is added to the table, and the value for members is updated once the participant has been validated as described in Section 6.2.1. The same processing occurs for each CSRC in a validated RTP packet.
SSRCがメンバーテーブルにない参加者からRTPまたはRTCPパケットを受信すると、SSRCがテーブルに追加され、セクション6.2.1で説明されているように参加者が検証されると、メンバーの値が更新されます。検証されたRTPパケットの各CSRCに対して同じ処理が行われます。
When an RTP packet is received from a participant whose SSRC is not in the sender table, the SSRC is added to the table, and the value for senders is updated.
SSRCが送信者テーブルにない参加者からRTPパケットを受信すると、SSRCがテーブルに追加され、送信者の値が更新されます。
For each compound RTCP packet received, the value of avg_rtcp_size is updated:
受信した複合RTCPパケットごとに、avg_rtcp_sizeの値が更新されます。
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
where packet_size is the size of the RTCP packet just received.
ここで、packet_sizeは受信したRTCPパケットのサイズです。
6.3.4 Receiving an RTCP BYE Packet
6.3.4 RTCP BYEパケットの受信
Except as described in Section 6.3.7 for the case when an RTCP BYE is to be transmitted, if the received packet is an RTCP BYE packet, the SSRC is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. The SSRC is then checked against the sender table. If present, the entry is removed from the table, and the value for senders is updated.
RTCP BYEを送信する場合のセクション6.3.7で説明されている場合を除き、受信パケットがRTCP BYEパケットの場合、SSRCはメンバーテーブルと照合されます。存在する場合、エントリはテーブルから削除され、メンバーの値が更新されます。次に、SSRCが送信者テーブルに対してチェックされます。存在する場合、エントリはテーブルから削除され、送信者の値が更新されます。
Furthermore, to make the transmission rate of RTCP packets more adaptive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet is received that reduces members to a value less than pmembers:
さらに、RTCPパケットの伝送速度をグループメンバーシップの変更に適応させるために、BYEパケットを受信したときに、メンバーをpmembers未満の値に減らす次の「逆再検討」アルゴリズムを実行する必要があります。
o The value for tn is updated according to the following formula:
o tnの値は、次の式に従って更新されます。
tn = tc + (members/pmembers) * (tn - tc)
o The value for tp is updated according the following formula:
o tpの値は、次の式に従って更新されます。
tp = tc - (members/pmembers) * (tc - tp).
tp = tc-（メンバー/ pmembers）*（tc-tp）。
o The next RTCP packet is rescheduled for transmission at time tn, which is now earlier.
o 次のRTCPパケットは、現在より早い時刻tnでの送信用に再スケジュールされます。
o The value of pmembers is set equal to members.
o pmembersの値は、membersと等しく設定されます。
This algorithm does not prevent the group size estimate from incorrectly dropping to zero for a short time due to premature timeouts when most participants of a large session leave at once but some remain. The algorithm does make the estimate return to the correct value more rapidly. This situation is unusual enough and the consequences are sufficiently harmless that this problem is deemed only a secondary concern.
このアルゴリズムは、大規模なセッションのほとんどの参加者が一度に離れたが一部が残った場合の早期タイムアウトにより、グループサイズの見積もりが短時間で誤ってゼロに落ちることを防ぎません。アルゴリズムは、推定をより迅速に正しい値に戻します。この状況は非常に異常であり、結果はこの問題が二次的な懸念にすぎないと見なされるほど十分に無害です。
6.3.5 Timing Out an SSRC
6.3.5 SSRCのタイムアウト
At occasional intervals, the participant MUST check to see if any of the other participants time out. To do this, the participant computes the deterministic (without the randomization factor) calculated interval Td for a receiver, that is, with we_sent false. Any other session member who has not sent an RTP or RTCP packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) is timed out. This means that its SSRC is removed from the member list, and members is updated. A similar check is performed on the sender list. Any member on the sender list who has not sent an RTP packet since time tc - 2T (within the last two RTCP report intervals) is removed from the sender list, and senders is updated.
時折、参加者は他の参加者のいずれかがタイムアウトするかどうかを確認する必要があります。これを行うために、参加者は、レシーバーの決定的な（ランダム化係数なしで）計算された間隔Tdを計算します。つまり、we_sentをfalseにします。時間tc-MTd（Mはタイムアウト乗数であり、デフォルトは5）からRTPまたはRTCPパケットを送信していない他のセッションメンバーはタイムアウトになります。つまり、そのSSRCがメンバーリストから削除され、メンバーが更新されます。送信者リストでも同様のチェックが行われます。時間tc-2T（最後の2つのRTCPレポート間隔内）以降にRTPパケットを送信していない送信者リストのメンバーは送信者リストから削除され、送信者が更新されます。
If any members time out, the reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed.
メンバーがタイムアウトした場合は、6.3.4項で説明した逆再検討アルゴリズムを実行する必要があります。
The participant MUST perform this check at least once per RTCP transmission interval.
参加者は、RTCP送信間隔ごとに少なくとも1回このチェックを実行する必要があります。
6.3.6 Expiration of Transmission Timer
6.3.6送信タイマーの期限切れ
When the packet transmission timer expires, the participant performs the following operations:
パケット送信タイマーが切れると、参加者は次の操作を実行します。
o The transmission interval T is computed as described in Section 6.3.1, including the randomization factor.
o 送信間隔Tは、ランダム化係数を含め、セクション6.3.1で説明されているように計算されます。
o If tp + T is less than or equal to tc, an RTCP packet is transmitted. tp is set to tc, then another value for T is calculated as in the previous step and tn is set to tc + T. The transmission timer is set to expire again at time tn. If tp + T is greater than tc, tn is set to tp + T. No RTCP packet is transmitted. The transmission timer is set to expire at time tn.
o tp + Tがtc以下の場合、RTCPパケットが送信されます。 tpがtcに設定され、前の手順と同様にTの別の値が計算され、tnがtc + Tに設定されます。送信タイマーは、時刻tnに再び期限切れになるように設定されます。 tp + Tがtcより大きい場合、tnはtp + Tに設定されます。RTCPパケットは送信されません。送信タイマーは、時刻tnに満了するように設定されています。
o pmembers is set to members.
o pmembersはメンバーに設定されます。
If an RTCP packet is transmitted, the value of initial is set to FALSE. Furthermore, the value of avg_rtcp_size is updated:
RTCPパケットが送信される場合、initialの値はFALSEに設定されます。さらに、avg_rtcp_sizeの値が更新されます。
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
where packet_size is the size of the RTCP packet just transmitted.
ここで、packet_sizeは、送信されたばかりのRTCPパケットのサイズです。
6.3.7 Transmitting a BYE Packet
6.3.7 BYEパケットの送信
When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. In order to avoid a flood of BYE packets when many participants leave the system, a participant MUST execute the following algorithm if the number of members is more than 50 when the participant chooses to leave. This algorithm usurps the normal role of the members variable to count BYE packets instead:
参加者がセッションを離れたい場合、BYEパケットが送信され、他の参加者にイベントを通知します。多くの参加者がシステムを離れるときにBYEパケットのフラッドを回避するために、参加者が離れることを選択したときにメンバー数が50を超える場合、参加者は次のアルゴリズムを実行する必要があります。このアルゴリズムは、代わりにBYEパケットをカウントするためにメンバー変数の通常の役割を奪います：
o When the participant decides to leave the system, tp is reset to tc, the current time, members and pmembers are initialized to 1, initial is set to 1, we_sent is set to false, senders is set to 0, and avg_rtcp_size is set to the size of the compound BYE packet. The calculated interval T is computed. The BYE packet is then scheduled for time tn = tc + T.
o 参加者がシステムを離れることを決定すると、tpはtcにリセットされ、現在の時刻、メンバーおよびpmembersは1に初期化され、initialは1に設定され、we_sentはfalseに設定され、sendersは0に設定され、avg_rtcp_sizeは複合BYEパケットのサイズ。計算された間隔Tが計算されます。次に、BYEパケットは時間tn = tc + Tにスケジュールされます。
o Every time a BYE packet from another participant is received, members is incremented by 1 regardless of whether that participant exists in the member table or not, and when SSRC sampling is in use, regardless of whether or not the BYE SSRC would be included in the sample. members is NOT incremented when other RTCP packets or RTP packets are received, but only for BYE packets. Similarly, avg_rtcp_size is updated only for received BYE packets. senders is NOT updated when RTP packets arrive; it remains 0.
o 別の参加者からのBYEパケットを受信するたびに、その参加者がメンバーテーブルに存在するかどうかに関係なく、メンバーは1ずつ増加し、SSRCサンプリングが使用されている場合は、BYE SSRCが含まれるかどうかに関係なくサンプル。他のRTCPパケットまたはRTPパケットが受信された場合、メンバーは増加しませんが、BYEパケットの場合のみです。同様に、avg_rtcp_sizeは、受信したBYEパケットに対してのみ更新されます。 RTPパケットが到着しても送信者は更新されません。 0のままです。
o Transmission of the BYE packet then follows the rules for transmitting a regular RTCP packet, as above.
o BYEパケットの送信は、上記のように通常のRTCPパケットを送信するためのルールに従います。
This allows BYE packets to be sent right away, yet controls their total bandwidth usage. In the worst case, this could cause RTCP control packets to use twice the bandwidth as normal (10%) -- 5% for non-BYE RTCP packets and 5% for BYE.
これにより、BYEパケットをすぐに送信しながら、帯域幅の総使用量を制御できます。最悪の場合、これによりRTCP制御パケットが通常の2倍の帯域幅（10％）を使用する可能性があります-非BYE RTCPパケットの場合は5％、BYEの場合は5％。
A participant that does not want to wait for the above mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members.
上記のメカニズムがBYEパケットの送信を許可するのを待たない参加者は、BYEをまったく送信せずにグループを去ることができます。その参加者は、最終的に他のグループメンバーによってタイムアウトになります。
If the group size estimate members is less than 50 when the participant decides to leave, the participant MAY send a BYE packet immediately. Alternatively, the participant MAY choose to execute the above BYE backoff algorithm.
参加者が脱退することを決定したときにグループサイズの推定メンバーが50未満の場合、参加者はBYEパケットをすぐに送信できます（MAY）。あるいは、参加者は上記のBYEバックオフアルゴリズムを実行することを選択できます。
In either case, a participant which never sent an RTP or RTCP packet MUST NOT send a BYE packet when they leave the group.
どちらの場合も、RTPまたはRTCPパケットを送信したことがない参加者は、グループを離れるときにBYEパケットを送信してはなりません（MUST NOT）。
6.3.8 Updating we_sent
6.3.8 we_sentの更新
The variable we_sent contains true if the participant has sent an RTP packet recently, false otherwise. This determination is made by using the same mechanisms as for managing the set of other participants listed in the senders table. If the participant sends an RTP packet when we_sent is false, it adds itself to the sender table and sets we_sent to true. The reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed to possibly reduce the delay before sending an SR packet. Every time another RTP packet is sent, the time of transmission of that packet is maintained in the table. The normal sender timeout algorithm is then applied to the participant -- if an RTP packet has not been transmitted since time tc - 2T, the participant removes itself from the sender table, decrements the sender count, and sets we_sent to false.
変数we_sentには、参加者が最近RTPパケットを送信した場合はtrue、それ以外の場合はfalseが含まれます。この決定は、送信者テーブルにリストされている他の参加者のセットを管理する場合と同じメカニズムを使用して行われます。参加者がwe_sentがfalseのときにRTPパケットを送信すると、それ自体が送信者テーブルに追加され、we_sentがtrueに設定されます。 SRパケットを送信する前に、セクション6.3.4で説明されている逆再検討アルゴリズムを実行して、遅延をおそらく減らす必要があります。別のRTPパケットが送信されるたびに、そのパケットの送信時刻がテーブルに保持されます。次に、通常の送信者タイムアウトアルゴリズムが参加者に適用されます。RTCパケットが時間tc-2T以降送信されていない場合、参加者は送信者テーブルから自身を削除し、送信者カウントをデクリメントして、we_sentをfalseに設定します。
6.3.9 Allocation of Source Description Bandwidth
6.3.9ソース記述帯域幅の割り当て
This specification defines several source description (SDES) items in addition to the mandatory CNAME item, such as NAME (personal name) and EMAIL (email address). It also provides a means to define new application-specific RTCP packet types. Applications should exercise caution in allocating control bandwidth to this additional information because it will slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. It is RECOMMENDED that no more than 20% of the RTCP bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all SDES items will be included in every application. Those that are included SHOULD be assigned a fraction of the bandwidth according to their utility. Rather than estimate these fractions dynamically, it is recommended that the percentages be translated statically into report interval counts based on the typical length of an item.
この仕様では、必須のCNAMEアイテムに加えて、NAME（個人名）やEMAIL（メールアドレス）など、いくつかのソース記述（SDES）アイテムが定義されています。また、新しいアプリケーション固有のRTCPパケットタイプを定義する手段も提供します。受信レポートとCNAMEが送信される速度が遅くなり、プロトコルのパフォーマンスが低下するため、アプリケーションはこの追加情報に制御帯域幅を割り当てる際には注意が必要です。 1人の参加者に割り当てられたRTCP帯域幅の20％以下が追加情報を運ぶために使用されることが推奨されます。さらに、すべてのSDESアイテムがすべてのアプリケーションに含まれることは意図されていません。含まれているものには、そのユーティリティに従って帯域幅の一部を割り当てる必要があります（SHOULD）。これらの割合を動的に推定するのではなく、パーセンテージをアイテムの一般的な長さに基づいてレポート間隔カウントに静的に変換することをお勧めします。
For example, an application may be designed to send only CNAME, NAME and EMAIL and not any others. NAME might be given much higher priority than EMAIL because the NAME would be displayed continuously in the application's user interface, whereas EMAIL would be displayed only when requested. At every RTCP interval, an RR packet and an SDES packet with the CNAME item would be sent. For a small session operating at the minimum interval, that would be every 5 seconds on the average. Every third interval (15 seconds), one extra item would be included in the SDES packet. Seven out of eight times this would be the NAME item, and every eighth time (2 minutes) it would be the EMAIL item.
たとえば、アプリケーションはCNAME、NAME、およびEMAILのみを送信し、その他は送信しないように設計されている場合があります。 NAMEはアプリケーションのユーザーインターフェイスに継続的に表示されるため、EMAILよりもはるかに高い優先度が与えられる可能性がありますが、EMAILは要求された場合にのみ表示されます。すべてのRTCP間隔で、CNAMEアイテムを含むRRパケットとSDESパケットが送信されます。最小間隔で動作する小さなセッションの場合、平均して5秒ごとになります。 3番目の間隔（15秒）ごとに、1つの追加項目がSDESパケットに含まれます。 8回のうち7回はNAMEアイテムで、8回（2分）ごとにEMAILアイテムになります。
When multiple applications operate in concert using cross-application binding through a common CNAME for each participant, for example in a multimedia conference composed of an RTP session for each medium, the additional SDES information MAY be sent in only one RTP session. The other sessions would carry only the CNAME item. In particular, this approach should be applied to the multiple sessions of a layered encoding scheme (see Section 2.4).
各メディアのRTPセッションで構成されるマルチメディア会議など、参加者ごとに共通のCNAMEを介したクロスアプリケーションバインディングを使用して複数のアプリケーションが協調して動作する場合、追加のSDES情報は1つのRTPセッションでのみ送信される場合があります。他のセッションはCNAMEアイテムのみを扱います。特に、このアプローチは、レイヤードエンコーディングスキームの複数のセッションに適用する必要があります（セクション2.4を参照）。
6.4 Sender and Receiver Reports
6.4送信者および受信者レポート
RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.
RTPレシーバーは、レシーバーがセンダーでもあるかどうかに応じて、2つの形式のいずれかをとることができるRTCPレポートパケットを使用して、受信品質フィードバックを提供します。パケットタイプコードを除いて、送信者レポート（SR）フォームと受信者レポート（RR）フォームの唯一の違いは、送信者レポートにアクティブな送信者が使用する20バイトの送信者情報セクションが含まれていることです。最後のレポートまたは前回のレポートを発行してから、インターバル中にサイトがデータパケットを送信した場合、SRが発行されます。それ以外の場合、RRが発行されます。
Both the SR and RR forms include zero or more reception report blocks, one for each of the synchronization sources from which this receiver has received RTP data packets since the last report. Reports are not issued for contributing sources listed in the CSRC list. Each reception report block provides statistics about the data received from the particular source indicated in that block. Since a maximum of 31 reception report blocks will fit in an SR or RR packet, additional RR packets SHOULD be stacked after the initial SR or RR packet as needed to contain the reception reports for all sources heard during the interval since the last report. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the MTU of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
SRとRRの両方の形式には、0個以上の受信レポートブロックが含まれます。最後のレポート以降、このレシーバーがRTPデータパケットを受信した同期ソースごとに1つずつあります。 CSRCリストにリストされている貢献元についてのレポートは発行されません。各受信レポートブロックは、そのブロックに示されている特定のソースから受信したデータに関する統計を提供します。最大31の受信レポートブロックがSRパケットまたはRRパケットに収まるため、最後のレポート以降のインターバル中に聞いたすべてのソースの受信レポートを含めるために、必要に応じて追加のRRパケットを最初のSRまたはRRパケットの後にスタックする必要があります。ソースが多すぎてネットワークパスのMTUを超えずに必要なすべてのRRパケットを1つの複合RTCPパケットに収められない場合、1つのMTUに適合するサブセットのみを各間隔に含める必要があります（SHOULD）。すべてのソースが報告されるように、サブセットは複数の間隔でラウンドロビンで選択する必要があります（SHOULD）。
The next sections define the formats of the two reports, how they may be extended in a profile-specific manner if an application requires additional feedback information, and how the reports may be used. Details of reception reporting by translators and mixers is given in Section 7.
次のセクションでは、2つのレポートの形式、アプリケーションが追加のフィードバック情報を必要とする場合にプロファイル固有の方法で拡張する方法、およびレポートの使用方法を定義します。翻訳者とミキサーによるレセプションレポートの詳細については、セクション7を参照してください。
6.4.1 SR: Sender Report RTCP Packet
6.4.1 SR：送信者レポートRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly followed by a fourth profile-specific extension section if defined. The first section, the header, is 8 octets long. The fields have the following meaning:
送信者レポートパケットは3つのセクションで構成され、定義されている場合は、4番目のプロファイル固有の拡張セクションが後に続く場合があります。最初のセクションであるヘッダーは、8オクテットの長さです。フィールドの意味は次のとおりです。
version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2).
バージョン（V）：2ビットRTPのバージョンを示します。これは、RTPパケットとRTPデータパケットで同じです。この仕様で定義されているバージョンは2です。
padding (P): 1 bit If the padding bit is set, this individual RTCP packet contains some additional padding octets at the end which are not part of the control information but are included in the length field. The last octet of the padding is a count of how many padding octets should be ignored, including itself (it will be a multiple of four). Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding is only required on one individual packet because the compound packet is encrypted as a whole for the method in Section 9.1. Thus, padding MUST only be added to the last individual packet, and if padding is added to that packet, the padding bit MUST be set only on that packet. This convention aids the header validity checks described in Appendix A.2 and allows detection of packets from some early implementations that incorrectly set the padding bit on the first individual packet and add padding to the last individual packet.
パディング（P）：1ビットパディングビットが設定されている場合、この個別のRTCPパケットには、制御情報の一部ではないが長さフィールドに含まれる追加のパディングオクテットが最後に含まれます。パディングの最後のオクテットは、無視されるパディングオクテットの数で、それ自体も含まれます（4の倍数になります）。固定ブロックサイズの一部の暗号化アルゴリズムでは、パディングが必要になる場合があります。複合RTCPパケットでは、複合パケットはセクション9.1の方法で全体として暗号化されるため、パディングは1つの個別のパケットでのみ必要です。したがって、パディングは最後の個々のパケットにのみ追加する必要があり、パディングがそのパケットに追加される場合、パディングビットはそのパケットにのみ設定する必要があります。この規則は、付録A.2で説明されているヘッダー有効性チェックを支援し、最初の個別パケットにパディングビットを誤って設定し、最後の個別パケットにパディングを追加する初期の実装からのパケットを検出できるようにします。
reception report count (RC): 5 bits The number of reception report blocks contained in this packet. A value of zero is valid.
受信レポートカウント（RC）：5ビットこのパケットに含まれる受信レポートブロックの数。ゼロの値が有効です。
packet type (PT): 8 bits Contains the constant 200 to identify this as an RTCP SR packet.
パケットタイプ（PT）：8ビットこれをRTCP SRパケットとして識別する定数200が含まれています。
length: 16 bits The length of this RTCP packet in 32-bit words minus one, including the header and any padding. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.)
長さ：16ビット32ビットワードから1を引いたこのRTCPパケットの長さ（ヘッダーとすべてのパディングを含む）。 （オフセットが1の場合、ゼロが有効な長さとなり、複合RTCPパケットのスキャンで無限ループが発生する可能性がなくなります。32ビットワードをカウントすると、4の倍数の有効性チェックが回避されます。）
SSRC: 32 bits The synchronization source identifier for the originator of this SR packet.
SSRC：32ビットこのSRパケットの発信元の同期ソース識別子。
The second section, the sender information, is 20 octets long and is present in every sender report packet. It summarizes the data transmissions from this sender. The fields have the following meaning:
2番目のセクションである送信者情報は20オクテット長であり、すべての送信者レポートパケットに存在します。この送信者からのデータ送信を要約します。フィールドの意味は次のとおりです。
NTP timestamp: 64 bits Indicates the wallclock time (see Section 4) when this report was sent so that it may be used in combination with timestamps returned in reception reports from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. On a system that has no notion of wallclock time but does have some system-specific clock such as "system uptime", a sender MAY use that clock as a reference to calculate relative NTP timestamps. It is important to choose a commonly used clock so that if separate implementations are used to produce the individual streams of a multimedia session, all implementations will use the same clock. Until the year 2036, relative and absolute timestamps will differ in the high bit so (invalid) comparisons will show a large difference; by then one hopes relative timestamps will no longer be needed. A sender that has no notion of wallclock or elapsed time MAY set the NTP timestamp to zero.
NTPタイムスタンプ：64ビットこのレポートが送信されたときの実時間（セクション4を参照）を示し、他の受信者からの受信レポートで返されるタイムスタンプと組み合わせて、それらの受信者への往復伝搬を測定できるようにします。受信者は、タイムスタンプの測定精度がNTPタイムスタンプの解像度よりもはるかに低く制限される可能性があることを期待する必要があります。タイムスタンプの測定の不確実性は、不明な場合があるため示されていません。ウォールクロック時間の概念はないが、「システム稼働時間」などのシステム固有のクロックがあるシステムでは、送信者はそのクロックを参照として使用して、相対NTPタイムスタンプを計算できます。マルチメディアセッションの個々のストリームを生成するために個別の実装が使用される場合、すべての実装が同じクロックを使用するように、一般的に使用されるクロックを選択することが重要です。 2036年までは、相対タイムスタンプと絶対タイムスタンプの上位ビットが異なるため、（無効な）比較では大きな違いが示されます。それまでに、相対タイムスタンプが不要になることを期待しています。ウォールクロックや経過時間の概念がない送信者は、NTPタイムスタンプをゼロに設定してもよい（MAY）。
RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it MUST be calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant.
RTPタイムスタンプ：32ビットNTPタイムスタンプ（上記）と同じ時刻に対応しますが、データパケットのRTPタイムスタンプと同じ単位で同じランダムオフセットを使用します。この対応は、NTPタイムスタンプが同期されるソースのメディア内およびメディア間同期に使用でき、公称RTPクロック周波数を推定するためにメディアに依存しない受信者が使用できます。ほとんどの場合、このタイムスタンプは隣接するデータパケットのRTPタイムスタンプと等しくないことに注意してください。むしろ、RTPタイムスタンプカウンターとリアルタイムの関係を使用して、対応するNTPタイムスタンプから計算される必要があります。サンプリングの瞬間にウォールクロック時間を定期的にチェックすることで維持されます。
sender's packet count: 32 bits The total number of RTP data packets transmitted by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier.
送信者のパケット数：32ビット送信を開始してからこのSRパケットが生成されるまでに送信者が送信したRTPデータパケットの総数。送信者がSSRC識別子を変更した場合、カウントをリセットする必要があります（SHOULD）。
sender's octet count: 32 bits The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier. This field can be used to estimate the average payload data rate.
送信者のオクテット数：32ビットこのSRパケットが生成されるまで送信を開始してから、送信者がRTPデータパケットで送信したペイロードオクテット（ヘッダーまたはパディングを含まない）の総数。送信者がSSRC識別子を変更した場合、カウントをリセットする必要があります（SHOULD）。このフィールドは、平均ペイロードデータレートを推定するために使用できます。
The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Receivers SHOULD NOT carry over statistics when a source changes its SSRC identifier due to a collision. These statistics are: SSRC_n (source identifier): 32 bits The SSRC identifier of the source to which the information in this reception report block pertains.
3番目のセクションには、最後のレポート以降にこの送信者が聞いた他のソースの数に応じて、0個以上の受信レポートブロックが含まれます。各受信レポートブロックは、単一の同期ソースからのRTPパケットの受信に関する統計を伝えます。衝突のためにソースがSSRC識別子を変更した場合、受信者は統計を引き継がないでください。これらの統計は次のとおりです。SSRC_n（ソース識別子）：32ビットこの受信レポートブロックの情報が関係するソースのSSRC識別子。
fraction lost: 8 bits The fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.) This fraction is defined to be the number of packets lost divided by the number of packets expected, as defined in the next paragraph. An implementation is shown in Appendix A.3. If the loss is negative due to duplicates, the fraction lost is set to zero. Note that a receiver cannot tell whether any packets were lost after the last one received, and that there will be no reception report block issued for a source if all packets from that source sent during the last reporting interval have been lost.
失われた割合：8ビット前のSRまたはRRパケットが送信されてからソースSSRC_nから失われたRTPデータパケットの割合。フィールドの左端に2進小数点がある固定小数点数として表されます。 （これは、損失部分に256を掛けた後の整数部分を取ることと同じです。）この部分は、次の段落で定義するように、失われたパケット数を予期されるパケット数で割ったものとして定義されます。実装は付録A.3に示されています。重複により損失が負の場合、損失率はゼロに設定されます。受信側は、最後のパケットが受信された後にパケットが失われたかどうかを判別できず、最後のレポート間隔中に送信されたそのソースからのパケットがすべて失われた場合、ソースに対して発行された受信レポートブロックがないことに注意してください。
cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3.
失われたパケットの累積数：24ビット受信の開始以降に失われた、ソースSSRC_nからのRTPデータパケットの総数。この数は、予想されるパケット数から実際に受信されたパケット数を差し引いた数として定義されます。受信されたパケット数には、遅延または重複したパケットが含まれます。したがって、遅れて到着するパケットは損失としてカウントされず、重複がある場合、損失は負になる可能性があります。予期されるパケット数は、次に定義されるように、受信された拡張された最後のシーケンス番号から、受信された最初のシーケンス番号を差し引いたものとして定義されます。これは、付録A.3に示すように計算できます。
extended highest sequence number received: 32 bits The low 16 bits contain the highest sequence number received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which may be maintained according to the algorithm in Appendix A.1. Note that different receivers within the same session will generate different extensions to the sequence number if their start times differ significantly.
受信した拡張最大シーケンス番号：32ビット下位16ビットには、ソースSSRC_nからRTPデータパケットで受信した最大シーケンス番号が含まれ、最上位16ビットは、シーケンス番号サイクルの対応するカウントでそのシーケンス番号を拡張します。付録A.1のアルゴリズムに従って。同じセッション内の異なるレシーバーは、開始時刻が大幅に異なる場合、シーケンス番号に異なる拡張子を生成することに注意してください。
interarrival jitter: 32 bits An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets;
到着間ジッター：32ビットタイムスタンプ単位で測定され、符号なし整数として表される、RTPデータパケットの到着間時間の統計的変動の推定値。到着間ジッタJは、パケットのペアの送信側と比較した受信側のパケット間隔の差Dの平均偏差（平滑化された絶対値）として定義されます。次の式に示すように、これは2つのパケットの「相対通過時間」の差に相当します。
the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units.
相対通過時間は、パケットのRTPタイムスタンプと到着時のレシーバーのクロックとの差であり、同じ単位で測定されます。
If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as
SiがパケットiからのRTPタイムスタンプであり、RiがパケットiのRTPタイムスタンプ単位での到着時間である場合、2つのパケットiおよびjの場合、Dは次のように表されます。
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula
次の式に従って、各データパケットiがソースSSRC_nから受信されたときに、到着順ジッターを連続して計算する必要があります（SHOULD）。
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
Whenever a reception report is issued, the current value of J is sampled.
受信レポートが発行されるたびに、Jの現在の値がサンプリングされます。
The jitter calculation MUST conform to the formula specified here in order to allow profile-independent monitors to make valid interpretations of reports coming from different implementations. This algorithm is the optimal first-order estimator and the gain parameter 1/16 gives a good noise reduction ratio while maintaining a reasonable rate of convergence [22]. A sample implementation is shown in Appendix A.8. See Section 6.4.4 for a discussion of the effects of varying packet duration and delay before transmission.
ジッターの計算は、プロファイルに依存しないモニターがさまざまな実装からのレポートを有効に解釈できるようにするために、ここで指定された式に準拠する必要があります。このアルゴリズムは最適な1次推定量であり、ゲインパラメーター1/16は、妥当な収束率を維持しながら良好なノイズ低減率を提供します[22]。実装例を付録A.8に示します。パケットの持続時間と送信前の遅延の影響については、6.4.4項を参照してください。
last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in Section 4) received as part of the most recent RTCP sender report (SR) packet from source SSRC_n. If no SR has been received yet, the field is set to zero.
最後のSRタイムスタンプ（LSR）：32ビットソースSSRC_nから最新のRTCP送信者レポート（SR）パケットの一部として受信されたNTPタイムスタンプ（セクション4で説明）の64のうちの中間の32ビット。 SRがまだ受信されていない場合、フィールドはゼロに設定されます。
delay since last SR (DLSR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last SR packet from source SSRC_n and sending this reception report block. If no SR packet has been received yet from SSRC_n, the DLSR field is set to zero.
最後のSRからの遅延（DLSR）：32ビットソースSSRC_nから最後のSRパケットを受信してからこの受信レポートブロックを送信するまでの遅延（1/65536秒単位）。 SRRCパケットがSSRC_nからまだ受信されていない場合、DLSRフィールドはゼロに設定されます。
Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this reception report block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as (A - LSR - DLSR). This is illustrated in Fig. 2. Times are shown in both a hexadecimal representation of the 32-bit fields and the equivalent floating-point decimal representation. Colons indicate a 32-bit field divided into a 16-bit integer part and 16-bit fraction part.
SSRC_rに、このレシーバーレポートを発行するレシーバーを示します。ソースSSRC_nは、この受信レポートブロックが受信された時間Aを記録することにより、SSRC_rへの往復伝播遅延を計算できます。最後のSRタイムスタンプ（LSR）フィールドを使用して合計往復時間A-LSRを計算し、このフィールドを差し引いて往復伝搬遅延を（A-LSR-DLSR）のままにします。これを図2に示します。時間は、32ビットフィールドの16進表記と、同等の浮動小数点10進表記の両方で表示されます。コロンは、16ビット整数部分と16ビット小数部分に分割された32ビットフィールドを示します。
This may be used as an approximate measure of distance to cluster receivers, although some links have very asymmetric delays.
一部のリンクには非常に非対称的な遅延がありますが、これはクラスターレシーバーまでの距離のおおよその目安として使用できます。
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992005.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
図2：往復時間の計算例
6.4.2 RR: Receiver Report RTCP Packet
6.4.2 RR：受信者レポートRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the receiver report (RR) packet is the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted (these are the NTP and RTP timestamps and sender's packet and octet counts). The remaining fields have the same meaning as for the SR packet.
レシーバーレポート（RR）パケットのフォーマットは、パケットタイプフィールドに定数201が含まれ、送信者情報の5ワードが省略されていることを除いて、SRパケットのフォーマットと同じです（NTPとRTPのタイムスタンプと送信者のパケットとオクテット数）。残りのフィールドは、SRパケットと同じ意味です。
An empty RR packet (RC = 0) MUST be put at the head of a compound RTCP packet when there is no data transmission or reception to report.
レポートするデータの送受信がない場合は、空のRRパケット（RC = 0）を複合RTCPパケットの先頭に配置する必要があります。
6.4.3 Extending the Sender and Receiver Reports
6.4.3送信者および受信者レポートの拡張
A profile SHOULD define profile-specific extensions to the sender report and receiver report if there is additional information that needs to be reported regularly about the sender or receivers. This method SHOULD be used in preference to defining another RTCP packet type because it requires less overhead:
送信者または受信者について定期的に報告する必要がある追加情報がある場合、プロファイルは送信者レポートと受信者レポートのプロファイル固有の拡張を定義する必要があります（SHOULD）。このメソッドは、オーバーヘッドが少ないため、別のRTCPパケットタイプを定義するよりも優先して使用する必要があります。
o fewer octets in the packet (no RTCP header or SSRC field);
o パケット内のオクテットが少ない（RTCPヘッダーまたはSSRCフィールドがない）。
o simpler and faster parsing because applications running under that profile would be programmed to always expect the extension fields in the directly accessible location after the reception reports.
o そのプロファイルの下で実行されているアプリケーションは、受信レポート後に直接アクセス可能な場所にある拡張フィールドを常に期待するようにプログラムされるため、解析がよりシンプルで高速になります。
The extension is a fourth section in the sender- or receiver-report packet which comes at the end after the reception report blocks, if any. If additional sender information is required, then for sender reports it would be included first in the extension section, but for receiver reports it would not be present. If information about receivers is to be included, that data SHOULD be structured as an array of blocks parallel to the existing array of reception report blocks; that is, the number of blocks would be indicated by the RC field.
拡張子は、受信レポートがブロックされた後、最後に来る送信者または受信者レポートパケットの4番目のセクションです。追加の送信者情報が必要な場合、送信者レポートの場合は最初に拡張セクションに含まれますが、受信者レポートの場合は存在しません。受信者に関する情報を含める場合、そのデータは、既存の受信レポートブロックの配列に平行なブロックの配列として構造化する必要があります（SHOULD）。つまり、ブロックの数はRCフィールドで示されます。
6.4.4 Analyzing Sender and Receiver Reports
6.4.4送信者および受信者レポートの分析
It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution.
受信品質のフィードバックは、送信者だけでなく、他の受信者やサードパーティのモニターにも役立つことが期待されています。送信者はフィードバックに基づいて送信を変更できます。レシーバーは、問題がローカル、リージョナル、グローバルのいずれであるかを判断できます。ネットワーク管理者は、対応するRTPデータパケットではなくRTCPパケットのみを受信するプロファイルに依存しないモニターを使用して、マルチキャスト配信用のネットワークのパフォーマンスを評価できます。
Cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors.
送信者情報ブロックと受信者レポートブロックの両方で累積カウントが使用されるため、任意の2つのレポート間の差異を計算して、短期と長期の両方で測定を行い、レポートの損失に対する回復力を提供できます。受信した最後の2つのレポートの違いを使用して、最近の分布の質を推定できます。 NTPタイムスタンプが含まれているため、2つのレポートの間隔でこれらの差からレートを計算できます。そのタイムスタンプはデータエンコーディングのクロックレートに依存しないため、エンコーディングおよびプロファイルに依存しない品質モニターを実装することが可能です。
An example calculation is the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of these two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of packets expected may also be used to judge the statistical validity of any loss estimates. For example, 1 out of 5 packets lost has a lower significance than 200 out of 1000.
計算例としては、2つの受信レポート間のインターバルにおけるパケット損失率があります。失われたパケットの累積数の違いは、その間隔中に失われた数を示します。受信した拡張最後のシーケンス番号の違いにより、間隔中に予想されるパケット数がわかります。これら2つの比率は、インターバルにおけるパケット損失率です。 2つのレポートが連続している場合、この比率は損失率フィールドと等しくなるはずですが、そうでない場合はそうではありません。 1秒あたりの損失率は、損失率を秒単位で表したNTPタイムスタンプの差で割ることで取得できます。受信したパケット数は、予想されるパケット数から失われた数を引いたものです。予想されるパケット数は、損失推定の統計的妥当性を判断するためにも使用できます。たとえば、失われた5パケットのうち1パケットは、1000パケットのうち200パケットよりも重要度が低くなります。
From the sender information, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval without receiving the data. Taking the ratio of the two gives the average payload size. If it can be assumed that packet loss is independent of packet size, then the number of packets received by a particular receiver times the average payload size (or the corresponding packet size) gives the apparent throughput available to that receiver.
サードパーティのモニターは、送信者情報から、データを受信せずに、ある間隔での平均ペイロードデータレートと平均パケットレートを計算できます。 2つの比率をとると、平均ペイロードサイズがわかります。パケット損失がパケットサイズに依存しないと想定できる場合、特定のレシーバーが受信したパケット数に平均ペイロードサイズ（または対応するパケットサイズ）を掛けると、そのレシーバーで利用できる見かけのスループットが得られます。
In addition to the cumulative counts which allow long-term packet loss measurements using differences between reports, the fraction lost field provides a short-term measurement from a single report. This becomes more important as the size of a session scales up enough that reception state information might not be kept for all receivers or the interval between reports becomes long enough that only one report might have been received from a particular receiver.
レポート間の差異を使用して長期間のパケット損失測定を可能にする累積カウントに加えて、フラクションロスフィールドは、単一のレポートからの短期測定を提供します。これは、セッションのサイズが大きくなり、すべてのレシーバーの受信状態情報が保持されない場合や、レポート間の間隔が長くなりすぎて、特定のレシーバーから1つのレポートしか受信されなかった場合に重要になります。
The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively. Rather, it is intended for comparison across a number of reports from one receiver over time or from multiple receivers, e.g., within a single network, at the same time. To allow comparison across receivers, it is important the the jitter be calculated according to the same formula by all receivers.
到着間ジッタフィールドは、ネットワークの輻輳の2番目の短期的な測定値を提供します。パケット損失は持続的な輻輳を追跡し、ジッター測定は一時的な輻輳を追跡します。ジッタ測定は、パケット損失につながる前に輻輳を示す場合があります。到着間ジッタフィールドは、レポート時のジッタのスナップショットにすぎず、定量的に取得することを意図したものではありません。むしろ、これは、1つの受信機からの複数のレポート、または単一のネットワーク内などの複数の受信機からの複数のレポートを同時に比較することを目的としています。レシーバー間で比較できるようにするには、すべてのレシーバーが同じ式に従ってジッターを計算することが重要です。
Because the jitter calculation is based on the RTP timestamp which represents the instant when the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated. Such a variation in delay would occur for audio packets of varying duration. It will also occur for video encodings because the timestamp is the same for all the packets of one frame but those packets are not all transmitted at the same time. The variation in delay until transmission does reduce the accuracy of the jitter calculation as a measure of the behavior of the network by itself, but it is appropriate to include considering that the receiver buffer must accommodate it. When the jitter calculation is used as a comparative measure, the (constant) component due to variation in delay until transmission subtracts out so that a change in the network jitter component can then be observed unless it is relatively small. If the change is small, then it is likely to be inconsequential.
ジッタの計算は、パケットの最初のデータがサンプリングされた瞬間を表すRTPタイムスタンプに基づいているため、そのサンプリングの瞬間とパケットが送信される時間との間の遅延の変動は、計算されるジッタに影響します。このような遅延の変動は、さまざまな期間のオーディオパケットで発生します。また、タイムスタンプは1つのフレームのすべてのパケットで同じですが、それらのパケットがすべて同時に送信されるわけではないため、ビデオエンコーディングでも発生します。送信までの遅延の変動は、それ自体でネットワークの動作の尺度としてのジッター計算の精度を低下させますが、レシーバーバッファーがそれを収容する必要があることを考慮することを含めることは適切です。ジッタの計算を比較指標として使用する場合、伝送が差し引かれるまでの遅延の変動による（一定の）成分が差し引かれるので、ネットワークジッタ成分の変化は、比較的小さい場合を除いて観測できます。変化が小さい場合、それは重要ではない可能性があります。
6.5 SDES: Source Description RTCP Packet
6.5 SDES：ソース記述RTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections.
SDESパケットは、ヘッダーと0個以上のチャンクで構成される3レベルの構造であり、各チャンクは、そのチャンクで識別されたソースを説明するアイテムで構成されています。項目については、以降のセクションで個別に説明します。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
バージョン（V）、パディング（P）、長さ：SRパケットについて説明したとおり（セクション6.4.1を参照）。
packet type (PT): 8 bits Contains the constant 202 to identify this as an RTCP SDES packet.
パケットタイプ（PT）：8ビットこれをRTCP SDESパケットとして識別する定数202が含まれています。
source count (SC): 5 bits The number of SSRC/CSRC chunks contained in this SDES packet. A value of zero is valid but useless.
ソースカウント（SC）：5ビットこのSDESパケットに含まれるSSRC / CSRCチャンクの数。ゼロの値は有効ですが、役に立ちません。
Each chunk consists of an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. Each chunk starts on a 32-bit boundary. Each item consists of an 8- bit type field, an 8-bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP bandwidth consumption.
各チャンクは、SSRC / CSRC識別子と、それに続く0個以上の項目のリストで構成され、SSRC / CSRCに関する情報を保持します。各チャンクは32ビット境界で始まります。各項目は、8ビットタイプのフィールド、テキストの長さを表す8ビットのオクテットカウント（したがって、この2オクテットのヘッダーは含まない）、およびテキスト自体で構成されます。テキストは255オクテット以下にする必要がありますが、これはRTCP帯域幅の消費を制限する必要性と一致しています。
The text is encoded according to the UTF-8 encoding specified in RFC 2279 [5]. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi-octet encodings is indicated by setting the most significant bit of a character to a value of one.
テキストは、RFC 2279 [5]で指定されているUTF-8エンコーディングに従ってエンコードされます。 US-ASCIIはこのエンコーディングのサブセットであり、追加のエンコーディングは必要ありません。マルチオクテットエンコーディングの存在は、文字の最上位ビットを値1に設定することで示されます。
Items are contiguous, i.e., items are not individually padded to a 32-bit boundary. Text is not null terminated because some multi-octet encodings include null octets. The list of items in each chunk MUST be terminated by one or more null octets, the first of which is interpreted as an item type of zero to denote the end of the list. No length octet follows the null item type octet, but additional null octets MUST be included if needed to pad until the next 32-bit boundary. Note that this padding is separate from that indicated by the P bit in the RTCP header. A chunk with zero items (four null octets) is valid but useless.
アイテムは連続しています。つまり、アイテムは32ビット境界に個別にパディングされていません。一部のマルチオクテットエンコーディングにはnullオクテットが含まれるため、テキストはnullで終了しません。各チャンク内のアイテムのリストは、1つ以上のヌルオクテットで終了する必要があります。最初のヌルオクテットは、リストの終わりを示すゼロのアイテムタイプとして解釈されます。 null項目タイプのオクテットに続く長さのオクテットはありませんが、次の32ビット境界までパディングする必要がある場合は、追加のnullオクテットを含める必要があります。このパディングは、RTCPヘッダーのPビットで示されるパディングとは異なることに注意してください。ゼロ項目（4つのヌルオクテット）のチャンクは有効ですが、役に立たないものです。
End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets in the format above if there are more than 31 such sources (see Section 7).
エンドシステムは、独自のソース識別子を含む1つのSDESパケットを送信します（固定RTPヘッダーのSSRCと同じ）。ミキサーは、SDES情報の受信元となるソースごとにチャンクを含む1つのSDESパケットを送信します。そのようなソースが31以上ある場合は、セクション7を参照してください。
The SDES items currently defined are described in the next sections. Only the CNAME item is mandatory. Some items shown here may be useful only for particular profiles, but the item types are all assigned from one common space to promote shared use and to simplify profile-independent applications. Additional items may be defined in a profile by registering the type numbers with IANA as described in Section 15.
現在定義されているSDESアイテムについては、次のセクションで説明します。 CNAMEアイテムのみが必須です。ここに表示される一部のアイテムは特定のプロファイルにのみ役立つ場合がありますが、アイテムタイプはすべて1つの共通スペースから割り当てられ、共有の使用を促進し、プロファイルに依存しないアプリケーションを簡素化します。セクション15で説明するように、タイプ番号をIANAに登録することにより、プロファイルで追加の項目を定義できます。
6.5.1 CNAME: Canonical End-Point Identifier SDES Item
6.5.1 CNAME：Canonical End-Point Identifier SDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
CNAME識別子には次のプロパティがあります。
o Because the randomly allocated SSRC identifier may change if a conflict is discovered or if a program is restarted, the CNAME item MUST be included to provide the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant.
o ランダムに割り当てられたSSRC識別子は、競合が発見された場合、またはプログラムが再起動された場合に変更される可能性があるため、SSRC識別子からソース（送信者または受信者）の識別子へのバインディングを提供するCNAMEアイテムを含める必要があります。
o Like the SSRC identifier, the CNAME identifier SHOULD also be unique among all participants within one RTP session.
o SSRC識別子と同様に、CNAME識別子も1つのRTPセッション内のすべての参加者の間で一意である必要があります（SHOULD）。
o To provide a binding across multiple media tools used by one participant in a set of related RTP sessions, the CNAME SHOULD be fixed for that participant.
o 関連するRTPセッションのセットで1人の参加者が使用する複数のメディアツールにバインドを提供するには、その参加者に対してCNAMEを修正する必要があります（SHOULD）。
o To facilitate third-party monitoring, the CNAME SHOULD be suitable for either a program or a person to locate the source.
o サードパーティによる監視を容易にするために、CNAMEはプログラムまたは人がソースを特定するのに適している必要があります。
Therefore, the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics. The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available as on single-user systems. For both formats, "host" is either the fully qualified domain name of the host from which the real-time data originates, formatted according to the rules specified in RFC 1034 [6], RFC 1035 [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII representation of the host's numeric address on the interface used for the RTP communication. For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 3513 [23]). Other address types are expected to have ASCII representations that are mutually unique. The fully qualified domain name is more convenient for a human observer and may avoid the need to send a NAME item in addition, but it may be difficult or impossible to obtain reliably in some operating environments. Applications that may be run in such environments SHOULD use the ASCII representation of the address instead.
したがって、CNAMEはアルゴリズムで導出する必要があり、可能な場合は手動で入力しないでください。これらの要件を満たすために、プロファイルで代替構文またはセマンティクスが指定されていない限り、次の形式を使用する必要があります（SHOULD）。 CNAMEアイテムの形式は「user @ host」、またはシングルユーザーシステムのようにユーザー名が利用できない場合は「host」にする必要があります。どちらの形式でも、「ホスト」は、リアルタイムデータの送信元であるホストの完全修飾ドメイン名であり、RFC 1034 [6]、RFC 1035 [7]およびRFC 1123のセクション2.1で指定されたルールに従ってフォーマットされています。 [8];または、RTP通信に使用されるインターフェース上のホストの数値アドレスの標準ASCII表現。たとえば、IPバージョン4アドレスの標準のASCII表現は「ドット付き10進数」であり、ドット付きクワッドとも呼ばれます。IPバージョン6の場合、アドレスはテキストでコロンで区切られた16進数のグループとして表現されます（RFCに詳細が記載されているバリエーションがあります）。 3513 [23]）。他のアドレスタイプには、相互に一意のASCII表現が必要です。完全修飾ドメイン名は人間の観察者にとってより便利であり、さらにNAMEアイテムを送信する必要性を回避する可能性がありますが、一部の動作環境では確実に取得することが困難または不可能である場合があります。そのような環境で実行される可能性のあるアプリケーションは、代わりにアドレスのASCII表現を使用する必要があります。
Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.example.com", "192.0.2.89" or "2201:056D::112E:144A:1E24".
たとえば、マルチユーザーシステムの場合、「doe@sleepy.example.com」、「doe@192.0.2.89」、「doe @ 2201：056D :: 112E：144A：1E24」などです。ユーザー名のないシステムでは、例は「sleepy.example.com」、「192.0.2.89」または「2201：056D :: 112E：144A：1E24」です。
The user name SHOULD be in a form that a program such as "finger" or "talk" could use, i.e., it typically is the login name rather than the personal name. The host name is not necessarily identical to the one in the participant's electronic mail address.
ユーザー名は、「finger」や「talk」などのプログラムが使用できる形式にする必要があります。つまり、通常は個人名ではなくログイン名です。ホスト名は、参加者の電子メールアドレスのホスト名と必ずしも同じではありません。
This syntax will not provide unique identifiers for each source if an application permits a user to generate multiple sources from one host. Such an application would have to rely on the SSRC to further identify the source, or the profile for that application would have to specify additional syntax for the CNAME identifier.
アプリケーションがユーザーが1つのホストから複数のソースを生成することを許可する場合、この構文は各ソースに一意の識別子を提供しません。そのようなアプリケーションは、ソースをさらに特定するためにSSRCに依存する必要があります。または、そのアプリケーションのプロファイルは、CNAME識別子の追加の構文を指定する必要があります。
If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool.
各アプリケーションが独立してCNAMEを作成する場合、関連する一連のRTPセッションの1つの参加者に属する複数のメディアツールにバインドを提供するために必要となるため、結果のCNAMEは同一ではない可能性があります。クロスメディアバインディングが必要な場合、各ツールのCNAMEを調整ツールによって同じ値で外部的に構成する必要がある場合があります。
Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1918 [24] may create network addresses that are not globally unique. This would lead to non-unique CNAMEs if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627 [25].) To handle this case, applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed.
アプリケーション作成者は、RFC 1918 [24]で提案されているNet-10割り当てなどのプライベートネットワークアドレス割り当てが、グローバルに一意ではないネットワークアドレスを作成する可能性があることに注意する必要があります。プライベートアドレスがあり、パブリックインターネットへの直接IP接続がないホストのRTPパケットがRTPレベルのトランスレータを介してパブリックインターネットに転送されている場合、これにより、一意でないCNAMEが発生します。 （RFC 1627 [25]も参照してください。）このケースを処理するために、アプリケーションは一意のCNAMEを構成する手段を提供できますが、プライベートアドレスが必要にならないようにする必要がある場合は、トランスレータがCNAMEをプライベートアドレスからパブリックアドレスに変換する負担があります。露出した。
6.5.2 NAME: User Name SDES Item
6.5.2 NAME：ユーザー名SDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe, Bit Recycler". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session.
これは、ソースを説明するために使用される本当の名前です（例： "John Doe、Bit Recycler"）。これは、ユーザーが希望する任意の形式にすることができます。会議などのアプリケーションの場合、この形式の名前は参加者リストでの表示に最も適しているため、CNAME以外のアイテムの中で最も頻繁に送信される可能性があります。プロファイルはそのような優先順位を確立してもよい（MAY）。 NAME値は、少なくともセッションの間は一定のままであることが期待されます。セッションのすべての参加者の間で一意であるとは限りません。
6.5.3 EMAIL: Electronic Mail Address SDES Item
6.5.3電子メール：電子メールアドレスSDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC 2822 [9], for example, "John.Doe@example.com". The EMAIL value is expected to remain constant for the duration of a session.
電子メールアドレスは、RFC 2822 [9]に従ってフォーマットされます（例： "John.Doe@example.com"）。 EMAIL値は、セッションの期間中一定のままであると予想されます。
6.5.4 PHONE: Phone Number SDES Item
6.5.4電話：電話番号SDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States.
電話番号は、国際アクセスコードを置き換えるプラス記号でフォーマットする必要があります。たとえば、米国の番号の場合は「+1 908 555 1212」。
6.5.5 LOC: Geographic User Location SDES Item
6.5.5 LOC：地理的ユーザーの場所SDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Depending on the application, different degrees of detail are appropriate for this item. For conference applications, a string like "Murray Hill, New Jersey" may be sufficient, while, for an active badge system, strings like "Room 2A244, AT&T BL MH" might be appropriate. The degree of detail is left to the implementation and/or user, but format and content MAY be prescribed by a profile. The LOC value is expected to remain constant for the duration of a session, except for mobile hosts.
アプリケーションに応じて、さまざまな詳細度がこのアイテムに適しています。会議アプリケーションの場合、「ニュージャージー州マレーヒル」のような文字列で十分な場合がありますが、アクティブなバッジシステムの場合、「Room 2A244、AT＆T BL MH」のような文字列が適切な場合があります。詳細度は実装やユーザーに委ねられますが、フォーマットとコンテンツはプロファイルによって規定される場合があります。 LOC値は、モバイルホストを除き、セッションの期間中一定であると予想されます。
6.5.6 TOOL: Application or Tool Name SDES Item
6.5.6ツール：アプリケーションまたはツール名のSDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A string giving the name and possibly version of the application generating the stream, e.g., "videotool 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The TOOL value is expected to remain constant for the duration of the session.
ストリームを生成するアプリケーションの名前と、場合によってはバージョンを示す文字列（例： "videotool 1.2"）。この情報はデバッグに役立つ場合があり、MailerまたはMail-System-Version SMTPヘッダーに似ています。 TOOL値は、セッションの期間中一定であることが期待されます。
6.5.7 NOTE: Notice/Status SDES Item
6.5.7注：通知/ステータスSDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following semantics are suggested for this item, but these or other semantics MAY be explicitly defined by a profile. The NOTE item is intended for transient messages describing the current state of the source, e.g., "on the phone, can't talk". Or, during a seminar, this item might be used to convey the title of the talk. It should be used only to carry exceptional information and SHOULD NOT be included routinely by all participants because this would slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. In particular, it SHOULD NOT be included as an item in a user's configuration file nor automatically generated as in a quote-of-the-day.
このアイテムには次のセマンティクスが推奨されますが、これらまたは他のセマンティクスはプロファイルによって明示的に定義される場合があります。 NOTE項目は、ソースの現在の状態を説明する一時的なメッセージを対象としています（例：「電話中、話せません」）。または、セミナー中に、このアイテムを使用してトークのタイトルを伝えることもできます。これは、例外的な情報を伝えるためにのみ使用する必要があります。これは、受信レポートとCNAMEの送信速度を低下させ、プロトコルのパフォーマンスを低下させるため、すべての参加者が日常的に含めるべきではありません。特に、ユーザーの構成ファイルの項目として含めたり、今日の見積もりのように自動的に生成したりしないでください。
Since the NOTE item may be important to display while it is active, the rate at which other non-CNAME items such as NAME are transmitted might be reduced so that the NOTE item can take that part of the RTCP bandwidth. When the transient message becomes inactive, the NOTE item SHOULD continue to be transmitted a few times at the same repetition rate but with a string of length zero to signal the receivers. However, receivers SHOULD also consider the NOTE item inactive if it is not received for a small multiple of the repetition rate, or perhaps 20-30 RTCP intervals.
NOTEアイテムはアクティブなときに表示することが重要な場合があるため、NAMEなどの他のCNAME以外のアイテムが送信される速度が低下し、NOTEアイテムがRTCP帯域幅のその部分を占めるようになる場合があります。一時的なメッセージが非アクティブになると、NOTアイテムは同じ繰り返しレートで数回送信され続ける必要がありますが、レシーバーに信号を送るために長さがゼロの文字列で送信されます。ただし、受信者は、繰り返し数の小さな倍数、またはおそらく20〜30のRTCP間隔で受信されない場合、NOTEアイテムを非アクティブと見なす必要があります。
6.5.8 PRIV: Private Extensions SDES Item
6.5.8 PRIV：Private Extensions SDESアイテム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This item is used to define experimental or application-specific SDES extensions. The item contains a prefix consisting of a length-string pair, followed by the value string filling the remainder of the item and carrying the desired information. The prefix length field is 8 bits long. The prefix string is a name chosen by the person defining the PRIV item to be unique with respect to other PRIV items this application might receive. The application creator might choose to use the application name plus an additional subtype identification if needed. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity.
この項目は、実験的またはアプリケーション固有のSDES拡張を定義するために使用されます。項目には、長さと文字列のペアで構成される接頭辞が含まれ、その後に値の文字列が残りの項目を埋め、必要な情報を保持します。プレフィックス長フィールドは8ビット長です。プレフィックス文字列は、このアプリケーションが受け取る可能性のある他のPRIVアイテムに対して一意になるようにPRIVアイテムを定義する人が選択した名前です。アプリケーション作成者は、必要に応じて、アプリケーション名と追加のサブタイプIDを使用することを選択できます。または、他の人が彼らが表すエンティティに基づいて名前を選択し、そのエンティティ内での名前の使用を調整することをお勧めします。
Note that the prefix consumes some space within the item's total length of 255 octets, so the prefix should be kept as short as possible. This facility and the constrained RTCP bandwidth SHOULD NOT be overloaded; it is not intended to satisfy all the control communication requirements of all applications.
接頭辞は、アイテムの全長255オクテット内のスペースを消費するため、接頭辞はできるだけ短くする必要があります。この機能と制約されたRTCP帯域幅を過負荷にしないでください。すべてのアプリケーションのすべての制御通信要件を満たすことは意図されていません。
SDES PRIV prefixes will not be registered by IANA. If some form of the PRIV item proves to be of general utility, it SHOULD instead be assigned a regular SDES item type registered with IANA so that no prefix is required. This simplifies use and increases transmission efficiency.
SDES PRIVプレフィックスはIANAによって登録されません。何らかの形のPRIVアイテムが一般的な有用性があることが判明した場合は、プレフィックスが不要になるように、IANAに登録された通常のSDESアイテムタイプを割り当てる必要があります（SHOULD）。これにより、使用が簡単になり、伝送効率が向上します。
6.6 BYE: Goodbye RTCP Packet
6.6 BYE：さようならRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BYE packet indicates that one or more sources are no longer active.
BYEパケットは、1つ以上のソースがアクティブではなくなったことを示します。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
バージョン（V）、パディング（P）、長さ：SRパケットについて説明したとおり（セクション6.4.1を参照）。
packet type (PT): 8 bits Contains the constant 203 to identify this as an RTCP BYE packet.
パケットタイプ（PT）：8ビットこれをRTCP BYEパケットとして識別する定数203が含まれています。
source count (SC): 5 bits The number of SSRC/CSRC identifiers included in this BYE packet. A count value of zero is valid, but useless.
ソースカウント（SC）：5ビットこのBYEパケットに含まれるSSRC / CSRC識別子の数。ゼロのカウント値は有効ですが、役に立ちません。
The rules for when a BYE packet should be sent are specified in Sections 6.3.7 and 8.2.
BYEパケットを送信する必要がある場合のルールは、セクション6.3.7および8.2で指定されています。
If a BYE packet is received by a mixer, the mixer SHOULD forward the BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts down, it SHOULD send a BYE packet listing all contributing sources it handles, as well as its own SSRC identifier. Optionally, the BYE packet MAY include an 8-bit octet count followed by that many octets of text indicating the reason for leaving, e.g., "camera malfunction" or "RTP loop detected". The string has the same encoding as that described for SDES. If the string fills the packet to the next 32-bit boundary, the string is not null terminated. If not, the BYE packet MUST be padded with null octets to the next 32- bit boundary. This padding is separate from that indicated by the P bit in the RTCP header.
BYEパケットがミキサーによって受信された場合、ミキサーは、SSRC / CSRC識別子を変更せずにBYEパケットを転送する必要があります（SHOULD）。ミキサーがシャットダウンした場合、ミキサーは、自身が処理するすべてのソースと、独自のSSRC識別子を含むBYEパケットを送信する必要があります（SHOULD）。必要に応じて、BYEパケットには、8ビットのオクテットカウントと、それに続く、たとえば「カメラの誤動作」や「RTPループの検出」などの理由を示すテキストのオクテットが含まれる場合があります。文字列のエンコードは、SDESで説明されているものと同じです。文字列が次の32ビット境界までパケットを満たす場合、文字列はnullで終了していません。そうでない場合、BYEパケットは次の32ビット境界までヌルオクテットでパディングする必要があります。このパディングは、RTCPヘッダーのPビットで示されるものとは別です。
6.7 APP: Application-Defined RTCP Packet
6.7 APP：アプリケーション定義のRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names SHOULD be ignored. After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type.
APPパケットは、パケットタイプ値の登録を必要とせずに、新しいアプリケーションや新機能が開発された実験的な使用を目的としています。認識されない名前のAPPパケットは無視する必要があります。テスト後、幅広い使用が正当化される場合は、各APPパケットをサブタイプおよび名前フィールドなしで再定義し、RTCPパケットタイプを使用してIANAに登録することをお勧めします。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
バージョン（V）、パディング（P）、長さ：SRパケットについて説明したとおり（セクション6.4.1を参照）。
subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data.
サブタイプ：5ビットサブタイプとして使用して、一連のAPPパケットを1つの一意の名前で定義したり、アプリケーションに依存するデータに使用したりできます。
packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP APP packet.
パケットタイプ（PT）：8ビットこれをRTCP APPパケットとして識別する定数204が含まれています。
name: 4 octets A name chosen by the person defining the set of APP packets to be unique with respect to other APP packets this application might receive. The application creator might choose to use the application name, and then coordinate the allocation of subtype values to others who want to define new packet types for the application. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. The name is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated as distinct.
name：4 octets APPパケットのセットを定義する人が、このアプリケーションが受信する可能性のある他のAPPパケットに対して一意になるように選択した名前。アプリケーションの作成者は、アプリケーション名を使用することを選択し、アプリケーションの新しいパケットタイプを定義したい他の人へのサブタイプ値の割り当てを調整できます。または、他の人が彼らが表すエンティティに基づいて名前を選択し、そのエンティティ内での名前の使用を調整することをお勧めします。名前は4つのASCII文字のシーケンスとして解釈され、大文字と小文字は区別されます。
application-dependent data: variable length Application-dependent data may or may not appear in an APP packet. It is interpreted by the application and not RTP itself. It MUST be a multiple of 32 bits long.
アプリケーション依存データ：可変長アプリケーション依存データは、APPパケットに含まれる場合と含まれない場合があります。これは、RTP自体ではなく、アプリケーションによって解釈されます。 32ビットの倍数である必要があります。
In addition to end systems, RTP supports the notion of "translators" and "mixers", which could be considered as "intermediate systems" at the RTP level. Although this support adds some complexity to the protocol, the need for these functions has been clearly established by experiments with multicast audio and video applications in the Internet. Example uses of translators and mixers given in Section 2.3 stem from the presence of firewalls and low bandwidth connections, both of which are likely to remain.
エンドシステムに加えて、RTPは「トランスレータ」と「ミキサー」の概念をサポートします。これは、RTPレベルで「中間システム」と見なすことができます。このサポートによりプロトコルが多少複雑になりますが、これらの機能の必要性は、インターネットでのマルチキャストオーディオおよびビデオアプリケーションの実験により明らかになりました。セクション2.3に記載されているトランスレータとミキサーの使用例は、ファイアウォールと低帯域幅接続の存在に由来します。これらは両方とも残る可能性があります。
7.1 General Description
7.1一般的な説明
An RTP translator/mixer connects two or more transport-level "clouds". Typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port or a pair of unicast addresses and ports. (Network-level protocol translators, such as IP version 4 to IP version 6, may be present within a cloud invisibly to RTP.) One system may serve as a translator or mixer for a number of RTP sessions, but each is considered a logically separate entity.
RTPトランスレータ/ミキサーは、2つ以上のトランスポートレベルの「クラウド」を接続します。通常、各クラウドは、共通のネットワークとトランスポートプロトコル（IP / UDPなど）に加えて、マルチキャストアドレスとトランスポートレベルの宛先ポートまたはユニキャストアドレスとポートのペアで定義されます。 （IPバージョン4からIPバージョン6などのネットワークレベルのプロトコルトランスレータは、RTPからは見えないようにクラウド内に存在する場合があります。）1つのシステムは、複数のRTPセッションのトランスレータまたはミキサーとして機能しますが、それぞれが論理的に見なされます。別のエンティティ。
In order to avoid creating a loop when a translator or mixer is installed, the following rules MUST be observed:
トランスレータまたはミキサーがインストールされているときにループが発生しないようにするために、次の規則を遵守する必要があります。
o Each of the clouds connected by translators and mixers participating in one RTP session either MUST be distinct from all the others in at least one of these parameters (protocol, address, port), or MUST be isolated at the network level from the others.
o 1つのRTPセッションに参加しているトランスレーターとミキサーによって接続されている各クラウドは、これらのパラメーター（プロトコル、アドレス、ポート）の少なくとも1つが他のすべてと区別されているか、ネットワークレベルで他から分離されている必要があります。
o A derivative of the first rule is that there MUST NOT be multiple translators or mixers connected in parallel unless by some arrangement they partition the set of sources to be forwarded.
o 最初のルールの派生物は、転送のためにソースのセットを分割する配置がない限り、並列に接続された複数のトランスレーターまたはミキサーがあってはならないことです。
Similarly, all RTP end systems that can communicate through one or more RTP translators or mixers share the same SSRC space, that is, the SSRC identifiers MUST be unique among all these end systems. Section 8.2 describes the collision resolution algorithm by which SSRC identifiers are kept unique and loops are detected.
同様に、1つ以上のRTPトランスレーターまたはミキサーを介して通信できるすべてのRTPエンドシステムは、同じSSRCスペースを共有します。つまり、SSRC識別子はこれらのエンドシステム間で一意である必要があります。セクション8.2では、SSRC識別子を一意に保ち、ループを検出する衝突解決アルゴリズムについて説明します。
There may be many varieties of translators and mixers designed for different purposes and applications. Some examples are to add or remove encryption, change the encoding of the data or the underlying protocols, or replicate between a multicast address and one or more unicast addresses. The distinction between translators and mixers is that a translator passes through the data streams from different sources separately, whereas a mixer combines them to form one new stream:
さまざまな目的やアプリケーション向けに設計されたさまざまな種類のトランスレータやミキサーが存在する場合があります。いくつかの例は、暗号化の追加または削除、データまたは基になるプロトコルのエンコーディングの変更、またはマルチキャストアドレスと1つ以上のユニキャストアドレス間の複製です。トランスレーターとミキサーの違いは、トランスレーターは異なるソースからのデータストリームを個別に通過するのに対し、ミキサーはそれらを結合して1つの新しいストリームを形成することです。
Translator: Forwards RTP packets with their SSRC identifier intact; this makes it possible for receivers to identify individual sources even though packets from all the sources pass through the same translator and carry the translator's network source address. Some kinds of translators will pass through the data untouched, but others MAY change the encoding of the data and thus the RTP data payload type and timestamp. If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming packet stream may induce corresponding gaps in the outgoing sequence numbers. Receivers cannot detect the presence of a translator unless they know by some other means what payload type or transport address was used by the original source.
トランスレーター：RTPパケットを、SSRC IDをそのままにして転送します。これにより、すべてのソースからのパケットが同じトランスレータを通過し、トランスレータのネットワークソースアドレスを伝送する場合でも、レシーバは個々のソースを識別できます。一部の種類のトランスレータはそのままデータを通過しますが、他の種類のトランスレータはデータのエンコーディングを変更し、RTPデータのペイロードタイプとタイムスタンプを変更する場合があります。複数のデータパケットが1つに再エンコードされる場合、またはその逆の場合、トランスレータは、発信パケットに新しいシーケンス番号を割り当てる必要があります。着信パケットストリームの損失は、発信シーケンス番号に対応するギャップを引き起こす可能性があります。レシーバーは、元のソースで使用されたペイロードタイプまたはトランスポートアドレスが他の方法でわからない限り、トランスレーターの存在を検出できません。
Mixer: Receives streams of RTP data packets from one or more sources, possibly changes the data format, combines the streams in some manner and then forwards the combined stream. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream, so it is the synchronization source. Thus, all data packets forwarded by a mixer MUST be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet, the mixer SHOULD insert their SSRC identifiers into the CSRC identifier list following the fixed RTP header of the packet. A mixer that is also itself a contributing source for some packet SHOULD explicitly include its own SSRC identifier in the CSRC list for that packet.
ミキサー：1つ以上のソースからRTPデータパケットのストリームを受信し、データ形式を変更し、何らかの方法でストリームを結合してから、結合したストリームを転送します。複数の入力ソース間のタイミングは一般的に同期されないため、ミキサーはストリーム間のタイミング調整を行い、結合されたストリームに対して独自のタイミングを生成するため、同期ソースになります。したがって、ミキサーによって転送されるすべてのデータパケットは、ミキサー自体のSSRC識別子でマークされている必要があります。混合パケットに寄与する元のソースのIDを保持するために、ミキサーは、パケットの固定RTPヘッダーに続くCSRC識別子リストにSSRC識別子を挿入する必要があります（SHOULD）。それ自体が一部のパケットのソースでもあるミキサーは、そのパケットのCSRCリストに独自のSSRC識別子を明示的に含める必要があります（SHOULD）。
For some applications, it MAY be acceptable for a mixer not to identify sources in the CSRC list. However, this introduces the danger that loops involving those sources could not be detected.
一部のアプリケーションでは、ミキサーがCSRCリストでソースを識別しないことが許容される場合があります。ただし、これにより、これらのソースを含むループが検出されない危険性が生じます。
The advantage of a mixer over a translator for applications like audio is that the output bandwidth is limited to that of one source even when multiple sources are active on the input side. This may be important for low-bandwidth links. The disadvantage is that receivers on the output side don't have any control over which sources are passed through or muted, unless some mechanism is implemented for remote control of the mixer. The regeneration of synchronization information by mixers also means that receivers can't do inter-media synchronization of the original streams. A multi-media mixer could do it.
オーディオのようなアプリケーションのトランスレータに対するミキサーの利点は、入力側で複数のソースがアクティブな場合でも、出力帯域幅が1つのソースの帯域幅に制限されることです。これは、低帯域幅のリンクにとって重要な場合があります。短所は、ミキサーのリモートコントロールに何らかのメカニズムが実装されていない限り、出力側のレシーバーはどのソースを通過またはミュートするかを制御できないことです。ミキサーによる同期情報の再生成は、レシーバーが元のストリームのメディア間同期を実行できないことも意味します。マルチメディアミキサーはそれを行うことができます。
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->
Figure 3: Sample RTP network with end systems, mixers and translators
図3：エンドシステム、ミキサー、トランスレーターを含むサンプルRTPネットワーク
A collection of mixers and translators is shown in Fig. 3 to illustrate their effect on SSRC and CSRC identifiers. In the figure, end systems are shown as rectangles (named E), translators as triangles (named T) and mixers as ovals (named M). The notation "M1: 48(1,17)" designates a packet originating a mixer M1, identified by M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, copied from the SSRC identifiers of packets from E1 and E2.
SSRCおよびCSRC識別子への影響を示すために、ミキサーとトランスレーターのコレクションを図3に示します。この図では、エンドシステムは長方形（Eという名前）、トランスレータは三角形（Tという名前）、ミキサーは楕円（Mという名前）として示されています。 「M1：48（1,17）」という表記は、M1の（ランダムな）SSRC値48と、E1およびE2からのパケットのSSRC識別子からコピーされた2つのCSRC識別子1および17によって識別されるミキサーM1を発信するパケットを示します。 。
7.2 RTCP Processing in Translators
7.2トランスレータでのRTCP処理
In addition to forwarding data packets, perhaps modified, translators and mixers MUST also process RTCP packets. In many cases, they will take apart the compound RTCP packets received from end systems to aggregate SDES information and to modify the SR or RR packets. Retransmission of this information may be triggered by the packet arrival or by the RTCP interval timer of the translator or mixer itself.
データパケットの転送に加えて、おそらく変更されたトランスレータとミキサーも、RTCPパケットを処理する必要があります。多くの場合、エンドシステムから受信した複合RTCPパケットを分解して、SDES情報を集約し、SRまたはRRパケットを変更します。この情報の再送信は、パケットの到着、またはトランスレーターまたはミキサー自体のRTCPインターバルタイマーによってトリガーされます。
A translator that does not modify the data packets, for example one that just replicates between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified as well. A translator that transforms the payload in some way MUST make corresponding transformations in the SR and RR information so that it still reflects the characteristics of the data and the reception quality. These translators MUST NOT simply forward RTCP packets. In general, a translator SHOULD NOT aggregate SR and RR packets from different sources into one packet since that would reduce the accuracy of the propagation delay measurements based on the LSR and DLSR fields.
データパケットを変更しないトランスレータ、たとえば、マルチキャストアドレスとユニキャストアドレスの間で複製するトランスレータは、変更されていないRTCPパケットを転送するだけでもかまいません。ペイロードを何らかの方法で変換するトランスレータは、SRおよびRR情報に対応する変換を行わなければならないため、データの特性と受信品質が反映されます。これらのトランスレータは、RTCPパケットを単純に転送してはなりません。一般に、トランスレータは、異なるソースからのSRパケットとRRパケットを1つのパケットに集約しないでください。これは、LSRフィールドとDLSRフィールドに基づく伝播遅延測定の精度が低下するためです。
SR sender information: A translator does not generate its own sender information, but forwards the SR packets received from one cloud to the others. The SSRC is left intact but the sender information MUST be modified if required by the translation. If a translator changes the data encoding, it MUST change the "sender's byte count" field. If it also combines several data packets into one output packet, it MUST change the "sender's packet count" field. If it changes the timestamp frequency, it MUST change the "RTP timestamp" field in the SR packet.
SR送信者情報：トランスレーターは独自の送信者情報を生成しませんが、1つのクラウドから受信したSRパケットを他のクラウドに転送します。 SSRCはそのまま残されますが、変換で必要な場合は送信者情報を変更する必要があります。トランスレータがデータエンコーディングを変更する場合は、「送信者のバイト数」フィールドを変更する必要があります。複数のデータパケットを1つの出力パケットに結合する場合も、「送信者のパケット数」フィールドを変更する必要があります。タイムスタンプの頻度を変更する場合は、SRパケットの「RTPタイムスタンプ」フィールドを変更する必要があります。
SR/RR reception report blocks: A translator forwards reception reports received from one cloud to the others. Note that these flow in the direction opposite to the data. The SSRC is left intact. If a translator combines several data packets into one output packet, and therefore changes the sequence numbers, it MUST make the inverse manipulation for the packet loss fields and the "extended last sequence number" field. This may be complex. In the extreme case, there may be no meaningful way to translate the reception reports, so the translator MAY pass on no reception report at all or a synthetic report based on its own reception. The general rule is to do what makes sense for a particular translation.
SR / RR受信レポートブロック：トランスレーターは、1つのクラウドから受信した受信レポートを他のクラウドに転送します。これらはデータと反対の方向に流れることに注意してください。 SSRCはそのまま残されます。トランスレータが複数のデータパケットを1つの出力パケットに結合し、したがってシーケンス番号を変更する場合、パケット損失フィールドと「拡張された最後のシーケンス番号」フィールドの逆の操作を行う必要があります。これは複雑な場合があります。極端なケースでは、受信レポートを翻訳する意味のある方法がない可能性があるため、トランスレータは受信レポートをまったく渡さないか、独自の受信に基づく合成レポートを渡してもよい（MAY）。一般的なルールは、特定の翻訳に意味のあることを行うことです。
A translator does not require an SSRC identifier of its own, but MAY choose to allocate one for the purpose of sending reports about what it has received. These would be sent to all the connected clouds, each corresponding to the translation of the data stream as sent to that cloud, since reception reports are normally multicast to all participants.
トランスレータはそれ自体のSSRC識別子を必要としませんが、受け取ったものに関するレポートを送信する目的で割り当てることができます。受信レポートは通常すべての参加者にマルチキャストされるため、これらは接続されているすべてのクラウドに送信され、それぞれがそのクラウドに送信されたデータストリームの変換に対応します。
SDES: Translators typically forward without change the SDES information they receive from one cloud to the others, but MAY, for example, decide to filter non-CNAME SDES information if bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC identifier collision detection to work. A translator that generates its own RR packets MUST send SDES CNAME information about itself to the same clouds that it sends those RR packets.
SDES：通常、トランスレーターは、1つのクラウドから他のクラウドに受信するSDES情報を変更せずに転送しますが、たとえば、帯域幅が限られている場合は、非CNAME SDES情報をフィルターに掛けることを決定できます。 SSRC識別子の衝突検出が機能するためには、CNAMEを転送する必要があります。独自のRRパケットを生成するトランスレーターは、自身に関するSDES CNAME情報を、それらのRRパケットを送信するのと同じクラウドに送信する必要があります。
BYE: Translators forward BYE packets unchanged. A translator that is about to cease forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the translator's own SSRC identifier if it sent reports of its own.
BYE：トランスレータはBYEパケットを変更せずに転送します。転送を停止しようとしているトランスレーターは、以前にそのクラウドに転送されていたすべてのSSRC識別子を含む各接続済みクラウドにBYEパケットを送信する必要があります（独自のレポートを送信した場合はトランスレーター自身のSSRC識別子を含む）。
APP: Translators forward APP packets unchanged.
APP：トランスレーターはAPPパケットを変更せずに転送します。
7.3 RTCP Processing in Mixers
7.3ミキサーでのRTCP処理
Since a mixer generates a new data stream of its own, it does not pass through SR or RR packets at all and instead generates new information for both sides.
ミキサーは独自の新しいデータストリームを生成するため、SRまたはRRパケットをまったく通過せず、代わりに両側の新しい情報を生成します。
SR sender information: A mixer does not pass through sender information from the sources it mixes because the characteristics of the source streams are lost in the mix. As a synchronization source, the mixer SHOULD generate its own SR packets with sender information about the mixed data stream and send them in the same direction as the mixed stream.
SR送信者情報：ソースストリームの特性が混合で失われるため、ミキサーは、混合するソースからの送信者情報を通過しません。同期ソースとして、ミキサーは、混合データストリームに関する送信者情報を含む独自のSRパケットを生成し、それらを混合ストリームと同じ方向に送信する必要があります（SHOULD）。
SR/RR reception report blocks: A mixer generates its own reception reports for sources in each cloud and sends them out only to the same cloud. It MUST NOT send these reception reports to the other clouds and MUST NOT forward reception reports from one cloud to the others because the sources would not be SSRCs there (only CSRCs).
SR / RR受信レポートブロック：ミキサーは、各クラウドのソースに関する独自の受信レポートを生成し、同じクラウドにのみ送信します。これらの受信レポートを他のクラウドに送信してはならず、ソースがSSRCではないため（CSRCのみ）、1つのクラウドから他のクラウドに受信レポートを転送してはなりません。
SDES: Mixers typically forward without change the SDES information they receive from one cloud to the others, but MAY, for example, decide to filter non-CNAME SDES information if bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC identifier collision detection to work. (An identifier in a CSRC list generated by a mixer might collide with an SSRC identifier generated by an end system.) A mixer MUST send SDES CNAME information about itself to the same clouds that it sends SR or RR packets.
SDES：ミキサーは通常、1つのクラウドから他のクラウドに受信するSDES情報を変更せずに転送しますが、たとえば、帯域幅が限られている場合は、非CNAME SDES情報をフィルターに掛けることを決定する場合があります。 SSRC識別子の衝突検出が機能するためには、CNAMEを転送する必要があります。 （ミキサーによって生成されたCSRCリスト内の識別子は、エンドシステムによって生成されたSSRC識別子と衝突する可能性があります。）ミキサーは、SRまたはRRパケットを送信するのと同じクラウドに、自身に関するSDES CNAME情報を送信する必要があります。
Since mixers do not forward SR or RR packets, they will typically be extracting SDES packets from a compound RTCP packet. To minimize overhead, chunks from the SDES packets MAY be aggregated into a single SDES packet which is then stacked on an SR or RR packet originating from the mixer. A mixer which aggregates SDES packets will use more RTCP bandwidth than an individual source because the compound packets will be longer, but that is appropriate since the mixer represents multiple sources. Similarly, a mixer which passes through SDES packets as they are received will be transmitting RTCP packets at higher than the single source rate, but again that is correct since the packets come from multiple sources. The RTCP packet rate may be different on each side of the mixer.
ミキサーはSRまたはRRパケットを転送しないため、通常、複合RTCPパケットからSDESパケットを抽出します。オーバーヘッドを最小限に抑えるために、SDESパケットからのチャンクを単一のSDESパケットに集約してから、ミキサーから発信されたSRまたはRRパケットにスタックすることができます（MAY）。 SDESパケットを集約するミキサーは、複合パケットが長くなるため、個々のソースよりも多くのRTCP帯域幅を使用しますが、ミキサーが複数のソースを表すため、これは適切です。同様に、受信時にSDESパケットを通過するミキサーは、単一のソースレートよりも高い速度でRTCPパケットを送信しますが、パケットが複数のソースから送信されるため、これも正しいことです。 RTCPパケットレートは、ミキサーの両側で異なる場合があります。
A mixer that does not insert CSRC identifiers MAY also refrain from forwarding SDES CNAMEs. In this case, the SSRC identifier spaces in the two clouds are independent. As mentioned earlier, this mode of operation creates a danger that loops can't be detected.
CSRC識別子を挿入しないミキサーも、SDES CNAMEの転送を控える場合があります。この場合、2つのクラウドのSSRC IDスペースは独立しています。前述のように、この操作モードでは、ループを検出できない危険が生じます。
BYE: Mixers MUST forward BYE packets. A mixer that is about to cease forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the mixer's own SSRC identifier if it sent reports of its own.
BYE：ミキサーはBYEパケットを転送する必要があります。パケットの転送を停止しようとしているミキサーは、以前にそのクラウドに転送されていたすべてのSSRC識別子を含む各接続されたクラウドにBYEパケットを送信する必要があります（独自のレポートを送信した場合はミキサー自体のSSRC識別子を含む）。
APP: The treatment of APP packets by mixers is application-specific.
APP：ミキサーによるAPPパケットの処理はアプリケーション固有です。
7.4 Cascaded Mixers
7.4カスケードミキサー
An RTP session may involve a collection of mixers and translators as shown in Fig. 3. If two mixers are cascaded, such as M2 and M3 in the figure, packets received by a mixer may already have been mixed and may include a CSRC list with multiple identifiers. The second mixer SHOULD build the CSRC list for the outgoing packet using the CSRC identifiers from already-mixed input packets and the SSRC identifiers from unmixed input packets. This is shown in the output arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case of mixers that are not cascaded, if the resulting CSRC list has more than 15 identifiers, the remainder cannot be included.
図3に示すように、RTPセッションにはミキサーとトランスレーターのコレクションが含まれる場合があります。図のM2とM3のように2つのミキサーがカスケード接続されている場合、ミキサーによって受信されたパケットはすでに混合されており、CSRCリストが含まれている場合があります。複数の識別子。 2番目のミキサーは、既に混合されている入力パケットのCSRC識別子と混合されていない入力パケットのSSRC識別子を使用して、発信パケットのCSRCリストを作成する必要があります（SHOULD）。これは、図のM3：89（64,45）とラベル付けされたミキサーM3からの出力アークに示されています。カスケードされていないミキサーの場合のように、結果のCSRCリストに15を超える識別子がある場合、残りは含めることができません。
The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session. It is crucial that the number be chosen with care in order that participants on the same network or starting at the same time are not likely to choose the same number.
RTPヘッダーとRTCPパケットのさまざまなフィールドで伝達されるSSRC識別子は、RTPセッション内でグローバルに一意である必要がある32ビットのランダムな番号です。同じネットワーク上の参加者または同時に開始する参加者が同じ番号を選択する可能性が低くなるように、慎重に番号を選択することが重要です。
It is not sufficient to use the local network address (such as an IPv4 address) for the identifier because the address may not be unique. Since RTP translators and mixers enable interoperation among multiple networks with different address spaces, the allocation patterns for addresses within two spaces might result in a much higher rate of collision than would occur with random allocation.
アドレスは一意でない可能性があるため、識別子にローカルネットワークアドレス（IPv4アドレスなど）を使用するだけでは不十分です。 RTPトランスレータとミキサは、異なるアドレススペースを持つ複数のネットワーク間の相互運用を可能にするため、2つのスペース内のアドレスの割り当てパターンは、ランダム割り当ての場合よりもはるかに高い衝突率になる可能性があります。
Multiple sources running on one host would also conflict.
1つのホストで実行されている複数のソースも競合します。
It is also not sufficient to obtain an SSRC identifier simply by calling random() without carefully initializing the state. An example of how to generate a random identifier is presented in Appendix A.6.
また、状態を慎重に初期化せずにrandom()を呼び出すだけでSSRC識別子を取得するだけでは不十分です。ランダムな識別子を生成する方法の例を付録A.6に示します。
8.1 Probability of Collision
8.1衝突の確率
Since the identifiers are chosen randomly, it is possible that two or more sources will choose the same number. Collision occurs with the highest probability when all sources are started simultaneously, for example when triggered automatically by some session management event. If N is the number of sources and L the length of the identifier (here, 32 bits), the probability that two sources independently pick the same value can be approximated for large N [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4.
識別子はランダムに選択されるため、2つ以上のソースが同じ番号を選択する可能性があります。たとえば、セッション管理イベントによって自動的にトリガーされた場合など、すべてのソースが同時に開始されると、衝突が発生する可能性が最も高くなります。 Nがソースの数でLが識別子の長さ（ここでは32ビット）である場合、2つのソースが独立して同じ値を選択する確率は、大きなNの場合に近似できます[26] 1-exp（-N ** 2 / 2 **（L + 1））。 N = 1000の場合、確率は約10 **-4です。
The typical collision probability is much lower than the worst-case above. When one new source joins an RTP session in which all the other sources already have unique identifiers, the probability of collision is just the fraction of numbers used out of the space. Again, if N is the number of sources and L the length of the identifier, the probability of collision is N / 2**L. For N=1000, the probability is roughly 2*10**-7.
典型的な衝突確率は、上記の最悪の場合よりもはるかに低くなります。他のすべてのソースが既に一意の識別子を持っているRTPセッションに1つの新しいソースが参加する場合、衝突の確率は、スペースの外で使用される数の一部にすぎません。この場合も、Nがソースの数でLが識別子の長さである場合、衝突の確率はN / 2 ** Lです。 N = 1000の場合、確率は約2 * 10 **-7です。
The probability of collision is further reduced by the opportunity for a new source to receive packets from other participants before sending its first packet (either data or control). If the new source keeps track of the other participants (by SSRC identifier), then before transmitting its first packet the new source can verify that its identifier does not conflict with any that have been received, or else choose again.
衝突の確率は、新しいソースが最初のパケット（データまたは制御）を送信する前に他の参加者からパケットを受信する機会によってさらに減少します。新しいソースが他の参加者を（SSRC識別子によって）追跡している場合、最初のパケットを送信する前に、新しいソースはその識別子が受信したものと競合していないことを確認できます。
8.2 Collision Resolution and Loop Detection
8.2衝突解決とループ検出
Although the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one. (As explained below, this step is taken only once in case of a loop.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last.
SSRC識別子の衝突の可能性は低いですが、すべてのRTP実装は、衝突を検出し、衝突を解決するための適切なアクションを実行できるように準備する必要があります。ソースが別のソースがそれ自体と同じSSRC識別子を使用していることを発見した場合、古い識別子のRTCP BYEパケットを送信し、別のランダムなものを選択する必要があります。 （以下で説明するように、この手順はループの場合に1回だけ実行されます。）他の2つのソースが衝突していることを受信者が検出した場合、別のソースからパケットを保持し、別のソースからパケットを検出できる場合はそれを破棄できますソーストランスポートアドレスまたはCNAME。 2つのソースは、状況が持続しないように衝突を解決することが期待されています。
Because the random SSRC identifiers are kept globally unique for each RTP session, they can also be used to detect loops that may be introduced by mixers or translators. A loop causes duplication of data and control information, either unmodified or possibly mixed, as in the following examples:
ランダムSSRC識別子はRTPセッションごとにグローバルに一意に保たれるため、ミキサーまたはトランスレーターによって導入される可能性のあるループを検出するためにも使用できます。ループは、次の例のように、変更されていないか、混合されている可能性があるデータと制御情報の重複を引き起こします。
o A translator may incorrectly forward a packet to the same multicast group from which it has received the packet, either directly or through a chain of translators. In that case, the same packet appears several times, originating from different network sources.
o トランスレータは、直接またはトランスレータのチェーンを介して、パケットを受信したのと同じマルチキャストグループに誤ってパケットを転送する場合があります。その場合、異なるネットワークソースから発信された同じパケットが数回現れます。
o Two translators incorrectly set up in parallel, i.e., with the same multicast groups on both sides, would both forward packets from one multicast group to the other. Unidirectional translators would produce two copies; bidirectional translators would form a loop.
o 2つのトランスレータが誤って並列に設定された場合、つまり、両側に同じマルチキャストグループが存在する場合、どちらも1つのマルチキャストグループから別のマルチキャストグループにパケットを転送します。単方向トランスレータは2つのコピーを生成します。双方向トランスレータはループを形成します。
o A mixer can close a loop by sending to the same transport destination upon which it receives packets, either directly or through another mixer or translator. In this case a source might show up both as an SSRC on a data packet and a CSRC in a mixed data packet.
o ミキサーは、直接または別のミキサーまたはトランスレーターを介して、パケットを受信するのと同じトランスポート宛先に送信することにより、ループを閉じることができます。この場合、ソースは、データパケットではSSRCとして、混合データパケットではCSRCとして表示されます。
A source may discover that its own packets are being looped, or that packets from another source are being looped (a third-party loop). Both loops and collisions in the random selection of a source identifier result in packets arriving with the same SSRC identifier but a different source transport address, which may be that of the end system originating the packet or an intermediate system.
ソースは、自身のパケットがループしていること、または別のソースからのパケットがループしていること（サードパーティのループ）を発見する場合があります。ソース識別子のランダム選択におけるループと衝突の両方により、パケットは同じSSRC識別子で到着しますが、ソーストランスポートアドレスが異なります。これは、パケットを発信するエンドシステムまたは中間システムのアドレスである可能性があります。
Therefore, if a source changes its source transport address, it MAY also choose a new SSRC identifier to avoid being interpreted as a looped source. (This is not MUST because in some applications of RTP sources may be expected to change addresses during a session.) Note that if a translator restarts and consequently changes the source transport address (e.g., changes the UDP source port number) on which it forwards packets, then all those packets will appear to receivers to be looped because the SSRC identifiers are applied by the original source and will not change. This problem can be avoided by keeping the source transport address fixed across restarts, but in any case will be resolved after a timeout at the receivers.
したがって、ソースがそのソーストランスポートアドレスを変更する場合、ループされたソースとして解釈されないように、新しいSSRC識別子を選択することもできます（MAY）。 （RTPソースの一部のアプリケーションでは、セッション中にアドレスを変更することが予想されるため、これは必須ではありません。）トランスレーターが再起動し、その結果、転送するソーストランスポートアドレスを変更する場合（たとえば、UDPソースポート番号を変更する場合）に注意してください。パケットの場合、SSRC IDは元のソースによって適用され、変更されないため、これらのパケットはすべて、ループされているように受信者に表示されます。この問題は、再起動後もソーストランスポートアドレスを固定しておくことで回避できますが、いずれの場合も、レシーバーでのタイムアウト後に解決されます。
Loops or collisions occurring on the far side of a translator or mixer cannot be detected using the source transport address if all copies of the packets go through the translator or mixer, however, collisions may still be detected when chunks from two RTCP SDES packets contain the same SSRC identifier but different CNAMEs.
トランスレーターまたはミキサーの反対側で発生するループまたは衝突は、パケットのすべてのコピーがトランスレーターまたはミキサーを通過する場合、ソーストランスポートアドレスを使用して検出できません。ただし、2つのRTCP SDESパケットからのチャンクにSSRC識別子は同じですが、CNAMEが異なります。
To detect and resolve these conflicts, an RTP implementation MUST include an algorithm similar to the one described below, though the implementation MAY choose a different policy for which packets from colliding third-party sources are kept. The algorithm described below ignores packets from a new source or loop that collide with an established source. It resolves collisions with the participant's own SSRC identifier by sending an RTCP BYE for the old identifier and choosing a new one. However, when the collision was induced by a loop of the participant's own packets, the algorithm will choose a new identifier only once and thereafter ignore packets from the looping source transport address. This is required to avoid a flood of BYE packets.
これらの競合を検出して解決するために、RTP実装には、以下で説明するアルゴリズムと同様のアルゴリズムを含める必要があります（ただし、実装は、競合するサードパーティのソースからのパケットを保持するための別のポリシーを選択できます）以下で説明するアルゴリズムは、確立されたソースと衝突する新しいソースまたはループからのパケットを無視します。古い識別子のRTCP BYEを送信し、新しい識別子を選択することで、参加者自身のSSRC識別子との衝突を解決します。ただし、参加者自身のパケットのループによって衝突が引き起こされた場合、アルゴリズムは新しい識別子を1回だけ選択し、その後、ループしている送信元トランスポートアドレスからのパケットを無視します。これは、BYEパケットのフラッドを回避するために必要です。
This algorithm requires keeping a table indexed by the source identifier and containing the source transport addresses from the first RTP packet and first RTCP packet received with that identifier, along with other state for that source. Two source transport addresses are required since, for example, the UDP source port numbers may be different on RTP and RTCP packets. However, it may be assumed that the network address is the same in both source transport addresses.
このアルゴリズムでは、ソース識別子でインデックス付けされたテーブルを保持し、その識別子で受信した最初のRTPパケットと最初のRTCPパケットからのソーストランスポートアドレス、およびそのソースの他の状態を保持する必要があります。たとえば、RTPパケットとRTCPパケットではUDPソースポート番号が異なる場合があるため、2つのソーストランスポートアドレスが必要です。ただし、ネットワークアドレスが両方のソーストランスポートアドレスで同じであると想定される場合があります。
Each SSRC or CSRC identifier received in an RTP or RTCP packet is looked up in the source identifier table in order to process that data or control information. The source transport address from the packet is compared to the corresponding source transport address in the table to detect a loop or collision if they don't match. For control packets, each element with its own SSRC identifier, for example an SDES chunk, requires a separate lookup. (The SSRC identifier in a reception report block is an exception because it identifies a source heard by the reporter, and that SSRC identifier is unrelated to the source transport address of the RTCP packet sent by the reporter.) If the SSRC or CSRC is not found, a new entry is created. These table entries are removed when an RTCP BYE packet is received with the corresponding SSRC identifier and validated by a matching source transport address, or after no packets have arrived for a relatively long time (see Section 6.2.1).
RTPまたはRTCPパケットで受信された各SSRCまたはCSRC識別子は、そのデータまたは制御情報を処理するために、ソース識別子テーブルで検索されます。パケットのソーストランスポートアドレスは、テーブル内の対応するソーストランスポートアドレスと比較され、一致しない場合にループまたは衝突が検出されます。制御パケットの場合、独自のSSRC識別子を持つ各要素（SDESチャンクなど）には、個別のルックアップが必要です。 （レポーターが聞いたソースを識別し、そのSSRC識別子はレポーターが送信したRTCPパケットのソーストランスポートアドレスと無関係であるため、受信レポートブロックのSSRC識別子は例外です。）SSRCまたはCSRCが見つかった場合、新しいエントリが作成されます。これらのテーブルエントリは、対応するSSRC識別子を含むRTCP BYEパケットが受信され、一致するソーストランスポートアドレスによって検証された場合、または比較的長い時間パケットが到着しなかった場合に削除されます（セクション6.2.1を参照）。
Note that if two sources on the same host are transmitting with the same source identifier at the time a receiver begins operation, it would be possible that the first RTP packet received came from one of the sources while the first RTCP packet received came from the other. This would cause the wrong RTCP information to be associated with the RTP data, but this situation should be sufficiently rare and harmless that it may be disregarded.
同じホスト上の2つのソースが、受信機の動作開始時に同じソース識別子で送信している場合、最初に受信したRTPパケットが一方のソースから送信され、最初のRTCPパケットが他方から送信された可能性があります。 。これにより、誤ったRTCP情報がRTPデータに関連付けられることになりますが、この状況は十分にまれで無害であり、無視される可能性があります。
In order to track loops of the participant's own data packets, the implementation MUST also keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. As in the source identifier table, two source transport addresses MUST be kept to separately track conflicting RTP and RTCP packets. Note that the conflicting address list should be short, usually empty. Each element in this list stores the source addresses plus the time when the most recent conflicting packet was received. An element MAY be removed from the list when no conflicting packet has arrived from that source for a time on the order of 10 RTCP report intervals (see Section 6.2).
参加者自身のデータパケットのループを追跡するために、実装では、競合していることが判明したソーストランスポートアドレス（識別子ではない）の個別のリストも保持する必要があります。ソース識別子テーブルと同様に、競合するRTPパケットとRTCPパケットを個別に追跡するために、2つのソーストランスポートアドレスを保持する必要があります。競合するアドレスリストは短く、通常は空である必要があります。このリストの各要素には、送信元アドレスと、最新の競合するパケットが受信された時刻が格納されます。要素は、競合するパケットがそのソースから10 RTCPレポート間隔のオーダーでしばらくの間到着しなかった場合にリストから削除される場合があります（セクション6.2を参照）。
For the algorithm as shown, it is assumed that the participant's own source identifier and state are included in the source identifier table. The algorithm could be restructured to first make a separate comparison against the participant's own source identifier.
示されているアルゴリズムでは、参加者自身のソース識別子と状態がソース識別子テーブルに含まれていると想定されています。アルゴリズムを再構成して、最初に参加者自身のソース識別子と個別に比較することができます。
if (SSRC or CSRC identifier is not found in the source
identifier table) {
create a new entry storing the data or control source
transport address, the SSRC or CSRC and other state;
}
/* Identifier is found in the table */
else if (table entry was created on receipt of a control packet
and this is the first data packet or vice versa) {
store the source transport address from this packet;
}
else if (source transport address from the packet does not match
the one saved in the table entry for this identifier) {
/* An identifier collision or a loop is indicated */
if (source identifier is not the participant's own) {
/* OPTIONAL error counter step */
if (source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry) {
count a third-party collision;
} else {
count a third-party loop;
}
abort processing of data packet or control element;
/* MAY choose a different policy to keep new source */
}
/* A collision or loop of the participant's own packets */
else if (source transport address is found in the list of
conflicting data or control source transport
addresses) {
/* OPTIONAL error counter step */
if (source identifier is not from an RTCP SDES chunk
containing a CNAME item or CNAME is the
participant's own) {
count occurrence of own traffic looped;
}
mark current time in conflicting address list entry;
abort processing of data packet or control element;
}
/* New collision, change SSRC identifier */
else {
log occurrence of a collision;
create a new entry in the conflicting data or control
source transport address list and mark current time;
send an RTCP BYE packet with the old SSRC identifier;
choose a new SSRC identifier;
create a new entry in the source identifier table with
the old SSRC plus the source transport address from
the data or control packet being processed;
}
}
In this algorithm, packets from a newly conflicting source address will be ignored and packets from the original source address will be kept. If no packets arrive from the original source for an extended period, the table entry will be timed out and the new source will be able to take over. This might occur if the original source detects the collision and moves to a new source identifier, but in the usual case an RTCP BYE packet will be received from the original source to delete the state without having to wait for a timeout.
このアルゴリズムでは、新しく競合する送信元アドレスからのパケットは無視され、元の送信元アドレスからのパケットは保持されます。元のソースから長期間パケットが到着しない場合、テーブルエントリがタイムアウトし、新しいソースが引き継ぐことができます。これは、元のソースが衝突を検出して新しいソース識別子に移動した場合に発生する可能性がありますが、通常の場合、RTCP BYEパケットが元のソースから受信され、タイムアウトを待たずに状態を削除します。
If the original source address was received through a mixer (i.e., learned as a CSRC) and later the same source is received directly, the receiver may be well advised to switch to the new source address unless other sources in the mix would be lost. Furthermore, for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session, the RTP implementation SHOULD modify the collision detection algorithm to accept packets from the new source transport address. To guard against flip-flopping between addresses if a genuine collision does occur, the algorithm SHOULD include some means to detect this case and avoid switching.
元のソースアドレスがミキサーを介して受信された場合（つまり、CSRCとして学習）、後で同じソースが直接受信された場合、ミックス内の他のソースが失われない限り、受信者は新しいソースアドレスに切り替えることをお勧めします。さらに、RTPセッション中にモバイルエンティティなどの一部のソースがアドレスを変更する可能性があるテレフォニーなどのアプリケーションの場合、RTP実装は、衝突検出アルゴリズムを変更して、新しいソーストランスポートアドレスからのパケットを受け入れる必要があります。本物の衝突が発生した場合にアドレス間のフリップフロップを防ぐために、アルゴリズムには、このケースを検出して切り替えを回避する手段が含まれている必要があります（SHOULD）。
When a new SSRC identifier is chosen due to a collision, the candidate identifier SHOULD first be looked up in the source identifier table to see if it was already in use by some other source. If so, another candidate MUST be generated and the process repeated.
衝突が原因で新しいSSRC識別子が選択された場合、候補識別子は最初にソース識別子テーブルで検索され、他のソースによってすでに使用されているかどうかを確認する必要があります。その場合は、別の候補を生成し、プロセスを繰り返す必要があります。
A loop of data packets to a multicast destination can cause severe network flooding. All mixers and translators MUST implement a loop detection algorithm like the one here so that they can break loops. This should limit the excess traffic to no more than one duplicate copy of the original traffic, which may allow the session to continue so that the cause of the loop can be found and fixed. However, in extreme cases where a mixer or translator does not properly break the loop and high traffic levels result, it may be necessary for end systems to cease transmitting data or control packets entirely. This decision may depend upon the application. An error condition SHOULD be indicated as appropriate. Transmission MAY be attempted again periodically after a long, random time (on the order of minutes).
マルチキャスト宛先へのデータパケットのループは、深刻なネットワークフラッディングを引き起こす可能性があります。すべてのミキサーとトランスレーターは、ループを中断できるように、ここに示すようなループ検出アルゴリズムを実装する必要があります。これにより、過剰なトラフィックが元のトラフィックの複製コピーを1つだけに制限するはずです。これにより、セッションを続行できるため、ループの原因を見つけて修正できます。ただし、ミキサーまたはトランスレーターがループを適切に中断せず、高トラフィックレベルが発生する極端なケースでは、エンドシステムがデータまたは制御パケットの送信を完全に停止する必要がある場合があります。この決定は、アプリケーションによって異なります。必要に応じて、エラー状態を示す必要があります。ランダムな長い時間（分単位）の後、定期的に送信が再試行される場合があります。
8.3 Use with Layered Encodings
8.3階層化エンコーディングでの使用
For layered encodings transmitted on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution. When a source discovers that it has collided, it transmits an RTCP BYE packet on only the base layer but changes the SSRC identifier to the new value in all layers.
個別のRTPセッション（セクション2.4を参照）で送信されるレイヤードエンコーディングの場合、すべてのレイヤーのセッション全体で単一のSSRC識別子スペースを使用する必要があり（SHOULD）、コア（ベース）レイヤーをSSRC識別子の割り当てと衝突解決に使用する必要があります（SHOULD）。ソースは、衝突したことを検出すると、ベースレイヤーのみでRTCP BYEパケットを送信しますが、SSRC識別子をすべてのレイヤーの新しい値に変更します。
Lower layer protocols may eventually provide all the security services that may be desired for applications of RTP, including authentication, integrity, and confidentiality. These services have been specified for IP in [27]. Since the initial audio and video applications using RTP needed a confidentiality service before such services were available for the IP layer, the confidentiality service described in the next section was defined for use with RTP and RTCP. That description is included here to codify existing practice. New applications of RTP MAY implement this RTP-specific confidentiality service for backward compatibility, and/or they MAY implement alternative security services. The overhead on the RTP protocol for this confidentiality service is low, so the penalty will be minimal if this service is obsoleted by other services in the future.
下位層プロトコルは、認証、整合性、機密性など、RTPのアプリケーションに必要なすべてのセキュリティサービスを最終的に提供する可能性があります。これらのサービスは[27]でIPに対して指定されています。 RTPを使用する最初のオーディオおよびビデオアプリケーションでは、IPレイヤーで機密サービスが利用可能になる前に機密サービスが必要だったため、次のセクションで説明する機密サービスは、RTPおよびRTCPで使用するために定義されました。その説明は、既存の慣行を成文化するためにここに含まれています。 RTPの新しいアプリケーションは、下位互換性のためにこのRTP固有の機密性サービスを実装する場合があります。また、代替のセキュリティサービスを実装する場合もあります。この機密性サービスのRTPプロトコルのオーバーヘッドは低いため、このサービスが将来他のサービスによって廃止される場合のペナルティは最小限になります。
Alternatively, other services, other implementations of services and other algorithms may be defined for RTP in the future. In particular, an RTP profile called Secure Real-time Transport Protocol (SRTP) [28] is being developed to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that link-level header compression algorithms can still operate. It is expected that SRTP will be the correct choice for many applications. SRTP is based on the Advanced Encryption Standard (AES) and provides stronger security than the service described here. No claim is made that the methods presented here are appropriate for a particular security need. A profile may specify which services and algorithms should be offered by applications, and may provide guidance as to their appropriate use.
あるいは、他のサービス、サービスの他の実装、および他のアルゴリズムは、将来のRTPに対して定義される可能性があります。特に、セキュアリアルタイムトランスポートプロトコル（SRTP）[28]と呼ばれるRTPプロファイルは、RTPペイロードの機密性を提供するために開発されており、リンクレベルのヘッダー圧縮アルゴリズムが引き続き動作できるようにRTPヘッダーをクリアのままにします。 SRTPは多くのアプリケーションにとって正しい選択となることが期待されています。 SRTPはAdvanced Encryption Standard（AES）に基づいており、ここで説明するサービスよりも強力なセキュリティを提供します。ここで紹介する方法が特定のセキュリティのニーズに適しているという主張はありません。プロファイルは、アプリケーションによって提供されるサービスとアルゴリズムを指定し、適切な使用に関するガイダンスを提供します。
Key distribution and certificates are outside the scope of this document.
鍵の配布と証明書は、このドキュメントの範囲外です。
9.1 Confidentiality
9.1守秘義務
Confidentiality means that only the intended receiver(s) can decode the received packets; for others, the packet contains no useful information. Confidentiality of the content is achieved by encryption.
機密性とは、意図した受信者のみが受信したパケットをデコードできることを意味します。その他の場合、パケットには有用な情報が含まれていません。コンテンツの機密性は暗号化によって実現されます。
When it is desired to encrypt RTP or RTCP according to the method specified in this section, all the octets that will be encapsulated for transmission in a single lower-layer packet are encrypted as a unit. For RTCP, a 32-bit random number redrawn for each unit MUST be prepended to the unit before encryption. For RTP, no prefix is prepended; instead, the sequence number and timestamp fields are initialized with random offsets. This is considered to be a weak initialization vector (IV) because of poor randomness properties. In addition, if the subsequent field, the SSRC, can be manipulated by an enemy, there is further weakness of the encryption method.
このセクションで指定された方法に従ってRTPまたはRTCPを暗号化する必要がある場合、単一の下位層パケットでの送信用にカプセル化されるすべてのオクテットは、1つの単位として暗号化されます。 RTCPの場合、暗号化する前に、ユニットごとに32ビットの乱数を再描画する必要があります。 RTPの場合、接頭辞は付加されません。代わりに、シーケンス番号とタイムスタンプのフィールドはランダムなオフセットで初期化されます。ランダム性のプロパティが低いため、これは弱い初期化ベクトル（IV）と見なされます。さらに、後続のフィールドであるSSRCが敵によって操作される可能性がある場合、暗号化方式のさらなる弱点があります。
For RTCP, an implementation MAY segregate the individual RTCP packets in a compound RTCP packet into two separate compound RTCP packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors that are not privy to the encryption key. In this example, depicted in Fig. 4, the SDES information MUST be appended to an RR packet with no reports (and the random number) to satisfy the requirement that all compound RTCP packets begin with an SR or RR packet. The SDES CNAME item is required in either the encrypted or unencrypted packet, but not both. The same SDES information SHOULD NOT be carried in both packets as this may compromise the encryption.
RTCPの場合、実装は、複合RTCPパケット内の個々のRTCPパケットを2つの別々の複合RTCPパケットに分離できます（1つは暗号化され、もう1つはクリアテキストで送信されます）。たとえば、暗号化キーを知らないサードパーティのモニターに対応するために、受信レポートが平文で送信されている間にSDES情報が暗号化される場合があります。図4に示すこの例では、すべての複合RTCPパケットがSRまたはRRパケットで始まるという要件を満たすために、SDES情報をレポート（および乱数）なしでRRパケットに追加する必要があります。 SDES CNAME項目は、暗号化されたパケットまたは暗号化されていないパケットのいずれかで必要ですが、両方では必要ありません。暗号化を危険にさらす可能性があるため、同じSDES情報を両方のパケットで送信しないでください。
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
#: SSRC identifier
＃：SSRC識別子
Figure 4: Encrypted and non-encrypted RTCP packets
図4：暗号化されたRTCPパケットと暗号化されていないRTCPパケット
The presence of encryption and the use of the correct key are confirmed by the receiver through header or payload validity checks. Examples of such validity checks for RTP and RTCP headers are given in Appendices A.1 and A.2.
暗号化の存在と正しいキーの使用は、ヘッダーまたはペイロードの有効性チェックを通じて受信者によって確認されます。 RTPおよびRTCPヘッダーのそのような有効性チェックの例は、付録A.1およびA.2に記載されています。
To be consistent with existing implementations of the initial specification of RTP in RFC 1889, the default encryption algorithm is the Data Encryption Standard (DES) algorithm in cipher block chaining (CBC) mode, as described in Section 1.1 of RFC 1423 [29], except that padding to a multiple of 8 octets is indicated as described for the P bit in Section 5.1. The initialization vector is zero because random values are supplied in the RTP header or by the random prefix for compound RTCP packets. For details on the use of CBC initialization vectors, see [30].
RFC 1489 [29]のセクション1.1で説明されているように、RFC 1889のRTPの初期仕様の既存の実装と整合性を保つために、デフォルトの暗号化アルゴリズムは暗号ブロック連鎖（CBC）モードのデータ暗号化標準（DES）アルゴリズムです。ただし、8オクテットの倍数へのパディングは、セクション5.1のPビットで説明されているように示されます。ランダムな値はRTPヘッダーで提供されるか、複合RTCPパケットのランダムなプレフィックスによって提供されるため、初期化ベクトルはゼロです。 CBC初期化ベクトルの使用の詳細については、[30]を参照してください。
Implementations that support the encryption method specified here SHOULD always support the DES algorithm in CBC mode as the default cipher for this method to maximize interoperability. This method was chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet. However, DES has since been found to be too easily broken.
ここで指定する暗号化方式をサポートする実装は、相互運用性を最大化するために、この方式のデフォルトの暗号としてCBCモードのDESアルゴリズムを常にサポートする必要があります（SHOULD）。この方法が選択されたのは、インターネットで運用されている実験的なオーディオおよびビデオツールでの使用が簡単で実用的であることが実証されているためです。ただし、DESは簡単に壊れてしまうことが判明しています。
It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm. Furthermore, secure CBC mode requires that the first block of each packet be XORed with a random, independent IV of the same size as the cipher's block size. For RTCP, this is (partially) achieved by prepending each packet with a 32-bit random number, independently chosen for each packet. For RTP, the timestamp and sequence number start from random values, but consecutive packets will not be independently randomized. It should be noted that the randomness in both cases (RTP and RTCP) is limited. High-security applications SHOULD consider other, more conventional, protection means. Other encryption algorithms MAY be specified dynamically for a session by non-RTP means. In particular, the SRTP profile [28] based on AES is being developed to take into account known plaintext and CBC plaintext manipulation concerns, and will be the correct choice in the future.
デフォルトのアルゴリズムの代わりに、Triple-DESなどのより強力な暗号化アルゴリズムを使用することをお勧めします。さらに、セキュアCBCモードでは、各パケットの最初のブロックを、暗号のブロックサイズと同じサイズのランダムな独立したIVとXORする必要があります。 RTCPの場合、これは（部分的に）各パケットに個別に選択された32ビットの乱数を各パケットの先頭に追加することで実現されます。 RTPの場合、タイムスタンプとシーケンス番号はランダムな値から始まりますが、連続するパケットは個別にランダム化されません。どちらの場合（RTPとRTCP）のランダム性にも制限があることに注意してください。高セキュリティアプリケーションは、他のより一般的な保護手段を検討する必要があります。他の暗号化アルゴリズムは、RTP以外の方法でセッションに対して動的に指定できます。特に、AESに基づくSRTPプロファイル[28]は、既知の平文およびCBC平文操作の懸念を考慮に入れて開発されており、将来的には正しい選択になるでしょう。
As an alternative to encryption at the IP level or at the RTP level as described above, profiles MAY define additional payload types for encrypted encodings. Those encodings MUST specify how padding and other aspects of the encryption are to be handled. This method allows encrypting only the data while leaving the headers in the clear for applications where that is desired. It may be particularly useful for hardware devices that will handle both decryption and decoding. It is also valuable for applications where link-level compression of RTP and lower-layer headers is desired and confidentiality of the payload (but not addresses) is sufficient since encryption of the headers precludes compression.
上記のIPレベルまたはRTPレベルでの暗号化の代替として、プロファイルは、暗号化されたエンコーディングの追加のペイロードタイプを定義する場合があります。それらのエンコーディングは、パディングおよび暗号化の他の側面の処理方法を指定する必要があります。この方法では、必要なアプリケーションでヘッダーをクリアなままにして、データのみを暗号化できます。これは、復号化と復号化の両方を処理するハードウェアデバイスに特に役立ちます。また、RTPと下位層ヘッダーのリンクレベルの圧縮が必要であり、ヘッダーの暗号化によって圧縮が妨げられるため、ペイロード（ただしアドレスではない）の機密性で十分なアプリケーションにも役立ちます。
9.2 Authentication and Message Integrity
9.2認証とメッセージの整合性
Authentication and message integrity services are not defined at the RTP level since these services would not be directly feasible without a key management infrastructure. It is expected that authentication and integrity services will be provided by lower layer protocols.
認証およびメッセージ整合性サービスはRTPレベルで定義されていません。これらのサービスは、キー管理インフラストラクチャなしでは直接実現できないためです。認証および整合性サービスは、下位層プロトコルによって提供されることが期待されています。
All transport protocols used on the Internet need to address congestion control in some way [31]. RTP is not an exception, but because the data transported over RTP is often inelastic (generated at a fixed or controlled rate), the means to control congestion in RTP may be quite different from those for other transport protocols such as TCP. In one sense, inelasticity reduces the risk of congestion because the RTP stream will not expand to consume all available bandwidth as a TCP stream can. However, inelasticity also means that the RTP stream cannot arbitrarily reduce its load on the network to eliminate congestion when it occurs.
インターネットで使用されるすべてのトランスポートプロトコルは、何らかの方法で輻輳制御に対処する必要があります[31]。 RTPも例外ではありませんが、RTPを介して転送されるデータは非弾性（固定レートまたは制御レートで生成される）が多いため、RTPの輻輳を制御する方法は、TCPなどの他の転送プロトコルの場合とはかなり異なる場合があります。ある意味では、RTPストリームはTCPストリームのようにすべての利用可能な帯域幅を消費するように拡張されないため、非弾性は輻輳のリスクを軽減します。ただし、非弾性とは、RTPストリームが発生したときに輻輳を解消するためにネットワークの負荷を任意に減らすことができないことも意味します。
Since RTP may be used for a wide variety of applications in many different contexts, there is no single congestion control mechanism that will work for all. Therefore, congestion control SHOULD be defined in each RTP profile as appropriate. For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required.
RTPは多くの異なるコンテキストでさまざまなアプリケーションに使用できるため、すべてに対して機能する単一の輻輳制御メカニズムはありません。したがって、輻輳制御は、必要に応じて各RTPプロファイルで定義する必要があります（SHOULD）。一部のプロファイルでは、エンジニアリングによって輻輳が回避される環境にそのプロファイルの使用を制限する適用性ステートメントを含めるだけで十分な場合があります。他のプロファイルの場合、RTCPフィードバックに基づくデータレート適応などの特定の方法が必要になる場合があります。
This section describes issues specific to carrying RTP packets within particular network and transport protocols. The following rules apply unless superseded by protocol-specific definitions outside this specification.
このセクションでは、特定のネットワークおよびトランスポートプロトコル内でのRTPパケットの伝送に固有の問題について説明します。この仕様外のプロトコル固有の定義に置き換えられない限り、次のルールが適用されます。
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams.
RTPは、基になるプロトコルに依存して、RTPデータとRTCP制御ストリームの逆多重化を提供します。 UDPおよび同様のプロトコルの場合、RTPは偶数の宛先ポート番号を使用する必要があり（SHOULD）、対応するRTCPストリームは次に大きい（奇数）宛先ポート番号を使用する必要があります（SHOULD）。単一のポート番号をパラメーターとして受け取り、その番号からRTPとRTCPのポートのペアを取得するアプリケーションの場合、奇数が指定された場合、アプリケーションはその番号を次に低い（偶数）番号に置き換えて、そのベースとして使用する必要があります（SHOULD）。ポートペア。 RTPとRTCPの宛先ポート番号が明示的で別個のパラメーター（シグナリングプロトコルまたはその他の手段を使用）で指定されているアプリケーションの場合、アプリケーションは、ポート番号が偶数/奇数で連続しているという制限を無視してもかまいません/ oddポートペアは引き続き推奨されます。 RTPはRTPデータとRTCP制御ストリームを逆多重化するためにポート番号に依存しているため、RTPとRTCPのポート番号は同じにしないでください。
In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets. Both participants MAY use the same port pair. A participant MUST NOT assume that the source port of the incoming RTP or RTCP packet can be used as the destination port for outgoing RTP or RTCP packets. When RTP data packets are being sent in both directions, each participant's RTCP SR packets MUST be sent to the port that the other participant has specified for reception of RTCP. The RTCP SR packets combine sender information for the outgoing data plus reception report information for the incoming data. If a side is not actively sending data (see Section 6.4), an RTCP RR packet is sent instead.
ユニキャストセッションでは、両方の参加者がRTPおよびRTCPパケットを受信するためのポートペアを識別する必要があります。両方の参加者が同じポートペアを使用する場合があります。参加者は、着信RTPまたはRTCPパケットのソースポートが発信RTPまたはRTCPパケットの宛先ポートとして使用できると想定してはなりません（MUST NOT）。 RTPデータパケットが両方向で送信されている場合、各参加者のRTCP SRパケットは、他の参加者がRTCPの受信用に指定したポートに送信する必要があります。 RTCP SRパケットは、発信データの送信者情報と着信データの受信レポート情報を組み合わせます。サイドがアクティブにデータを送信していない場合（セクション6.4を参照）、代わりにRTCP RRパケットが送信されます。
It is RECOMMENDED that layered encoding applications (see Section 2.4) use a set of contiguous port numbers. The port numbers MUST be distinct because of a widespread deficiency in existing operating systems that prevents use of the same port with multiple multicast addresses, and for unicast, there is only one permissible address. Thus for layer n, the data port is P + 2n, and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct because multicast routing and group membership are managed on an address granularity. However, allocation of contiguous IP multicast addresses cannot be assumed because some groups may require different scopes and may therefore be allocated from different address ranges.
レイヤードエンコーディングアプリケーション（セクション2.4を参照）では、一連の連続したポート番号を使用することをお勧めします。複数のマルチキャストアドレスで同じポートを使用できない既存のオペレーティングシステムの欠陥のため、ポート番号は異なる必要があります。ユニキャストの場合、許可されるアドレスは1つだけです。したがって、レイヤーnの場合、データポートはP + 2nで、制御ポートはP + 2n + 1です。IPマルチキャストを使用する場合、マルチキャストルーティングとグループメンバーシップはアドレスの細分性で管理されるため、アドレスも異なる必要があります。ただし、一部のグループには異なるスコープが必要な場合があり、したがって異なるアドレス範囲から割り当てられる場合があるため、連続したIPマルチキャストアドレスの割り当ては想定できません。
The previous paragraph conflicts with the SDP specification, RFC 2327 [15], which says that it is illegal for both multiple addresses and multiple ports to be specified in the same session description because the association of addresses with ports could be ambiguous. It is intended that this restriction will be relaxed in a revision of RFC 2327 to allow an equal number of addresses and ports to be specified with a one-to-one mapping implied.
前の段落は、SDP仕様、RFC 2327 [15]と競合します。RFC2327 [15]は、アドレスとポートの関連付けがあいまいになる可能性があるため、同じセッションの説明で複数のアドレスと複数のポートの両方を指定することは違法であると述べています。この制限は、RFC 2327の改訂版で緩和され、同数のアドレスとポートを1対1のマッピングを指定して指定できるようにすることを目的としています。
RTP data packets contain no length field or other delineation, therefore RTP relies on the underlying protocol(s) to provide a length indication. The maximum length of RTP packets is limited only by the underlying protocols.
RTPデータパケットには、長さフィールドやその他の説明が含まれていないため、RTPは長さを示すために、基礎となるプロトコルに依存しています。 RTPパケットの最大長は、基になるプロトコルによってのみ制限されます。
If RTP packets are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation of the RTP packets MUST be defined to provide a framing mechanism. Framing is also needed if the underlying protocol may contain padding so that the extent of the RTP payload cannot be determined. The framing mechanism is not defined here.
RTPパケットが、メッセージ（パケット）ではなく連続オクテットストリームの抽象化を提供する基になるプロトコルで運ばれる場合は、RTPパケットのカプセル化を定義して、フレーミングメカニズムを提供する必要があります。基になるプロトコルにパディングが含まれている可能性があり、RTPペイロードの範囲を決定できない場合は、フレーミングも必要です。フレーミングのメカニズムはここでは定義されていません。
A profile MAY specify a framing method to be used even when RTP is carried in protocols that do provide framing in order to allow carrying several RTP packets in one lower-layer protocol data unit, such as a UDP packet. Carrying several RTP packets in one network or transport packet reduces header overhead and may simplify synchronization between different streams.
UDPパケットなど、1つの下位層プロトコルデータユニットで複数のRTPパケットを伝送できるようにするために、フレーミングを提供するプロトコルでRTPが伝送される場合でも、プロファイルは使用するフレーミング方法を指定する場合があります。 1つのネットワークまたはトランスポートパケットで複数のRTPパケットを伝送すると、ヘッダーのオーバーヘッドが減少し、異なるストリーム間の同期が簡略化される場合があります。
This section contains a summary listing of the constants defined in this specification.
このセクションには、この仕様で定義されている定数の要約リストが含まれています。
The RTP payload type (PT) constants are defined in profiles rather than this document. However, the octet of the RTP header which contains the marker bit(s) and payload type MUST avoid the reserved values 200 and 201 (decimal) to distinguish RTP packets from the RTCP SR and RR packet types for the header validation procedure described in Appendix A.1. For the standard definition of one marker bit and a 7-bit payload type field as shown in this specification, this restriction means that payload types 72 and 73 are reserved.
RTPペイロードタイプ（PT）定数は、このドキュメントではなくプロファイルで定義されています。ただし、マーカービットとペイロードタイプを含むRTPヘッダーのオクテットは、予約済みの値200と201（10進数）を避けて、付録で説明されているヘッダー検証手順でRTPパケットをRTCP SRおよびRRパケットタイプから区別する必要があります。 A.1。この仕様に示されている1つのマーカービットと7ビットのペイロードタイプフィールドの標準定義では、この制限はペイロードタイプ72と73が予約されていることを意味します。
12.1 RTCP Packet Types
12.1 RTCPパケットタイプ
abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204
略語。名前値SR送信者レポート200 RR受信者レポート201 SDESソースの説明202 BYEさようなら203 APPアプリケーション定義204
These type values were chosen in the range 200-204 for improved header validity checking of RTCP packets compared to RTP packets or other unrelated packets. When the RTCP packet type field is compared to the corresponding octet of the RTP header, this range corresponds to the marker bit being 1 (which it usually is not in data packets) and to the high bit of the standard payload type field being 1 (since the static payload types are typically defined in the low half). This range was also chosen to be some distance numerically from 0 and 255 since all-zeros and all-ones are common data patterns.
これらのタイプの値は、RTPパケットまたは他の無関係なパケットと比較してRTCPパケットのヘッダー有効性チェックを改善するために200〜204の範囲で選択されました。 RTCPパケットタイプフィールドをRTPヘッダーの対応するオクテットと比較すると、この範囲はマーカービットが1（通常はデータパケットにはない）であり、標準ペイロードタイプフィールドの高ビットが1（静的ペイロードタイプは通常、下半分で定義されているため）。すべて0と1は一般的なデータパターンであるため、この範囲は数値的に0〜255の距離になるように選択されました。
Since all compound RTCP packets MUST begin with SR or RR, these codes were chosen as an even/odd pair to allow the RTCP validity check to test the maximum number of bits with mask and value.
すべての複合RTCPパケットはSRまたはRRで始まる必要があるため、これらのコードは偶数/奇数のペアとして選択され、RTCP有効性チェックでマスクと値を使用してビットの最大数をテストできるようにしました。
Additional RTCP packet types may be registered through IANA (see Section 15).
IANAを通じて追加のRTCPパケットタイプを登録できます（セクション15を参照）。
12.2 SDES Types
12.2ここのトープ
abbrev. name value END end of SDES list 0 CNAME canonical name 1 NAME user name 2 EMAIL user's electronic mail address 3 PHONE user's phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8
略語。名前値END SDESリストの終わり0 CNAME正規名1 NAMEユーザー名2 EMAILユーザーの電子メールアドレス3 PHONEユーザーの電話番号4 LOC地理的ユーザーの場所5アプリケーションまたはツールのTOOL名6ソースに関する注記7 PRIVプライベート拡張8
Additional SDES types may be registered through IANA (see Section 15).
IANAを通じて追加のSDESタイプを登録できます（セクション15を参照）。
A complete specification of RTP for a particular application will require one or more companion documents of two types described here: profiles, and payload format specifications.
特定のアプリケーションのRTPの完全な仕様には、ここで説明する2つのタイプの1つ以上の関連ドキュメントが必要です。プロファイルとペイロード形式の仕様です。
RTP may be used for a variety of applications with somewhat differing requirements. The flexibility to adapt to those requirements is provided by allowing multiple choices in the main protocol specification, then selecting the appropriate choices or defining extensions for a particular environment and class of applications in a separate profile document. Typically an application will operate under only one profile in a particular RTP session, so there is no explicit indication within the RTP protocol itself as to which profile is in use. A profile for audio and video applications may be found in the companion RFC 3551. Profiles are typically titled "RTP Profile for ...".
RTPは、要件が多少異なるさまざまなアプリケーションに使用できます。これらの要件に適応する柔軟性は、メインプロトコル仕様で複数の選択肢を許可し、適切な選択肢を選択するか、特定の環境とアプリケーションのクラスの拡張機能を別のプロファイルドキュメントで定義することによって提供されます。通常、アプリケーションは特定のRTPセッションの1つのプロファイルのみで動作するため、RTPプロトコル自体の中で、どのプロファイルが使用されているかを明示的に示すものはありません。オーディオおよびビデオアプリケーションのプロファイルは、関連するRFC 3551にあります。プロファイルのタイトルは通常、「RTP Profile for ...」です。
The second type of companion document is a payload format specification, which defines how a particular kind of payload data, such as H.261 encoded video, should be carried in RTP. These documents are typically titled "RTP Payload Format for XYZ Audio/Video Encoding". Payload formats may be useful under multiple profiles and may therefore be defined independently of any particular profile. The profile documents are then responsible for assigning a default mapping of that format to a payload type value if needed.
コンパニオンドキュメントの2番目のタイプは、H.261エンコードされたビデオなどの特定の種類のペイロードデータをRTPでどのように伝送するかを定義するペイロード形式仕様です。これらのドキュメントのタイトルは通常、「XYZ Audio / Video EncodingのRTPペイロード形式」です。ペイロード形式は複数のプロファイルで役立つ場合があるため、特定のプロファイルとは無関係に定義できます。プロファイルドキュメントは、必要に応じて、その形式のデフォルトマッピングをペイロードタイプ値に割り当てる責任があります。
Within this specification, the following items have been identified for possible definition within a profile, but this list is not meant to be exhaustive:
この仕様では、プロファイル内で可能な定義のために次の項目が識別されていますが、このリストは完全なものではありません。
RTP data header: The octet in the RTP data header that contains the marker bit and payload type field MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits (Section 5.3, p. 18).
RTPデータヘッダー：マーカービットとペイロードタイプフィールドを含むRTPデータヘッダーのオクテットは、たとえばマーカービットの数が多い場合や少ない場合など、さまざまな要件に合わせてプロファイルで再定義できます（セクション5.3、p。18）。
Payload types: Assuming that a payload type field is included, the profile will usually define a set of payload formats (e.g., media encodings) and a default static mapping of those formats to payload type values. Some of the payload formats may be defined by reference to separate payload format specifications. For each payload type defined, the profile MUST specify the RTP timestamp clock rate to be used (Section 5.1, p. 14).
ペイロードタイプ：ペイロードタイプフィールドが含まれていると仮定すると、プロファイルは通常、一連のペイロードフォーマット（メディアエンコーディングなど）と、それらのフォーマットからペイロードタイプ値へのデフォルトの静的マッピングを定義します。一部のペイロード形式は、個別のペイロード形式の仕様を参照することで定義できます。定義されたペイロードタイプごとに、プロファイルは、使用するRTPタイムスタンプクロックレートを指定する必要があります（セクション5.1、p。14）。
RTP data header additions: Additional fields MAY be appended to the fixed RTP data header if some additional functionality is required across the profile's class of applications independent of payload type (Section 5.3, p. 18).
RTPデータヘッダーの追加：ペイロードタイプに関係なく、プロファイルのアプリケーションのクラス全体で追加の機能が必要な場合は、追加のフィールドを固定RTPデータヘッダーに追加できます（セクション5.3、18ページ）。
RTP data header extensions: The contents of the first 16 bits of the RTP data header extension structure MUST be defined if use of that mechanism is to be allowed under the profile for implementation-specific extensions (Section 5.3.1, p. 18).
RTPデータヘッダー拡張：RTPデータヘッダー拡張構造の最初の16ビットの内容は、そのメカニズムの使用を実装固有の拡張のプロファイルで許可する場合に定義する必要があります（セクション5.3.1、p。18）。
RTCP packet types: New application-class-specific RTCP packet types MAY be defined and registered with IANA.
RTCPパケットタイプ：新しいアプリケーションクラス固有のRTCPパケットタイプを定義し、IANAに登録できます。
RTCP report interval: A profile SHOULD specify that the values suggested in Section 6.2 for the constants employed in the calculation of the RTCP report interval will be used. Those are the RTCP fraction of session bandwidth, the minimum report interval, and the bandwidth split between senders and receivers. A profile MAY specify alternate values if they have been demonstrated to work in a scalable manner.
RTCPレポート間隔：プロファイルは、RTCPレポート間隔の計算に使用される定数についてセクション6.2で提案された値が使用されることを指定する必要があります（SHOULD）。これらは、セッション帯域幅のRTCP部分、最小レポート間隔、および送信者と受信者の間で分割された帯域幅です。それらがスケーラブルな方法で機能することが実証されている場合、プロファイルは代替値を指定してもよい（MAY）。
SR/RR extension: An extension section MAY be defined for the RTCP SR and RR packets if there is additional information that should be reported regularly about the sender or receivers (Section 6.4.3, p. 42 and 43).
SR / RR拡張：送信者または受信者について定期的に報告する必要がある追加情報がある場合は、RTCP SRおよびRRパケットの拡張セクションを定義できます（セクション6.4.3、42ページおよび43ページ）。
SDES use: The profile MAY specify the relative priorities for RTCP SDES items to be transmitted or excluded entirely (Section 6.3.9); an alternate syntax or semantics for the CNAME item (Section 6.5.1); the format of the LOC item (Section 6.5.5); the semantics and use of the NOTE item (Section 6.5.7); or new SDES item types to be registered with IANA.
SDESの使用：プロファイルは、送信または完全に除外するRTCP SDESアイテムの相対的な優先度を指定してもよい（セクション6.3.9）。 CNAMEアイテムの代替の構文またはセマンティクス（6.5.1節）。 LOCアイテムの形式（セクション6.5.5）。 NOTEアイテムのセマンティクスと使用（セクション6.5.7）。または、IANAに登録される新しいSDESアイテムタイプ。
Security: A profile MAY specify which security services and algorithms should be offered by applications, and MAY provide guidance as to their appropriate use (Section 9, p. 65).
セキュリティ：プロファイルは、アプリケーションによって提供されるセキュリティサービスとアルゴリズムを指定することができ（MAY）、それらの適切な使用に関するガイダンスを提供することができます（セクション9、65ページ）。
String-to-key mapping: A profile MAY specify how a user-provided password or pass phrase is mapped into an encryption key.
文字列からキーへのマッピング：プロファイルは、ユーザー指定のパスワードまたはパスフレーズを暗号化キーにマップする方法を指定する場合があります。
Congestion: A profile SHOULD specify the congestion control behavior appropriate for that profile.
輻輳：プロファイルは、そのプロファイルに適切な輻輳制御動作を指定する必要があります（SHOULD）。
Underlying protocol: Use of a particular underlying network or transport layer protocol to carry RTP packets MAY be required.
基礎となるプロトコル：RTPパケットを伝送するための特定の基礎となるネットワークまたはトランスポート層プロトコルの使用が必要になる場合があります。
Transport mapping: A mapping of RTP and RTCP to transport-level addresses, e.g., UDP ports, other than the standard mapping defined in Section 11, p. 68 may be specified.
トランスポートマッピング：セクション11で定義されている標準マッピング以外のトランスポートレベルアドレス（UDPポートなど）へのRTPおよびRTCPのマッピング。 68を指定できます。
Encapsulation: An encapsulation of RTP packets may be defined to allow multiple RTP data packets to be carried in one lower-layer packet or to provide framing over underlying protocols that do not already do so (Section 11, p. 69).
カプセル化：RTPパケットのカプセル化を定義して、複数のRTPデータパケットを1つの下位層パケットで伝送したり、まだ実装されていない基礎となるプロトコルでフレーミングを提供したりできます（セクション11、69ページ）。
It is not expected that a new profile will be required for every application. Within one application class, it would be better to extend an existing profile rather than make a new one in order to facilitate interoperation among the applications since each will typically run under only one profile. Simple extensions such as the definition of additional payload type values or RTCP packet types may be accomplished by registering them through IANA and publishing their descriptions in an addendum to the profile or in a payload format specification.
すべてのアプリケーションに新しいプロファイルが必要になることは想定されていません。 1つのアプリケーションクラス内では、通常、それぞれが1つのプロファイルでのみ実行されるため、アプリケーション間の相互運用を容易にするために、新しいプロファイルを作成するよりも、既存のプロファイルを拡張する方が適切です。追加のペイロードタイプ値やRTCPパケットタイプの定義などの単純な拡張は、IANAを通じてそれらを登録し、それらの説明をプロファイルの補遺またはペイロード形式の仕様で公開することで実現できます。
RTP suffers from the same security liabilities as the underlying protocols. For example, an impostor can fake source or destination network addresses, or change the header or payload. Within RTCP, the CNAME and NAME information may be used to impersonate another participant. In addition, RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication [33]. Therefore, the use of security mechanisms with RTP is important. These mechanisms are discussed in Section 9.
RTPには、基礎となるプロトコルと同じセキュリティ上の問題があります。たとえば、詐欺師は送信元または宛先のネットワークアドレスを偽造したり、ヘッダーやペイロードを変更したりできます。 RTCP内では、CNAMEおよびNAME情報を使用して、別の参加者になりすますことができます。さらに、RTPはIPマルチキャストを介して送信される場合があります。これは、送信者が送信されたデータのすべての受信者を知るための直接的な手段を提供しないため、プライバシーを測定できません。当然のことながら、従来の形式のネットワーク通信よりも、ユーザーは音声およびビデオ通信のプライバシーの問題に敏感になる可能性があります[33]。したがって、RTPでのセキュリティメカニズムの使用は重要です。これらのメカニズムについては、セクション9で説明します。
RTP-level translators or mixers may be used to allow RTP traffic to reach hosts behind firewalls. Appropriate firewall security principles and practices, which are beyond the scope of this document, should be followed in the design and installation of these devices and in the admission of RTP applications for use behind the firewall.
RTPレベルのトランスレータまたはミキサーを使用して、RTPトラフィックがファイアウォールの背後にあるホストに到達できるようにすることができます。これらのデバイスの設計とインストール、およびファイアウォールの背後で使用するRTPアプリケーションの承認では、このドキュメントの範囲を超える適切なファイアウォールセキュリティの原則と実践に従う必要があります。
Additional RTCP packet types and SDES item types may be registered through the Internet Assigned Numbers Authority (IANA). Since these number spaces are small, allowing unconstrained registration of new values would not be prudent. To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert." (Contact the IANA for the contact information of the current expert.)
追加のRTCPパケットタイプとSDESアイテムタイプは、Internet Assigned Numbers Authority（IANA）を通じて登録できます。これらの数値スペースは小さいため、新しい値を無制限に登録できるようにすることは賢明ではありません。要求のレビューを容易にし、複数のアプリケーション間での新しいタイプの共有使用を促進するために、新しい値の登録の要求は、RFCまたは他の共同標準化団体の製品（ITU-などの製品など） T）。 「指定された専門家」の助言の下で、他の要求も受け入れることができます。 （現在の専門家の連絡先情報については、IANAに連絡してください。）
RTP profile specifications SHOULD register with IANA a name for the profile in the form "RTP/xxx", where xxx is a short abbreviation of the profile title. These names are for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [15], to refer to transport methods.
RTPプロファイル仕様は、「RTP / xxx」の形式でプロファイルの名前をIANAに登録する必要があります。ここで、xxxはプロファイルタイトルの短い省略形です。これらの名前は、セッション記述プロトコル（SDP）、RFC 2327 [15]などの上位レベルの制御プロトコルがトランスポート方式を参照するために使用します。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能にされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IETF Executive Directorに情報を送信してください。
This memorandum is based on discussions within the IETF Audio/Video Transport working group chaired by Stephen Casner and Colin Perkins. The current protocol has its origins in the Network Voice Protocol and the Packet Video Protocol (Danny Cohen and Randy Cole) and the protocol implemented by the vat application (Van Jacobson and Steve McCanne). Christian Huitema provided ideas for the random identifier generator. Extensive analysis and simulation of the timer reconsideration algorithm was done by Jonathan Rosenberg. The additions for layered encodings were specified by Michael Speer and Steve McCanne.
この覚書は、Stephen CasnerとColin Perkinsが議長を務めるIETF Audio / Video Transportワーキンググループ内の議論に基づいています。現在のプロトコルは、ネットワーク音声プロトコルとパケットビデオプロトコル（ダニーコーエンとランディコール）と、バットアプリケーション（ヴァンジェイコブソンとスティーブマッキャンネ）によって実装されたプロトコルに起源があります。 Christian Huitemaは、ランダムIDジェネレーターのアイデアを提供しました。タイマー再検討アルゴリズムの広範な分析とシミュレーションは、Jonathan Rosenbergによって行われました。レイヤードエンコーディングの追加は、Michael SpeerおよびSteve McCanneによって指定されました。
Appendix A - Algorithms
付録A-アルゴリズム
We provide examples of C code for aspects of RTP sender and receiver algorithms. There may be other implementation methods that are faster in particular operating environments or have other advantages. These implementation notes are for informational purposes only and are meant to clarify the RTP specification.
RTP送信側および受信側アルゴリズムの側面のCコードの例を示します。特定の動作環境でより高速であるか、または他の利点がある他の実装方法があるかもしれません。これらの実装ノートは情報提供のみを目的としており、RTP仕様を明確にすることを目的としています。
The following definitions are used for all examples; for clarity and brevity, the structure definitions are only valid for 32-bit big-endian (most significant octet first) architectures. Bit fields are assumed to be packed tightly in big-endian bit order, with no additional padding. Modifications would be required to construct a portable implementation.
次の定義はすべての例で使用されます。明快さと簡潔さのために、構造体の定義は32ビットのビッグエンディアン（最上位オクテットが最初）のアーキテクチャでのみ有効です。ビットフィールドは、ビッグエンディアンのビット順で密にパックされ、追加のパディングはないものと見なされます。移植可能な実装を構築するには、変更が必要です。
/*
* rtp.h -- RTP header file
*/
#include <sys/types.h>
/*
* The type definitions below are valid for 32-bit architectures and
* may have to be adjusted for 16- or 64-bit architectures.
*/
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/*
* Current protocol version.
*/
#define RTP_VERSION 2
#define RTP_SEQ_MOD (1<<16)
#define RTP_MAX_SDES 255 /* maximum text length for SDES */
typedef enum {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204
} rtcp_type_t;
typedef enum {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1, RTCP_SDES_NAME = 2,
RTCP_SDES_EMAIL = 3,
RTCP_SDES_PHONE = 4,
RTCP_SDES_LOC = 5,
RTCP_SDES_TOOL = 6,
RTCP_SDES_NOTE = 7,
RTCP_SDES_PRIV = 8
} rtcp_sdes_type_t;
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
/*
* RTCP common header word
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */
unsigned int pt:8; /* RTCP packet type */
u_int16 length; /* pkt len in words, w/o this word */
} rtcp_common_t;
/*
* Big-endian mask for version, padding bit and packet type pair
*/
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/*
* Reception report block
*/
typedef struct {
u_int32 ssrc; /* data source being reported */
unsigned int fraction:8; /* fraction lost since last SR/RR */ int lost:24; /* cumul. no. pkts lost (signed!) */
u_int32 last_seq; /* extended last seq. no. received */
u_int32 jitter; /* interarrival jitter */
u_int32 lsr; /* last SR packet from this source */
u_int32 dlsr; /* delay since last SR packet */
} rtcp_rr_t;
/*
* SDES item
*/
typedef struct {
u_int8 type; /* type of item (rtcp_sdes_type_t) */
u_int8 length; /* length of item (in octets) */
char data[1]; /* text, not null-terminated */
} rtcp_sdes_item_t;
/*
* One RTCP packet
*/
typedef struct {
rtcp_common_t common; /* common header */
union {
/* sender report (SR) */
struct {
u_int32 ssrc; /* sender generating this report */
u_int32 ntp_sec; /* NTP timestamp */
u_int32 ntp_frac;
u_int32 rtp_ts; /* RTP timestamp */
u_int32 psent; /* packets sent */
u_int32 osent; /* octets sent */
rtcp_rr_t rr[1]; /* variable-length list */
} sr;
/* reception report (RR) */
struct {
u_int32 ssrc; /* receiver generating this report */
rtcp_rr_t rr[1]; /* variable-length list */
} rr;
/* source description (SDES) */
struct rtcp_sdes {
u_int32 src; /* first SSRC/CSRC */
rtcp_sdes_item_t item[1]; /* list of SDES items */
} sdes;
/* BYE */
struct {
u_int32 src[1]; /* list of sources */
/* can't express trailing text for reason */
} bye;
} r;
} rtcp_t;
typedef struct rtcp_sdes rtcp_sdes_t;
topdef strukt rtsp_sdes gtkp_sdes_t;
/*
* Per-source state information
*/
typedef struct {
u_int16 max_seq; /* highest seq. number seen */
u_int32 cycles; /* shifted count of seq. number cycles */
u_int32 base_seq; /* base seq number */
u_int32 bad_seq; /* last 'bad' seq number + 1 */
u_int32 probation; /* sequ. packets till source is valid */
u_int32 received; /* packets received */
u_int32 expected_prior; /* packet expected at last interval */
u_int32 received_prior; /* packet received at last interval */
u_int32 transit; /* relative trans time for prev pkt */
u_int32 jitter; /* estimated jitter */
/* ... */
} source;
A.1 RTP Data Header Validity Checks
A.1 RTPデータヘッダーの有効性チェック
An RTP receiver should check the validity of the RTP header on incoming packets since they might be encrypted or might be from a different application that happens to be misaddressed. Similarly, if encryption according to the method described in Section 9 is enabled, the header validity check is needed to verify that incoming packets have been correctly decrypted, although a failure of the header validity check (e.g., unknown payload type) may not necessarily indicate decryption failure.
RTPレシーバーは、暗号化されている場合や、誤ってアドレス指定された別のアプリケーションからのものである場合があるため、着信パケットのRTPヘッダーの有効性を確認する必要があります。同様に、セクション9で説明されている方法による暗号化が有効になっている場合、着信パケットが正しく復号化されたことを確認するためにヘッダー有効性チェックが必要ですが、ヘッダー有効性チェックの失敗（不明なペイロードタイプなど）は必ずしも示すとは限りません復号化に失敗しました。
Only weak validity checks are possible on an RTP data packet from a source that has not been heard before:
これまで聞いたことがないソースからのRTPデータパケットでは、弱い有効性チェックのみが可能です。
o RTP version field must equal 2.
o RTPバージョンフィールドは2でなければなりません。
o The payload type must be known, and in particular it must not be equal to SR or RR.
o ペイロードタイプは既知である必要があり、特にSRまたはRRと等しくない必要があります。
o If the P bit is set, then the last octet of the packet must contain a valid octet count, in particular, less than the total packet length minus the header size.
o Pビットが設定されている場合、パケットの最後のオクテットには、有効なオクテットカウントが含まれている必要があります。特に、合計パケット長からヘッダーサイズを引いた値よりも小さい必要があります。
o The X bit must be zero if the profile does not specify that the header extension mechanism may be used. Otherwise, the extension length field must be less than the total packet size minus the fixed header length and padding.
o ヘッダー拡張メカニズムを使用できることをプロファイルが指定していない場合、Xビットはゼロでなければなりません。それ以外の場合、拡張長フィールドは、合計パケットサイズから固定ヘッダー長とパディングを差し引いた値よりも小さくなければなりません。
o The length of the packet must be consistent with CC and payload type (if payloads have a known length).
o パケットの長さは、CCおよびペイロードタイプと一致している必要があります（ペイロードの長さがわかっている場合）。
The last three checks are somewhat complex and not always possible, leaving only the first two which total just a few bits. If the SSRC identifier in the packet is one that has been received before, then the packet is probably valid and checking if the sequence number is in the expected range provides further validation. If the SSRC identifier has not been seen before, then data packets carrying that identifier may be considered invalid until a small number of them arrive with consecutive sequence numbers. Those invalid packets MAY be discarded or they MAY be stored and delivered once validation has been achieved if the resulting delay is acceptable.
最後の3つのチェックはやや複雑であり、常に可能であるとは限りません。最初の2つだけが残り、合計はほんの数ビットです。パケット内のSSRC識別子が以前に受信されたものである場合、パケットはおそらく有効であり、シーケンス番号が期待される範囲内にあるかどうかをチェックすることで、さらに検証できます。 SSRC識別子が以前に見られなかった場合、その識別子を運ぶデータパケットは、少数の連続したシーケンス番号で到着するまで無効と見なされる可能性があります。結果として生じる遅延が許容できる場合、検証が達成されると、それらの無効なパケットは破棄されるか、または格納されて配信される場合があります。
The routine update_seq shown below ensures that a source is declared valid only after MIN_SEQUENTIAL packets have been received in sequence. It also validates the sequence number seq of a newly received packet and updates the sequence state for the packet's source in the structure to which s points.
以下に示すupdate_seqルーチンは、MIN_SEQUENTIALパケットが順番に受信された後にのみ、ソースが有効であると宣言されることを保証します。また、新しく受信したパケットのシーケンス番号seqを検証し、sが指す構造内のパケットの送信元のシーケンス状態を更新します。
When a new source is heard for the first time, that is, its SSRC identifier is not in the table (see Section 8.2), and the per-source state is allocated for it, s->probation is set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL) and other variables are initialized:
新しいソースが初めて聞こえたとき、つまり、そのSSRC識別子がテーブルに存在せず（セクション8.2を参照）、ソースごとの状態が割り当てられている場合、s-> probationはシーケンシャルの数に設定されます。ソースが有効であると宣言する前に必要なパケット（パラメーターMIN_SEQUENTIAL）およびその他の変数が初期化されます。
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;
A non-zero s->probation marks the source as not yet valid so the state may be discarded after a short timeout rather than a long one, as discussed in Section 6.2.1.
ゼロ以外のs-> probationは、ソースをまだ有効ではないものとしてマークするため、セクション6.2.1で説明するように、長いタイムアウトではなく短いタイムアウトの後に状態が破棄される可能性があります。
After a source is considered valid, the sequence number is considered valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more than MAX_MISORDER behind. If the new sequence number is ahead of max_seq modulo the RTP sequence number range (16 bits), but is smaller than max_seq, it has wrapped around and the (shifted) count of sequence number cycles is incremented. A value of one is returned to indicate a valid sequence number.
ソースが有効であると見なされた後、s-> max_seqより前のMAX_DROPOUT以下、または後のMAX_MISORDER以下の場合、シーケンス番号は有効であると見なされます。新しいシーケンス番号がRTPシーケンス番号の範囲（16ビット）を法とするmax_seqより前であるが、max_seqよりも小さい場合は、循環し、シーケンス番号サイクルの（シフトされた）カウントが増分されます。有効なシーケンス番号を示すために、1の値が返されます。
Otherwise, the value zero is returned to indicate that the validation failed, and the bad sequence number plus 1 is stored. If the next packet received carries the next higher sequence number, it is considered the valid start of a new packet sequence presumably caused by an extended dropout or a source restart. Since multiple complete sequence number cycles may have been missed, the packet loss statistics are reset.
それ以外の場合は、検証が失敗したことを示すために値0が返され、不正なシーケンス番号に1を加えたものが格納されます。受信した次のパケットが次に大きいシーケンス番号を持っている場合、それはおそらく拡張ドロップアウトまたはソースの再起動によって引き起こされた新しいパケットシーケンスの有効な開始と見なされます。複数の完全なシーケンス番号サイクルが失われた可能性があるため、パケット損失統計がリセットされます。
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a small fraction of the 16-bit sequence number space to give a reasonable probability that new sequence numbers after a restart will not fall in the acceptable range for sequence numbers from before the restart.
50パケット/秒での2秒の最大誤順序時間と1分の最大ドロップアウトに基づいて、パラメーターの典型的な値が表示されます。ドロップアウトパラメータMAX_DROPOUTは、再起動後の新しいシーケンス番号が、再起動前からのシーケンス番号の許容範囲に入らないという妥当な確率を与えるために、16ビットのシーケンス番号スペースのごく一部である必要があります。
void init_seq(source *s, u_int16 seq)
{
s->base_seq = seq;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
s->cycles = 0;
s->received = 0;
s->received_prior = 0;
s->expected_prior = 0;
/* other initialization */
}
int update_seq(source *s, u_int16 seq)
{
u_int16 udelta = seq - s->max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
/*
* Source is not valid until MIN_SEQUENTIAL packets with
* sequential sequence numbers have been received.
*/
if (s->probation) {
/* packet is in sequence */
if (seq == s->max_seq + 1) {
s->probation--;
s->max_seq = seq;
if (s->probation == 0) {
init_seq(s, seq);
s->received++;
return 1;
}
} else {
s->probation = MIN_SEQUENTIAL - 1;
s->max_seq = seq;
}
return 0;
} else if (udelta < MAX_DROPOUT) {
/* in order, with permissible gap */
if (seq < s->max_seq) {
/*
* Sequence number wrapped - count another 64K cycle.
*/
s->cycles += RTP_SEQ_MOD;
}
s->max_seq = seq;
} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
/* the sequence number made a very large jump */
if (seq == s->bad_seq) {
/*
* Two sequential packets -- assume that the other side
* restarted without telling us so just re-sync
* (i.e., pretend this was the first packet).
*/
init_seq(s, seq);
}
else {
s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
return 0;
}
} else {
/* duplicate or reordered packet */
}
s->received++;
return 1;
}
The validity check can be made stronger requiring more than two packets in sequence. The disadvantages are that a larger number of initial packets will be discarded (or delayed in a queue) and that high packet loss rates could prevent validation. However, because the RTCP header validation is relatively strong, if an RTCP packet is received from a source before the data packets, the count could be adjusted so that only two packets are required in sequence. If initial data loss for a few seconds can be tolerated, an application MAY choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
有効性チェックは、2つ以上のパケットを順番に要求することでより強力にできます。欠点は、多数の初期パケットが破棄される（またはキューで遅延する）ことと、パケット損失率が高いために検証が妨げられる可能性があることです。ただし、RTCPヘッダーの検証は比較的強力であるため、データパケットの前にソースからRTCPパケットを受信した場合、2つのパケットのみが順番に必要になるようにカウントを調整できます。数秒間の初期データ損失が許容できる場合、アプリケーションは、ソースから有効なRTCPパケットが受信されるまで、ソースからのすべてのデータパケットを破棄することを選択できます（MAY）。
Depending on the application and encoding, algorithms may exploit additional knowledge about the payload format for further validation. For payload types where the timestamp increment is the same for all packets, the timestamp values can be predicted from the previous packet received from the same source using the sequence number difference (assuming no change in payload type).
アプリケーションとエンコーディングに応じて、アルゴリズムはペイロードフォーマットに関する追加の知識を利用して、さらに検証を行うことができます。タイムスタンプの増分がすべてのパケットで同じであるペイロードタイプの場合、シーケンス番号の違いを使用して、同じソースから受信した前のパケットからタイムスタンプ値を予測できます（ペイロードタイプに変更がない場合）。
A strong "fast-path" check is possible since with high probability the first four octets in the header of a newly received RTP data packet will be just the same as that of the previous packet from the same SSRC except that the sequence number will have increased by one. Similarly, a single-entry cache may be used for faster SSRC lookups in applications where data is typically received from one source at a time.
新しく受信したRTPデータパケットのヘッダーの最初の4つのオクテットは、シーケンス番号が異なることを除いて、同じSSRCからの前のパケットとまったく同じになる可能性が高いため、強力な「高速パス」チェックが可能です。 1増加しました。同様に、単一エントリのキャッシュは、通常、一度に1つのソースからデータを受信するアプリケーションで、より高速なSSRCルックアップに使用できます。
A.2 RTCP Header Validity Checks
A.2 RTCPヘッダーの有効性チェック
The following checks should be applied to RTCP packets.
次のチェックをRTCPパケットに適用する必要があります。
o RTP version field must equal 2.
o RTPバージョンフィールドは2でなければなりません。
o The payload type field of the first RTCP packet in a compound packet must be equal to SR or RR.
o 複合パケットの最初のRTCPパケットのペイロードタイプフィールドは、SRまたはRRと等しくなければなりません。
o The padding bit (P) should be zero for the first packet of a compound RTCP packet because padding should only be applied, if it is needed, to the last packet.
o パディングは必要に応じて最後のパケットにのみ適用されるため、複合RTCPパケットの最初のパケットのパディングビット（P）はゼロでなければなりません。
o The length fields of the individual RTCP packets must add up to the overall length of the compound RTCP packet as received. This is a fairly strong check.
o 個々のRTCPパケットの長さフィールドの合計は、受信した複合RTCPパケットの全長になる必要があります。これはかなり強力なチェックです。
The code fragment below performs all of these checks. The packet type is not checked for subsequent packets since unknown packet types may be present and should be ignored.
以下のコードフラグメントは、これらすべてのチェックを実行します。不明なパケットタイプが存在する可能性があり、無視する必要があるため、後続のパケットのパケットタイプはチェックされません。
u_int32 len; /* length of compound RTCP packet in words */
rtcp_t *r; /* RTCP header */
rtcp_t *end; /* end of compound RTCP packet */
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* something wrong with packet format */
}
end = (rtcp_t *)((u_int32 *)r + len);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
if (r != end) {
/* something wrong with packet format */
}
A.3 Determining Number of Packets Expected and Lost
A.3予想されるパケット数と失われるパケット数の決定
In order to compute packet loss rates, the number of RTP packets expected and actually received from each source needs to be known, using per-source state information defined in struct source referenced via pointer s in the code below. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets expected can be computed by the receiver as the difference between the highest sequence number received (s->max_seq) and the first sequence number received (s->base_seq). Since the sequence number is only 16 bits and will wrap around, it is necessary to extend the highest sequence number with the (shifted) count of sequence number wraparounds (s->cycles). Both the received packet count and the count of cycles are maintained the RTP header validity check routine in Appendix A.1.
パケット損失率を計算するには、以下のコードのポインターsを介して参照されるstruct sourceで定義されているソースごとの状態情報を使用して、各ソースから予期され、実際に受信されるRTPパケットの数を知る必要があります。受信されたパケット数は、到着したパケットの数であり、遅延パケットまたは重複パケットを含みます。予想されるパケット数は、受信された最も高いシーケンス番号（s-> max_seq）と最初に受信されたシーケンス番号（s-> base_seq）の差として、レシーバーによって計算できます。シーケンス番号は16ビットのみでラップアラウンドするため、シーケンス番号のラップアラウンド（s-> cycles）の（シフトされた）カウントで最大シーケンス番号を拡張する必要があります。受信パケット数とサイクル数の両方が、付録A.1のRTPヘッダー有効性チェックルーチンで維持されます。
extended_max = s->cycles + s->max_seq;
expected = extended_max - s->base_seq + 1;
The number of packets lost is defined to be the number of packets expected less the number of packets actually received:
失われたパケット数は、予想されるパケット数から実際に受信されたパケット数を差し引いたものとして定義されます。
lost = expected - s->received;
Since this signed number is carried in 24 bits, it should be clamped at 0x7fffff for positive loss or 0x800000 for negative loss rather than wrapping around.
この符号付き数値は24ビットで運ばれるため、正の損失の場合は0x7fffffに、負の損失の場合は0x800000にクランプする必要があります。
The fraction of packets lost during the last reporting interval (since the previous SR or RR packet was sent) is calculated from differences in the expected and received packet counts across the interval, where expected_prior and received_prior are the values saved when the previous reception report was generated:
最後のレポート間隔中に失われたパケットの割合（前のSRまたはRRパケットが送信されたため）は、間隔全体の予想パケット数と受信パケット数の差から計算されます。expected_priorとreceived_priorは、前回の受信レポートが保存されたときに保存された値です。生成された：
expected_interval = expected - s->expected_prior;
s->expected_prior = expected;
received_interval = s->received - s->received_prior;
s->received_prior = s->received;
lost_interval = expected_interval - received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;
The resulting fraction is an 8-bit fixed point number with the binary point at the left edge.
結果の小数部は、2進小数点が左端にある8ビットの固定小数点数です。
A.4 Generating RTCP SDES Packets
A.4 RTCP SDESパケットの生成
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type, value and length. It returns a pointer to the next available location within b.
この関数は、配列タイプ、値、および長さで提供されるargc項目で構成されるバッファーbに1つのSDESチャンクを構築します。 b内で次に使用可能な場所へのポインタを返します。
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* invalid length, may want to take other action */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* terminate with end marker and pad to next 4-octet boundary */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
return b;
}
A.5 Parsing RTCP SDES Packets
A.5 RTCP SDESパケットの解析
This function parses an SDES packet, calling functions find_member() to find a pointer to the information for a session member given the SSRC identifier and member_sdes() to store the new SDES information for that member. This function expects a pointer to the header of the RTCP packet.
この関数は、SDESパケットを解析し、関数find_member()を呼び出して、SSRC識別子が与えられたセッションメンバーの情報へのポインターを検索し、member_sdes()がそのメンバーの新しいSDES情報を格納します。この関数は、RTCPパケットのヘッダーへのポインターを想定しています。
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}
A.6 Generating a Random 32-bit Identifier
A.6ランダム32ビット識別子の生成
The following subroutine generates a random 32-bit identifier using the MD5 routines published in RFC 1321 [32]. The system routines may not be present on all operating systems, but they should serve as hints as to what kinds of information may be used. Other system calls that may be appropriate include o getdomainname(),
次のサブルーチンは、RFC 1321 [32]で公開されているMD5ルーチンを使用して、ランダムな32ビット識別子を生成します。システムルーチンはすべてのオペレーティングシステムに存在するわけではありませんが、使用できる情報の種類に関するヒントとして機能する必要があります。その他の適切なシステムコールには、o getdomainname()、
o getwd(), or
o getwd()、または
o getrusage().
o getrusage()。
"Live" video or audio samples are also a good source of random numbers, but care must be taken to avoid using a turned-off microphone or blinded camera as a source [17].
「ライブ」ビデオまたはオーディオサンプルも乱数の優れたソースですが、オフのマイクまたはブラインドカメラをソースとして使用しないように注意する必要があります[17]。
Use of this or a similar routine is recommended to generate the initial seed for the random number generator producing the RTCP period (as shown in Appendix A.7), to generate the initial values for the sequence number and timestamp, and to generate SSRC values. Since this routine is likely to be CPU-intensive, its direct use to generate RTCP periods is inappropriate because predictability is not an issue. Note that this routine produces the same result on repeated calls until the value of the system clock changes unless different values are supplied for the type argument.
RTCP期間を生成する乱数ジェネレーターの初期シード（付録A.7を参照）を生成し、シーケンス番号とタイムスタンプの初期値を生成し、SSRC値を生成するには、このルーチンまたは同様のルーチンの使用をお勧めします。このルーチンはCPUを集中的に使用する可能性が高いため、RTCP期間を生成するために直接使用することは、予測可能性が問題ではないため不適切です。 type引数に異なる値が指定されない限り、システムクロックの値が変化するまで、このルーチンは繰り返しの呼び出しで同じ結果を生成することに注意してください。
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321 */
#include "md5.h" /* from RFC 1321 */
#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final
#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
MDInit (&context);
MDInit（＆context）;
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
return md_32((char *)&s, sizeof(s));
} /* random32 */
A.7 Computing the RTCP Transmission Interval
A.7 RTCP送信間隔の計算
The following functions implement the RTCP transmission and reception rules described in Section 6.2. These rules are coded in several functions:
以下の関数は、セクション6.2で説明されているRTCP送信および受信ルールを実装します。これらのルールは、いくつかの関数でコード化されています。
o rtcp_interval() computes the deterministic calculated interval, measured in seconds. The parameters are defined in Section 6.3.
o rtcp_interval()は、決定論的に計算された間隔を秒単位で計算します。パラメータはセクション6.3で定義されています。
o OnExpire() is called when the RTCP transmission timer expires.
o OnExpire()は、RTCP送信タイマーが期限切れになると呼び出されます。
o OnReceive() is called whenever an RTCP packet is received.
o OnReceive()は、RTCPパケットが受信されるたびに呼び出されます。
Both OnExpire() and OnReceive() have event e as an argument. This is the next scheduled event for that participant, either an RTCP report or a BYE packet. It is assumed that the following functions are available:
OnExpire()とOnReceive()はどちらも引数としてイベントeを持っています。これは、RTCPレポートまたはBYEパケットのいずれかである、その参加者に対して次にスケジュールされているイベントです。以下の機能が利用可能であることを前提としています。
o Schedule(time t, event e) schedules an event e to occur at time t. When time t arrives, the function OnExpire is called with e as an argument.
o Schedule（time t、event e）は、イベントeが時刻tに発生するようにスケジュールします。時間tに達すると、関数OnExpireがeを引数として呼び出されます。
o Reschedule(time t, event e) reschedules a previously scheduled event e for time t.
o Reschedule（time t、event e）は、以前にスケジュールされたイベントeを時間tに再スケジュールします。
o SendRTCPReport(event e) sends an RTCP report.
o SendRTCPReport（event e）はRTCPレポートを送信します。
o SendBYEPacket(event e) sends a BYE packet.
o SendBYEPacket（event e）はBYEパケットを送信します。
o TypeOfEvent(event e) returns EVENT_BYE if the event being processed is for a BYE packet to be sent, else it returns EVENT_REPORT.
o TypeOfEvent（event e）は、処理中のイベントがBYEパケットの送信用である場合はEVENT_BYEを返し、それ以外の場合はEVENT_REPORTを返します。
o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an RTCP report (not BYE), PACKET_BYE if its a BYE RTCP packet, and PACKET_RTP if its a regular RTP data packet.
o PacketType（p）は、パケットpがRTCPレポート（BYEではない）の場合はPACKET_RTCP_REPORTを、BYE RTCPパケットの場合はPACKET_BYEを、通常のRTPデータパケットの場合はPACKET_RTPを返します。
o ReceivedPacketSize() and SentPacketSize() return the size of the referenced packet in octets.
o ReceivedPacketSize()およびSentPacketSize()は、参照されたパケットのサイズをオクテットで返します。
o NewMember(p) returns a 1 if the participant who sent packet p is not currently in the member list, 0 otherwise. Note this function is not sufficient for a complete implementation because each CSRC identifier in an RTP packet and each SSRC in a BYE packet should be processed.
o NewMember（p）は、パケットpを送信した参加者が現在メンバーリストにない場合は1を返し、そうでない場合は0を返します。 RTPパケットの各CSRC識別子とBYEパケットの各SSRCを処理する必要があるため、この機能は完全な実装には不十分です。
o NewSender(p) returns a 1 if the participant who sent packet p is not currently in the sender sublist of the member list, 0 otherwise.
o NewSender（p）は、パケットpを送信した参加者が現在メンバーリストの送信者サブリストにない場合は1を返し、そうでない場合は0を返します。
o AddMember() and RemoveMember() to add and remove participants from the member list.
o AddMember()およびRemoveMember()は、メンバーリストに参加者を追加および削除します。
o AddSender() and RemoveSender() to add and remove participants from the sender sublist of the member list.
o AddSender()およびRemoveSender()は、メンバーリストの送信者サブリストに参加者を追加および削除します。
These functions would have to be extended for an implementation that allows the RTCP bandwidth fractions for senders and non-senders to be specified as explicit parameters rather than fixed values of 25% and 75%. The extended implementation of rtcp_interval() would need to avoid division by zero if one of the parameters was zero.
これらの関数は、送信側と非送信側のRTCP帯域幅の割合を、25％と75％の固定値ではなく明示的なパラメーターとして指定できる実装に拡張する必要があります。 rtcp_interval()の拡張実装では、パラメータの1つがゼロの場合、ゼロによる除算を回避する必要があります。
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
double avg_rtcp_size,
int initial)
{
/*
* Minimum average time between RTCP packets from this site (in
* seconds). This time prevents the reports from `clumping' when
* sessions are small and the law of large numbers isn't helping
* to smooth out the traffic. It also keeps the report interval
* from becoming ridiculously small during transient outages like
* a network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
/* To compensate for "timer reconsideration" converging to a
* value below the intended average.
*/
double const COMPENSATION = 2.71828 - 1.5;
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly.
*/
if (initial) {
rtcp_min_time /= 2;
}
/*
* Dedicate a fraction of the RTCP bandwidth to senders unless
* the number of senders is large enough that their share is
* more than that fraction.
*/
n = members;
if (senders <= members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = avg_rtcp_size * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
t = t * (drand48() + 0.5);
t = t / COMPENSATION;
return t;
}
void OnExpire(event e,
int members,
int senders,
double rtcp_bw,
int we_sent,
double *avg_rtcp_size, int *initial,
time_tp tc,
time_tp *tp,
int *pmembers)
{
/* This function is responsible for deciding whether to send an
* RTCP report or BYE packet now, or to reschedule transmission.
* It is also responsible for updating the pmembers, initial, tp,
* and avg_rtcp_size state variables. This function should be
* called upon expiration of the event timer used by Schedule().
*/
double t; /* Interval */
double tn; /* Next transmit time */
/* In the case of a BYE, we use "timer reconsideration" to
* reschedule the transmission of the BYE if necessary */
if (TypeOfEvent(e) == EVENT_BYE) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendBYEPacket(e);
exit(1);
} else {
Schedule(tn, e);
}
} else if (TypeOfEvent(e) == EVENT_REPORT) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) +
(15./16.)*(*avg_rtcp_size);
*tp = tc;
/* We must redraw the interval. Don't reuse the
one computed above, since its not actually
distributed the same, as we are conditioned
on it being small enough to cause a packet to
be sent */
t = rtcp_interval(members, senders, rtcp_bw, we_sent, *avg_rtcp_size, *initial);
t = rtcp_interval（members、senders、rtcp_bw、we_sent、* avg_rtcp_size、* initial）;
Schedule(t+tc,e);
*initial = 0;
} else {
Schedule(tn, e);
}
*pmembers = members;
}
}
void OnReceive(packet p,
event e,
int *members,
int *pmembers,
int *senders,
double *avg_rtcp_size,
double *tp,
double tc,
double tn)
{
/* What we do depends on whether we have left the group, and are
* waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
* report. p represents the packet that was just received. */
if (PacketType(p) == PACKET_RTCP_REPORT) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
} else if (PacketType(p) == PACKET_RTP) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddSender(p);
*senders += 1;
}
} else if (PacketType(p) == PACKET_BYE) {
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
if (TypeOfEvent(e) == EVENT_REPORT) {
if (NewSender(p) == FALSE) {
RemoveSender(p);
*senders -= 1;
}
if (NewMember(p) == FALSE) {
RemoveMember(p);
*members -= 1;
}
if (*members < *pmembers) {
tn = tc +
(((double) *members)/(*pmembers))*(tn - tc);
*tp = tc -
(((double) *members)/(*pmembers))*(tc - *tp);
/* Reschedule the next report for time tn */
Reschedule(tn, e);
*pmembers = *members;
}
} else if (TypeOfEvent(e) == EVENT_BYE) {
*members += 1;
}
}
}
A.8 Estimating the Interarrival Jitter
A.8到着間ジッタの推定
The code fragments below implement the algorithm given in Section 6.4.1 for calculating an estimate of the statistical variance of the RTP data interarrival time to be inserted in the interarrival jitter field of reception reports. The inputs are r->ts, the timestamp from the incoming packet, and arrival, the current time in the same units. Here s points to state for the source; s->transit holds the relative transit time for the previous packet, and s->jitter holds the estimated jitter. The jitter field of the reception report is measured in timestamp units and expressed as an unsigned integer, but the jitter estimate is kept in a floating point. As each data packet arrives, the jitter estimate is updated:
以下のコードフラグメントは、受信レポートの到着間ジッタフィールドに挿入されるRTPデータ到着間時間の統計的分散の推定値を計算するために、セクション6.4.1で指定されたアルゴリズムを実装します。入力は、r-> ts、着信パケットからのタイムスタンプ、および到着、同じ単位での現在時刻です。ここで、sはソースの状態を指します。 s-> transitは前のパケットの相対通過時間を保持し、s-> jitterは推定ジッターを保持します。受信レポートのジッターフィールドはタイムスタンプ単位で測定され、符号なし整数として表されますが、ジッター推定値は浮動小数点で保持されます。各データパケットが到着すると、ジッター推定値が更新されます。
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
When a reception report block (to which rr points) is generated for this member, the current jitter estimate is returned:
このメンバーに対して受信レポートブロック（rrポイント）が生成されると、現在のジッタ推定が返されます。
rr->jitter = (u_int32) s->jitter;
Alternatively, the jitter estimate can be kept as an integer, but scaled to reduce round-off error. The calculation is the same except for the last line:
あるいは、ジッター推定値を整数として保持できますが、丸め誤差を減らすためにスケーリングされます。計算は最後の行を除いて同じです：
s->jitter += d - ((s->jitter + 8) >> 4);
In this case, the estimate is sampled for the reception report as:
この場合、受信レポートの推定値は次のようにサンプリングされます。
rr->jitter = s->jitter >> 4;
Appendix B - Changes from RFC 1889
付録B-RFC 1889からの変更
Most of this RFC is identical to RFC 1889. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets:
このRFCのほとんどはRFC 1889と同じです。ネットワーク上のパケット形式に変更はなく、プロトコルの使用方法を制御するルールとアルゴリズムにのみ変更があります。最大の変更は、RTCPパケットを送信するタイミングを計算するためのスケーラブルタイマーアルゴリズムの拡張です。
o The algorithm for calculating the RTCP transmission interval specified in Sections 6.2 and 6.3 and illustrated in Appendix A.7 is augmented to include "reconsideration" to minimize transmission in excess of the intended rate when many participants join a session simultaneously, and "reverse reconsideration" to reduce the incidence and duration of false participant timeouts when the number of participants drops rapidly. Reverse reconsideration is also used to possibly shorten the delay before sending RTCP SR when transitioning from passive receiver to active sender mode.
o セクション6.2と6.3で指定され、付録A.7に示されているRTCP送信間隔を計算するアルゴリズムは、多くの参加者が同時にセッションに参加したときに意図したレートを超える送信を最小限に抑えるための「再検討」と「逆再検討」を含むように拡張されています。参加者の数が急激に減少した場合に、誤った参加者のタイムアウトの発生率と期間を減らすため。パッシブレシーバーモードからアクティブセンダーモードに移行するときに、RTCP SRを送信する前の遅延を短縮するために、逆再検討も使用されます。
o Section 6.3.7 specifies new rules controlling when an RTCP BYE packet should be sent in order to avoid a flood of packets when many participants leave a session simultaneously.
o セクション6.3.7は、多くの参加者が同時にセッションを離れたときにパケットのフラッドを回避するために、RTCP BYEパケットをいつ送信するかを制御する新しいルールを指定しています。
o The requirement to retain state for inactive participants for a period long enough to span typical network partitions was removed from Section 6.2.1. In a session where many participants join for a brief time and fail to send BYE, this requirement would cause a significant overestimate of the number of participants. The reconsideration algorithm added in this revision compensates for the large number of new participants joining simultaneously when a partition heals.
o 一般的なネットワークパーティションにまたがるのに十分な期間、非アクティブな参加者の状態を保持する要件は、セクション6.2.1から削除されました。多くの参加者が短時間参加し、BYEの送信に失敗するセッションでは、この要件により、参加者数が大幅に過大評価されます。このリビジョンで追加された再検討アルゴリズムは、パーティションが回復したときに同時に参加する多数の新しい参加者を補償します。
It should be noted that these enhancements only have a significant effect when the number of session participants is large (thousands) and most of the participants join or leave at the same time. This makes testing in a live network difficult. However, the algorithm was subjected to a thorough analysis and simulation to verify its performance. Furthermore, the enhanced algorithm was designed to interoperate with the algorithm in RFC 1889 such that the degree of reduction in excess RTCP bandwidth during a step join is proportional to the fraction of participants that implement the enhanced algorithm. Interoperation of the two algorithms has been verified experimentally on live networks.
これらの機能強化は、セッション参加者の数が多く（数千人）、ほとんどの参加者が同時に参加または脱退する場合にのみ大きな効果があることに注意してください。これにより、ライブネットワークでのテストが困難になります。ただし、アルゴリズムはそのパフォーマンスを検証するために徹底的な分析とシミュレーションが行われました。さらに、拡張アルゴリズムはRFC 1889のアルゴリズムと相互運用するように設計されているため、ステップ結合中の過剰なRTCP帯域幅の減少の度合いは、拡張アルゴリズムを実装する参加者の割合に比例します。 2つのアルゴリズムの相互運用は、ライブネットワークで実験的に検証されています。
Other functional changes were:
その他の機能変更は次のとおりです。
o Section 6.2.1 specifies that implementations may store only a sampling of the participants' SSRC identifiers to allow scaling to very large sessions. Algorithms are specified in RFC 2762 [21].
o セクション6.2.1は、実装が参加者のSSRC識別子のサンプリングのみを保存して、非常に大きなセッションへのスケーリングを可能にすることを指定しています。アルゴリズムはRFC 2762 [21]で指定されています。
o In Section 6.2 it is specified that RTCP sender and non-sender bandwidths may be set as separate parameters of the session rather than a strict percentage of the session bandwidth, and may be set to zero. The requirement that RTCP was mandatory for RTP sessions using IP multicast was relaxed. However, a clarification was also added that turning off RTCP is NOT RECOMMENDED.
o セクション6.2では、RTCPの送信側と非送信側の帯域幅を、セッション帯域幅の厳密な割合ではなく、セッションの個別のパラメーターとして設定し、ゼロに設定することを指定しています。 IPマルチキャストを使用するRTPセッションでRTCPが必須であるという要件は緩和されました。ただし、RTCPをオフにすることは推奨されないという説明も追加されました。
o In Sections 6.2, 6.3.1 and Appendix A.7, it is specified that the fraction of participants below which senders get dedicated RTCP bandwidth changes from the fixed 1/4 to a ratio based on the RTCP sender and non-sender bandwidth parameters when those are given. The condition that no bandwidth is dedicated to senders when there are no senders was removed since that is expected to be a transitory state. It also keeps non-senders from using sender RTCP bandwidth when that is not intended.
o セクション6.2、6.3.1、および付録A.7では、送信者が専用のRTCP帯域幅を取得する参加者の割合が、固定された1/4から、RTCP送信者および非送信者の帯域幅パラメーターに基づく比率に変化することが指定されています。それらが与えられます。一時的な状態であると予想されるため、送信者がいない場合に送信者専用の帯域幅がないという条件は削除されました。また、意図しない場合に、非送信者が送信者のRTCP帯域幅を使用しないようにします。
o Also in Section 6.2 it is specified that the minimum RTCP interval may be scaled to smaller values for high bandwidth sessions, and that the initial RTCP delay may be set to zero for unicast sessions.
o また、セクション6.2では、最小RTCP間隔を高帯域幅セッションの場合はより小さな値にスケーリングでき、ユニキャストセッションの場合は初期RTCP遅延をゼロに設定できることを指定しています。
o Timing out a participant is to be based on inactivity for a number of RTCP report intervals calculated using the receiver RTCP bandwidth fraction even for active senders.
o 参加者のタイムアウトは、アクティブな送信者であっても、受信者のRTCP帯域幅の割合を使用して計算された、いくつかのRTCPレポート間隔の非アクティブに基づいています。
o Sections 7.2 and 7.3 specify that translators and mixers should send BYE packets for the sources they are no longer forwarding.
o セクション7.2および7.3では、トランスレーターとミキサーが転送しなくなったソースに対してBYEパケットを送信するように指定しています。
o Rule changes for layered encodings are defined in Sections 2.4, 6.3.9, 8.3 and 11. In the last of these, it is noted that the address and port assignment rule conflicts with the SDP specification, RFC 2327 [15], but it is intended that this restriction will be relaxed in a revision of RFC 2327.
o レイヤードエンコーディングのルール変更は、セクション2.4、6.3.9、8.3、11で定義されています。これらの最後では、アドレスとポートの割り当てルールがSDP仕様、RFC 2327 [15]と競合することに注意してください。この制限はRFC 2327の改訂で緩和されることを意図していました。
o The convention for using even/odd port pairs for RTP and RTCP in Section 11 was clarified to refer to destination ports. The requirement to use an even/odd port pair was removed if the two ports are specified explicitly. For unicast RTP sessions, distinct port pairs may be used for the two ends (Sections 3, 7.1 and 11).
o セクション11のRTPとRTCPで偶数/奇数のポートペアを使用するための規則は、宛先ポートを参照するように明確化されました。 2つのポートが明示的に指定されている場合は、偶数/奇数のポートペアを使用する必要がなくなりました。ユニキャストRTPセッションの場合、2つの端（セクション3、7.1、および11）に異なるポートペアを使用できます。
o A new Section 10 was added to explain the requirement for congestion control in applications using RTP.
o RTPを使用するアプリケーションでの輻輳制御の要件を説明するために、新しいセクション10が追加されました。
o In Section 8.2, the requirement that a new SSRC identifier MUST be chosen whenever the source transport address is changed has been relaxed to say that a new SSRC identifier MAY be chosen. Correspondingly, it was clarified that an implementation MAY choose to keep packets from the new source address rather than the existing source address when an SSRC collision occurs between two other participants, and SHOULD do so for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session.
o セクション8.2では、ソーストランスポートアドレスが変更されるたびに新しいSSRC識別子を選択する必要があるという要件が緩和され、新しいSSRC識別子を選択できる場合があります。同様に、他の2つの参加者間でSSRC衝突が発生した場合、実装は既存の送信元アドレスではなく新しい送信元アドレスからのパケットを保持することを選択できることを明確にし、モバイルなどの一部の送信元がテレフォニーなどのアプリケーションでそうする必要がある（SHOULD）エンティティは、RTPセッション中にアドレスを変更する場合があります。
o An indentation bug in the RFC 1889 printing of the pseudo-code for the collision detection and resolution algorithm in Section 8.2 has been corrected by translating the syntax to pseudo C language, and the algorithm has been modified to remove the restriction that both RTP and RTCP must be sent from the same source port number.
o セクション8.2の衝突検出および解決アルゴリズムの疑似コードのRFC 1889印刷におけるインデントのバグは、構文を疑似C言語に変換することによって修正され、アルゴリズムはRTPとRTCPの両方の制限を削除するように変更されました同じ送信元ポート番号から送信する必要があります。
o The description of the padding mechanism for RTCP packets was clarified and it is specified that padding MUST only be applied to the last packet of a compound RTCP packet.
o RTCPパケットのパディングメカニズムの説明が明確になり、パディングは複合RTCPパケットの最後のパケットにのみ適用する必要があると指定されています。
o In Section A.1, initialization of base_seq was corrected to be seq rather than seq - 1, and the text was corrected to say the bad sequence number plus 1 is stored. The initialization of max_seq and other variables for the algorithm was separated from the text to make clear that this initialization must be done in addition to calling the init_seq() function (and a few words lost in RFC 1889 when processing the document from source to output form were restored).
o セクションA.1では、base_seqの初期化がseq-1ではなくseqになるように修正され、テキストは不正なシーケンス番号+ 1が格納されていることを示すように修正されました。アルゴリズムのmax_seqおよび他の変数の初期化は、init_seq()関数の呼び出しに加えてこの初期化を実行する必要があること（およびドキュメントをソースから出力に処理するときにRFC 1889で失われるいくつかの単語）を明確にするために、テキストから分離されました。フォームが復元されました）。
o Clamping of number of packets lost in Section A.3 was corrected to use both positive and negative limits.
o セクションA.3で失われたパケット数のクランプは、正と負の両方の制限を使用するように修正されました。
o The specification of "relative" NTP timestamp in the RTCP SR section now defines these timestamps to be based on the most common system-specific clock, such as system uptime, rather than on session elapsed time which would not be the same for multiple applications started on the same machine at different times.
o RTCP SRセクションでの「相対」NTPタイムスタンプの仕様は、これらのタイムスタンプが、開始された複数のアプリケーションで同じではないセッションの経過時間ではなく、システムの稼働時間などの最も一般的なシステム固有のクロックに基づくように定義するようになりました。同じマシンで異なる時間に。
Non-functional changes:
非機能的な変更：
o It is specified that a receiver MUST ignore packets with payload types it does not understand.
o 受信者が理解できないペイロードタイプのパケットを無視しなければならないことが指定されています。
o In Fig. 2, the floating point NTP timestamp value was corrected, some missing leading zeros were added in a hex number, and the UTC timezone was specified.
o 図2では、浮動小数点のNTPタイムスタンプ値が修正され、欠落している先行ゼロが16進数で追加され、UTCタイムゾーンが指定されています。
o The inconsequence of NTP timestamps wrapping around in the year 2036 is explained.
o 2036年に循環するNTPタイムスタンプの重要性について説明します。
o The policy for registration of RTCP packet types and SDES types was clarified in a new Section 15, IANA Considerations. The suggestion that experimenters register the numbers they need and then unregister those which prove to be unneeded has been removed in favor of using APP and PRIV. Registration of profile names was also specified.
o RTCPパケットタイプとSDESタイプの登録ポリシーは、新しいセクション15、IANAの考慮事項で明確になりました。実験者が必要な数を登録してから、不要であることが判明した数を登録解除するという提案は、APPとPRIVの使用を支持して削除されました。プロファイル名の登録も指定されました。
o The reference for the UTF-8 character set was changed from an X/Open Preliminary Specification to be RFC 2279.
o UTF-8文字セットの参照は、X / Open暫定仕様からRFC 2279に変更されました。
o The reference for RFC 1597 was updated to RFC 1918 and the reference for RFC 2543 was updated to RFC 3261.
o RFC 1597のリファレンスはRFC 1918に更新され、RFC 2543のリファレンスはRFC 3261に更新されました。
o The last paragraph of the introduction in RFC 1889, which cautioned implementors to limit deployment in the Internet, was removed because it was deemed no longer relevant.
o RFC 1889での導入の最後の段落は、インターネットでの展開を制限するよう実装者に警告していましたが、もはや関連がないと見なされたため削除されました。
o A non-normative note regarding the use of RTP with Source-Specific Multicast (SSM) was added in Section 6.
o Source-Specific Multicast（SSM）でのRTPの使用に関する非規範的な注記がセクション6に追加されました。
o The definition of "RTP session" in Section 3 was expanded to acknowledge that a single session may use multiple destination transport addresses (as was always the case for a translator or mixer) and to explain that the distinguishing feature of an RTP session is that each corresponds to a separate SSRC identifier space. A new definition of "multimedia session" was added to reduce confusion about the word "session".
o セクション3の「RTPセッション」の定義は、単一のセッションが複数の宛先トランスポートアドレスを使用する可能性があること（トランスレータまたはミキサーの場合は常にそうであるように）を認め、RTPセッションの際立った機能はそれぞれ別のSSRC識別子スペースに対応します。 「マルチメディアセッション」の新しい定義が追加され、「セッション」という単語に関する混乱を減らします。
o The meaning of "sampling instant" was explained in more detail as part of the definition of the timestamp field of the RTP header in Section 5.1.
o 「サンプリングインスタント」の意味は、セクション5.1のRTPヘッダーのタイムスタンプフィールドの定義の一部として、より詳細に説明されました。
o Small clarifications of the text have been made in several places, some in response to questions from readers. In particular:
o 読者からの質問に答えるために、いくつかの場所でテキストの小さな明確化が行われました。特に：
- In RFC 1889, the first five words of the second sentence of Section 2.2 were lost in processing the document from source to output form, but are now restored.
- RFC 1889では、セクション2.2の2番目の文の最初の5ワードが、ソースから出力形式へのドキュメントの処理で失われましたが、現在は復元されています。
- A definition for "RTP media type" was added in Section 3 to allow the explanation of multiplexing RTP sessions in Section 5.2 to be more clear regarding the multiplexing of multiple media. That section also now explains that multiplexing multiple sources of the same medium based on SSRC identifiers may be appropriate and is the norm for multicast sessions.
- セクション3で「RTPメディアタイプ」の定義が追加され、セクション5.2でのRTPセッションの多重化の説明が、複数のメディアの多重化に関してより明確になるようになりました。そのセクションでは、SSRC識別子に基づく同じメディアの複数のソースの多重化が適切であり、マルチキャストセッションの標準であることも説明しています。
- The definition for "non-RTP means" was expanded to include examples of other protocols constituting non-RTP means.
- 「非RTP手段」の定義は、非RTP手段を構成する他のプロトコルの例を含むように拡張されました。
- The description of the session bandwidth parameter is expanded in Section 6.2, including a clarification that the control traffic bandwidth is in addition to the session bandwidth for the data traffic.
- セッション帯域幅パラメーターの説明は、制御トラフィック帯域幅がデータトラフィックのセッション帯域幅に追加されることの明確化を含めて、セクション6.2で拡張されています。
- The effect of varying packet duration on the jitter calculation was explained in Section 6.4.4.
- パケット期間の変化がジッターの計算に与える影響については、6.4.4項で説明しました。
- The method for terminating and padding a sequence of SDES items was clarified in Section 6.5.
- SDESアイテムのシーケンスを終了してパディングする方法は、セクション6.5で明確になりました。
- IPv6 address examples were added in the description of SDES CNAME in Section 6.5.1, and "example.com" was used in place of other example domain names.
- IPv6アドレスの例がセクション6.5.1のSDES CNAMEの説明に追加され、「example.com」が他の例のドメイン名の代わりに使用されました。
- The Security section added a formal reference to IPSEC now that it is available, and says that the confidentiality method defined in this specification is primarily to codify existing practice. It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm, and noted that the SRTP profile based on AES will be the correct choice in the future. A caution about the weakness of the RTP header as an initialization vector was added. It was also noted that payload-only encryption is necessary to allow for header compression.
- セキュリティのセクションでは、IPSECが利用できるようになったことを正式に参照し、この仕様で定義されている機密保持方法は主に既存の慣行を成文化することであると述べています。デフォルトのアルゴリズムの代わりにTriple-DESなどのより強力な暗号化アルゴリズムを使用することをお勧めします。将来的には、AESに基づくSRTPプロファイルが正しい選択になることに注意してください。初期化ベクトルとしてのRTPヘッダーの弱点に関する注意が追加されました。ペイロードのみの暗号化はヘッダー圧縮を可能にするために必要であることも指摘されました。
- The method for partial encryption of RTCP was clarified; in particular, SDES CNAME is carried in only one part when the compound RTCP packet is split.
- RTCPの部分暗号化の方法が明確になりました。特に、複合RTCPパケットが分割される場合、SDES CNAMEは1つの部分でのみ伝送されます。
- It is clarified that only one compound RTCP packet should be sent per reporting interval and that if there are too many active sources for the reports to fit in the MTU, then a subset of the sources should be selected round-robin over multiple intervals.
- レポート間隔ごとに1つの複合RTCPパケットのみを送信する必要があること、およびMTUに収まらないほどレポートのアクティブソースが多すぎる場合は、複数の間隔でソースのサブセットをラウンドロビンで選択する必要があることを明確にしました。
- A note was added in Appendix A.1 that packets may be saved during RTP header validation and delivered upon success.
- 付録A.1に、RTPヘッダーの検証中にパケットが保存され、成功時に配信されるというメモが追加されました。
- Section 7.3 now explains that a mixer aggregating SDES packets uses more RTCP bandwidth due to longer packets, and a mixer passing through RTCP naturally sends packets at higher than the single source rate, but both behaviors are valid.
- セクション7.3では、SDESパケットを集約するミキサーは、パケットが長いためにRTCP帯域幅をより多く使用し、RTCPを通過するミキサーは、単一のソースレートよりも高い速度でパケットを送信するが、どちらの動作も有効であることを説明します。
- Section 13 clarifies that an RTP application may use multiple profiles but typically only one in a given session.
- セクション13では、RTPアプリケーションが複数のプロファイルを使用する場合があることを明記していますが、通常、特定のセッションでは1つのみです。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 2119.
- RFC 2119で定義されているように、MUST、SHOULD、MAYなどの用語が使用されます。
- The bibliography was divided into normative and informative references.
- 参考文献は、規範的および有益な参考文献に分けられました。
References
参考文献
Normative References
引用文献
[1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[1] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、RFC 3551、2003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[4] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、Marc 1992。
[5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 2279, January 1998.
[5] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[6] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[7] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[7] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月。
[8] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[8] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick、P。、「Internet Message Format」、RFC 2822、2001年4月。
Informative References
参考引用
[10] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE Computer Communications Review, Vol. 20(4), September 1990.
[10] SIGCOMM Symposium on Communications Architectures and Protocols（Philadelphia、Pennsylvania）、pp。200--208、IEEE Computer Communications Review、Vol。2の「新世代プロトコルのアーキテクチャに関する考慮事項」、クラークD.およびD.テネンハウス20（4）、1990年9月。
[11] Schulzrinne, H., "Issues in designing a transport protocol for audio and video conferences and other multiparticipant real-time applications." expired Internet Draft, October 1993.
[11] Schulzrinne、H.、「オーディオおよびビデオ会議、および他の複数参加者のリアルタイムアプリケーション用のトランスポートプロトコルを設計する際の問題。」 1993年10月にインターネットドラフトが期限切れになりました。
[12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.
[12] Comer、D.、TCP / IPによるインターネットワーキング、vol。 1.ニュージャージー州イングルウッドクリフス：プレンティスホール、1991年。
[13] 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.
[13] Rosenberg、J.、Schulzrinne、H.、Camariillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261、 2002年6月。
[14] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[14] 国際電気通信連合、「非保証のサービス品質を提供するローカルエリアネットワーク用のビジュアル電話システムおよび機器」、勧告H.323、ITUの電気通信標準化部門、スイス、ジュネーブ、2003年7月。
[15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[15] Handley、M。およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne、H.、Rao、A。およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[17] Eastlake 3rd、D.、Crocker、S. and J. Schiller、 "Randomness Recommendations for Security"、RFC 1750、December 1994。
[18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet", in SIGCOMM Symposium on Communications Architectures and Protocols, (London, England), pp. 58--67, ACM, August 1994.
[18] Bolot、J.-C.、Turletti、T. and I. Wakeman、 "Scalable Feedback Control for Multicast Video Distribution in the Internet"、SIGCOMM Symposium on Communications Architectures and Protocols（London、England）、pp.58-- 67、ACM、1994年8月。
[19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control of Multimedia Applications Based on RTP", Computer Communications , vol. 19, pp. 49--58, January 1996.
[19] Busse、I.、Deffner、B。およびH. Schulzrinne、「RTPに基づくマルチメディアアプリケーションの動的QoS制御」、Computer Communications、vol。 19、49-58ページ、1996年1月。
[20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, September 1993. Also in [34].
[20] Floyd、S. and V. Jacobson、 "The Synchronization of Periodic Routing Messages"、SIGCOMM Symposium on Communications Architectures and Protocols（DP Sidhu、ed。）、（San Francisco、California）、pp。33--44、ACM、 1993年9月。[34]にも。
[21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[21] Rosenberg、J。およびH. Schulzrinne、「RTPでのグループメンバーシップのサンプリング」、RFC 2762、2000年2月。
[22] Cadzow, J., Foundations of Digital Signal Processing and Data Analysis New York, New York: Macmillan, 1987.
[22] Cadzow、J.、Foundations of Digital Signal Processing and Data Analysis New York、New York：Macmillan、1987。
[23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[23] Hinden、R。およびS. Deering、「Internet Protocol Version 6（IPv6）Addressing Architecture」、RFC 3513、2003年4月。
[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[24] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。およびE. Lear、「プライベートインターネットのアドレス割り当て」、RFC 1918、1996年2月。
[25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 1627, July 1994.
[25] リア、E。、フェア、E。、クロッカー、D.、T。ケスラー、「ネットワーク10は有害と見なされる（一部の慣行は成文化すべきではない）」、RFC 1627、1994年7月。
[26] Feller, W., An Introduction to Probability Theory and its Applications, vol. 1. New York, New York: John Wiley and Sons, third ed., 1968.
[26] Feller、W.、An Introduction to Probability Theory and its Applications、vol。 1.ニューヨーク、ニューヨーク：ジョンワイリーアンドサンズ、第3版、1968。
[27] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[27] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. and D. Oran, "Secure Real-time Transport Protocol", Work in Progress, April 2003.
[28] バウアーM.、ブロムR.、カララE.、マクルーグD.、ナスルンドM.、ノーマンK.およびD.オラン、「Secure Real-time Transport Protocol」、Work in Progress、2003年4月。
[29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III", RFC 1423, February 1993.
[29] バレンソンD.、「インターネット電子メールのプライバシー強化：パートIII」、RFC 1423、1993年2月。
[30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171, June 1983.
[30] Voydock、V。およびS.ケント、「高レベルネットワークプロトコルのセキュリティメカニズム」、ACM Computing Surveys、vol。 15、pp。135-171、1983年6月。
[31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[31] Floyd、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[32] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[33] Stubblebine, S., "Security Services for Multimedia Conferencing", in 16th National Computer Security Conference, (Baltimore, Maryland), pp. 391--395, September 1993.
[33] Stubblebine、S。、「マルチメディア会議のためのセキュリティサービス」、第16回全国コンピュータセキュリティ会議（メリーランド州ボルチモア）、391-395ページ、1993年9月。
[34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, vol. 2, pp. 122--136, April 1994.
[34] Floyd、S.およびV. Jacobson、「The Synchronization of Periodic Routing Messages」、IEEE / ACM Transactions on Networking、vol。 2、pp.122-136、1994年4月。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
ヘニングシュルズリンネコンピュータサイエンス学科コロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ合衆国
EMail: schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L.Casner Packet Design 3400 Hillview Avenue、Building 3 Palo Alto、CA 94304アメリカ合衆国
EMail: casner@acm.org
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale、CA 94085アメリカ合衆国
EMail: ronf@bluecoat.com
Van Jacobson Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Van Jacobson Packet Design 3400 Hillview Avenue、Building 3 Palo Alto、CA 94304アメリカ合衆国
EMail: van@packetdesign.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。