[要約] RFC 4588は、RTP再送信ペイロード形式に関する標準仕様であり、パケットロスの影響を軽減するために再送信をサポートします。目的は、リアルタイム通信の品質を向上させることです。
Network Working Group J. Rey
Request for Comments: 4588 Panasonic
Category: Standards Track D. Leon
Consultant
A. Miyazaki
Panasonic
V. Varsa
Nokia
R. Hakenberg
Panasonic
July 2006
RTP Retransmission Payload Format
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.
RTP再送信は、リラックスした遅延境界を備えたリアルタイムアプリケーションの効果的なパケット損失回復手法です。このドキュメントでは、再送信を実行するためのRTPペイロード形式について説明します。再送信されたRTPパケットは、元のRTPストリームから別のストリームで送信されます。受信者から送信者へのフィードバックが利用可能であると想定されています。特に、RTCPベースのフィードバックの拡張RTPプロファイル（RTP/AVPFを示します）の拡張RTPプロファイルで定義されているリアルタイムトランスポートコントロールプロトコル（RTCP）フィードバックがこのメモで利用できると想定されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements and Design Rationale for a Retransmission Scheme ...4
3.1. Multiplexing Scheme Choice .................................6
4. Retransmission Payload Format ...................................7
5. Association of Retransmission and Original Streams ..............9
5.1. Retransmission Session Sharing .............................9
5.2. CNAME Use ..................................................9
5.3. Association at the Receiver ................................9
6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1. RTCP at the Sender ........................................11
6.2. RTCP Receiver Reports .....................................11
6.3. Retransmission Requests ...................................12
6.4. Timing Rules ..............................................13
7. Congestion Control .............................................13
8. Retransmission Payload Format MIME Type Registration ...........15
8.1. Introduction ..............................................15
8.2. Registration of audio/rtx .................................16
8.3. Registration of video/rtx .................................17
8.4. Registration of text/rtx ..................................18
8.5. Registration of application/rtx ...........................19
8.6. Mapping to SDP ............................................20
8.7. SDP Description with Session-Multiplexing .................20
8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP Considerations ............................................22
9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2. RTSP Control with Session-Multiplexing ....................22
9.3. RTSP Control of the Retransmission Stream .................23
9.4. Cache Control .............................................23
10. Implementation Examples .......................................23
10.1. A Minimal Receiver Implementation Example ................24
10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA Considerations ...........................................26
12. Security Considerations .......................................26
13. Acknowledgements ..............................................27
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
Appendix A. How to Control the Number of Rtxs. per Packet .........29
Packet losses between an RTP sender and receiver may significantly degrade the quality of the received media. Several techniques, such as forward error correction (FEC), retransmissions, or interleaving, may be considered to increase packet loss resiliency. RFC 2354 [8] discusses the different options.
RTP送信者とレシーバー間のパケット損失は、受信されたメディアの品質を大幅に低下させる可能性があります。フォワードエラー補正（FEC）、再送信、またはインターリーブなどのいくつかの手法は、パケット損失の回復力を高めると見なされる場合があります。RFC 2354 [8]は、さまざまなオプションについて説明します。
When choosing a repair technique for a particular application, the tolerable latency of the application has to be taken into account. In the case of multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds in order to guarantee interactivity, which usually excludes the use of retransmission.
特定のアプリケーションの修理手法を選択する場合、アプリケーションの許容可能なレイテンシを考慮する必要があります。マルチメディア会議の場合、インタラクティブ性を保証するために、エンドツーエンドの遅延は、通常は再送信の使用を除外するインタラクティブ性を保証するために、せいぜい数百ミリ秒でなければなりません。
With sufficient latency, the efficiency of the repair scheme can be increased. The sender may use the receiver feedback in order to react to losses before their playout time at the receiver.
十分な遅延により、修理スキームの効率を向上させることができます。送信者は、レシーバーでのプレイアウト時間の前に損失に対応するために、受信機フィードバックを使用できます。
In the case of multimedia streaming, the user can tolerate an initial latency as part of the session set-up and thus an end-to-end delay of several seconds may be acceptable. RTP retransmission as defined in this document is targeted at such applications.
マルチメディアストリーミングの場合、ユーザーはセッションのセットアップの一部として初期遅延を許容できるため、数秒のエンドツーエンドの遅延が許容される場合があります。このドキュメントで定義されているRTPの再送信は、そのようなアプリケーションを対象としています。
Furthermore, the RTP retransmission method defined herein is applicable to unicast and (small) multicast groups. The present document defines a payload format for retransmitted RTP packets and provides protocol rules for the sender and the receiver involved in retransmissions.
さらに、本明細書で定義されているRTP再送信方法は、ユニキャストおよび（小）マルチキャストグループに適用できます。現在のドキュメントでは、再送信されたRTPパケットのペイロード形式を定義し、送信者と再送信に関与する受信者のプロトコルルールを提供します。
This retransmission payload format was designed for use with the extended RTP profile for RTCP-based feedback, AVPF [1]. It may also be used with other RTP profiles defined in the future.
この再送信ペイロード形式は、RTCPベースのフィードバックAVPF [1]の拡張RTPプロファイルで使用するために設計されました。また、将来定義されている他のRTPプロファイルでも使用できます。
The AVPF profile allows for more frequent feedback and for early feedback. It defines a general-purpose feedback message, i.e., NACK, as well as codec and application-specific feedback messages. See [1] for details.
AVPFプロファイルにより、より頻繁なフィードバックと早期フィードバックが可能になります。汎用フィードバックメッセージ、つまりNACK、およびCodecおよびアプリケーション固有のフィードバックメッセージを定義します。詳細については、[1]を参照してください。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
CSRC: contributing source. See [3].
CSRC：寄稿ソース。[3]を参照してください。
Original packet: an RTP packet that carries user data sent for the first time by an RTP sender.
元のパケット：RTP送信者から初めて送信されたユーザーデータを運ぶRTPパケット。
Original stream: the RTP stream of original packets.
オリジナルストリーム：元のパケットのRTPストリーム。
Retransmission packet: an RTP packet that is to be used by the receiver instead of a lost original packet. Such a retransmission packet is said to be associated with the original RTP packet.
再送信パケット：紛失した元のパケットの代わりにレシーバーが使用するRTPパケット。このような再送信パケットは、元のRTPパケットに関連付けられていると言われています。
Retransmission request: a means by which an RTP receiver is able to request that the RTP sender should send a retransmission packet for a given original packet. Usually, an RTCP NACK packet as specified in [1] is used as retransmission request for lost packets.
再送信リクエスト：RTPレシーバーがRTP送信者が特定の元のパケットの再送信パケットを送信することを要求できる手段。通常、[1]で指定されているRTCP NACKパケットは、失われたパケットの再送信要求として使用されます。
Retransmission stream: the stream of retransmission packets associated with an original stream.
再送信ストリーム：元のストリームに関連付けられた再送信パケットのストリーム。
Session-multiplexing: scheme by which the original stream and the associated retransmission stream are sent into two different RTP sessions.
セッションマルチプレックス：元のストリームと関連する再送信ストリームが2つの異なるRTPセッションに送信されるスキーム。
SSRC: synchronization source. See [3].
SSRC：同期ソース。[3]を参照してください。
SSRC-multiplexing: scheme by which the original stream and the retransmission stream are sent in the same RTP session with different SSRC values.
SSRC-Multiplexing：元のストリームと再送信ストリームが異なるSSRC値で同じRTPセッションで送信されるスキーム。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2]に記載されているように解釈される。
The use of retransmissions in RTP as a repair method for streaming media is appropriate in those scenarios with relaxed delay bounds and where full reliability is not a requirement. More specifically, RTP retransmission allows one to trade off reliability vs. delay; i.e., the endpoints may give up retransmitting a lost packet after a given buffering time has elapsed. Unlike TCP, there is thus no head-of-line blocking caused by RTP retransmissions. The implementer should be aware that in cases where full reliability is required or higher delay and jitter can be tolerated, TCP or other transport options should be considered.
リラックスした遅延境界と完全な信頼性が要件ではない場合、メディアをストリーミングするための修復方法としてRTPでの再送信を使用することは適切です。より具体的には、RTPの再送信により、信頼性と遅延をトレードオフすることができます。つまり、エンドポイントは、特定のバッファリング時間が経過した後、失われたパケットを再送信することをあきらめる可能性があります。TCPとは異なり、RTPの再送信によって引き起こされる頭のブロックはありません。実装者は、完全な信頼性が必要またはより高い遅延とジッターを許容できる場合、TCPまたはその他の輸送オプションを考慮する必要があることに注意する必要があります。
The RTP retransmission scheme defined in this document is designed to fulfill the following set of requirements:
このドキュメントで定義されているRTP再送信スキームは、次の要件を満たすように設計されています。
1. It must not break general RTP and RTCP mechanisms. 2. It must be suitable for unicast and small multicast groups. 3. It must work with mixers and translators. 4. It must work with all known payload types. 5. It must not prevent the use of multiple payload types in a session.
1. 一般的なRTPおよびRTCPメカニズムを破ってはなりません。2.ユニキャストおよび小さなマルチキャストグループに適している必要があります。3.ミキサーと翻訳者で動作する必要があります。4.すべての既知のペイロードタイプで動作する必要があります。5.セッションで複数のペイロードタイプの使用を防止してはなりません。
6. In order to support the largest variety of payload formats, the RTP receiver must be able to derive how many and which RTP packets were lost as a result of a gap in received RTP sequence numbers. This requirement is referred to as sequence number preservation. Without such a requirement, it would be impossible to use retransmission with payload formats, such as conversational text [9] or most audio/video streaming applications, that use the RTP sequence number to detect lost packets.
6. 最大の種類のペイロード形式をサポートするために、RTPレシーバーは、受信したRTPシーケンス番号のギャップの結果として、どれだけのRTPパケットが失われたかを導き出すことができなければなりません。この要件は、シーケンス番号の保存と呼ばれます。このような要件がなければ、RTPシーケンス番号を使用して失われたパケットを検出する、会話テキスト[9]やほとんどのオーディオ/ビデオストリーミングアプリケーションなどのペイロード形式で再送信を使用することは不可能です。
When designing a solution for RTP retransmission, several approaches may be considered for the multiplexing of the original RTP packets and the retransmitted RTP packets.
RTPの再送信のソリューションを設計する場合、元のRTPパケットと再送信されたRTPパケットの多重化には、いくつかのアプローチが考慮される場合があります。
One approach may be to retransmit the RTP packet with its original sequence number and send original and retransmission packets in the same RTP stream. The retransmission packet would then be identical to the original RTP packet, i.e., the same header (and thus same sequence number) and the same payload. However, such an approach is not acceptable because it would corrupt the RTCP statistics. As a consequence, requirement 1 would not be met. Correct RTCP statistics require that for every RTP packet within the RTP stream, the sequence number be increased by one.
1つのアプローチは、元のシーケンス番号でRTPパケットを再送信し、同じRTPストリームで元の再送信パケットを送信することです。再送信パケットは、元のRTPパケット、つまり同じヘッダー（したがって同じシーケンス番号）と同じペイロードと同一になります。ただし、このようなアプローチは、RTCP統計が破損するため、受け入れられません。結果として、要件1は満たされません。正しいRTCP統計には、RTPストリーム内のすべてのRTPパケットについて、シーケンス数が1つ増加することが必要です。
Another approach may be to multiplex original RTP packets and retransmission packets in the same RTP stream using different payload type values. With such an approach, the original packets and the retransmission packets would share the same sequence number space. As a result, the RTP receiver would not be able to infer how many and which original packets (which sequence numbers) were lost.
別のアプローチは、異なるペイロードタイプの値を使用して、同じRTPストリームの元のRTPパケットと再送信パケットをマルチプレックスすることです。このようなアプローチを使用すると、元のパケットと再送信パケットが同じシーケンス番号スペースを共有します。その結果、RTPレシーバーは、どれだけの元のパケット（シーケンス番号）が失われたかを推測できません。
In other words, this approach does not satisfy the sequence number preservation requirement (requirement 6). This in turn implies that requirement 4 would not be met. Interoperability with mixers and translators would also be more difficult if they did not understand this new retransmission payload type in a sender RTP stream. For these reasons, a solution based on payload type multiplexing of original packets and retransmission packets in the same RTP stream is excluded.
言い換えれば、このアプローチは、シーケンス番号の保存要件を満たしていません（要件6）。これは、要件4が満たされないことを意味します。ミキサーと翻訳者との相互運用性も、送信者RTPストリームでこの新しい再送信ペイロードタイプを理解していない場合、より困難です。これらの理由により、同じRTPストリームの元のパケットのペイロードタイプの多重化と再送信パケットに基づくソリューションは除外されます。
Finally, the original and retransmission packets may be sent in two separate streams. These two streams may be multiplexed either by sending them in two different sessions , i.e., session-multiplexing, or in the same session using different SSRC values, i.e., SSRC-multiplexing. Since original and retransmission packets carry media of the same type, the objections in Section 5.2 of RTP [3] to RTP multiplexing do not apply in this case.
最後に、元の再送信パケットは2つの別々のストリームで送信できます。これらの2つのストリームは、2つの異なるセッション、つまりセッションマルチプレックス、または異なるSSRC値、つまりSSRC-Multiplexingを使用して同じセッションで送信することにより、多重化される場合があります。元の再送信パケットは同じタイプのメディアを搭載しているため、この場合、RTP [3]からRTPマルチプレックスのセクション5.2の異議は適用されません。
Mixers and translators may process the original stream and simply discard the retransmission stream if they are unable to utilise it.
ミキサーと翻訳者は、元のストリームを処理し、それを利用できない場合は再送信ストリームを単純に破棄することができます。
On the other hand, sending the original and retransmission packets in two separate streams does not alone satisfy requirements 1 and 6. For this purpose, this document includes the original sequence number in the retransmitted packets.
一方、2つの別々のストリームで元の再送信パケットを送信すると、要件1と6を満たすだけではありません。この目的のために、このドキュメントには再送信パケットに元のシーケンス番号が含まれています。
In this manner, using two separate streams satisfies all the requirements listed in this section.
この方法で、2つの別々のストリームを使用すると、このセクションにリストされているすべての要件が満たされます。
Session-multiplexing and SSRC-multiplexing have different pros and cons:
セッションのマルチプレックスとSSRCマルチプレックスには、長所と短所が異なります。
Session-multiplexing is based on sending the retransmission stream in a different RTP session (as defined in RTP [3]) from that of the original stream; i.e., the original and retransmission streams are sent to different network addresses and/or port numbers. Having a separate session allows more flexibility. In multicast, using two separate sessions for the original and the retransmission streams allows a receiver to choose whether or not to subscribe to the RTP session carrying the retransmission stream. The original session may also be single-source multicast while separate unicast sessions are used to convey retransmissions to each of the receivers, which as a result will receive only the retransmission packets they request.
セッションマルチプレックスは、元のストリームからの別のRTPセッション（RTP [3]で定義されている）で再送信ストリームを送信することに基づいています。つまり、元の再送信ストリームと再送信ストリームは、異なるネットワークアドレスおよび/またはポート番号に送信されます。個別のセッションを持つことで、柔軟性が向上します。マルチキャストでは、オリジナルと再送信ストリームに2つの個別のセッションを使用すると、受信者は再送信ストリームを運ぶRTPセッションを購読するかどうかを選択できます。元のセッションはシングルソースのマルチキャストである場合がありますが、個別のユニキャストセッションを使用して各レシーバーに再送信を伝えるために使用されます。その結果、リクエストした再送信パケットのみが受信されます。
The use of separate sessions also facilitates differential treatment by the network and may simplify processing in mixers, translators, and packet caches.
また、個別のセッションを使用すると、ネットワークによる微分処理が促進され、ミキサー、翻訳者、パケットキャッシュの処理が簡素化される場合があります。
With SSRC-multiplexing, a single session is needed for the original and the retransmission streams. This allows streaming servers and middleware that are involved in a high number of concurrent sessions to minimise their port usage.
SSRC-Multiplexingを使用すると、オリジナルと再送信ストリームに1回のセッションが必要です。これにより、ポートの使用量を最小限に抑えるために、多数の同時セッションに関与するストリーミングサーバーとミドルウェアが可能になります。
This retransmission payload format allows both session-multiplexing and SSRC-multiplexing for unicast sessions. From an implementation point of view, there is little difference between the two approaches. Hence, in order to maximise interoperability, both multiplexing approaches SHOULD be supported by senders and receivers. For multicast sessions, session-multiplexing MUST be used because the association of the original stream and the retransmission stream is problematic if SSRC-multiplexing is used with multicast sessions(see Section 5.3 for motivation).
この再送信ペイロード形式により、ユニキャストセッションのセッションマルチプレックスとSSRCマルチプレックスの両方が可能になります。実装の観点からは、2つのアプローチにはほとんど違いがありません。したがって、相互運用性を最大化するには、両方の多重化アプローチを送信者と受信者によってサポートする必要があります。マルチキャストセッションの場合、SSRCマルチプレックスがマルチキャストセッションで使用される場合、元のストリームと再送信ストリームの関連に問題があるため、セッションのマルチプレックスを使用する必要があります（モチベーションについてはセクション5.3を参照）。
The format of a retransmission packet is shown below:
再送信パケットの形式を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP header usage is as follows:
RTPヘッダーの使用は次のとおりです。
In the case of session-multiplexing, the same SSRC value MUST be used for the original stream and the retransmission stream. In the case of an SSRC collision in either the original session or the retransmission session, the RTP specification requires that an RTCP BYE packet MUST be sent in the session where the collision happened. In addition, an RTCP BYE packet MUST also be sent for the associated stream in its own session. After a new SSRC identifier is obtained, the SSRC of both streams MUST be set to this value.
セッションのマルチプレックスの場合、元のストリームと再送信ストリームに同じSSRC値を使用する必要があります。元のセッションまたは再送信セッションのいずれかでのSSRC衝突の場合、RTP仕様では、衝突が発生したセッションでRTCPバイパケットを送信する必要があります。さらに、RTCP Byeパケットも、独自のセッションで関連するストリームに送信する必要があります。新しいSSRC識別子が取得された後、両方のストリームのSSRCをこの値に設定する必要があります。
In the case of SSRC-multiplexing, two different SSRC values MUST be used for the original stream and the retransmission stream as required by RTP. If an SSRC collision is detected for either the original stream or the retransmission stream, the RTP specification requires that an RTCP BYE packet MUST be sent for this stream. An RTCP BYE packet MUST NOT be sent for the associated stream. Therefore, only the stream that experienced SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 for the implications on the original stream and retransmission stream SSRC association at the receiver.
SSRCマルチプレックスの場合、RTPで要求される元のストリームと再送信ストリームに2つの異なるSSRC値を使用する必要があります。元のストリームまたは再送信ストリームのいずれかでSSRC衝突が検出された場合、RTP仕様では、このストリームに対してRTCPバイパケットを送信する必要があります。RTCP Byeパケットは、関連するストリームに送信してはなりません。したがって、SSRC衝突を経験したストリームのみが、新しいSSRC値を選択する必要があります。受信機の元のストリームおよび再送信ストリームSSRC協会の影響については、セクション5.3を参照してください。
For either multiplexing scheme, the sequence number has the standard definition; i.e., it MUST be one higher than the sequence number of the preceding packet sent in the retransmission stream.
いずれかの多重化スキームの場合、シーケンス番号には標準定義があります。つまり、再送信ストリームで送信される前のパケットのシーケンス番号よりも1つ高い必要があります。
The retransmission packet timestamp MUST be set to the original timestamp, i.e., to the timestamp of the original packet. As a consequence, the initial RTP timestamp for the first packet of the retransmission stream is not random but equal to the original timestamp of the first packet that is retransmitted. See the Security Considerations section in this document for security implications.
再送信パケットタイムスタンプは、元のタイムスタンプ、つまり元のパケットのタイムスタンプに設定する必要があります。結果として、再送信ストリームの最初のパケットの最初のRTPタイムスタンプは、ランダムではなく、再送信された最初のパケットの元のタイムスタンプに等しくなります。セキュリティへの影響については、このドキュメントのセキュリティに関する考慮事項セクションを参照してください。
Implementers have to be aware that the RTCP jitter value for the retransmission stream does not reflect the actual network jitter since there could be little correlation between the time a packet is retransmitted and its original timestamp.
実装者は、再送信ストリームのRTCPジッター値が実際のネットワークジッターを反映していないことに注意する必要があります。これは、パケットが再送信される時間とその元のタイムスタンプの間にはほとんど相関がない可能性があるためです。
The payload type is dynamic. If multiple payload types using retransmission are present in the original stream, then for each of these, a dynamic payload type MUST be mapped to the retransmission payload format. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done with Session Description Protocol (SDP).
ペイロードタイプは動的です。再送信を使用した複数のペイロードタイプが元のストリームに存在する場合、これらのそれぞれについて、動的なペイロードタイプを再送信ペイロード形式にマッピングする必要があります。セッション説明プロトコル（SDP）では、元のペイロードタイプと再送信ペイロードタイプのマッピングがどのように行われるかの仕様については、セクション8.1を参照してください。
As the retransmission packet timestamp carries the original media timestamp, the timestamp clockrate used by the retransmission payload type MUST be the same as the one used by the associated original payload type. Therefore, if an RTP stream carries payload types of different clockrates, this will also be the case for the associated retransmission stream. Note that an RTP stream does not usually carry payload types of different clockrates.
再送信パケットのタイムスタンプには元のメディアタイムスタンプが含まれているため、再送信ペイロードタイプで使用されるタイムスタンプ時計レートは、関連する元のペイロードタイプで使用されているものと同じでなければなりません。したがって、RTPストリームが異なる時計のペイロードタイプを搭載している場合、これは関連する再送信ストリームの場合にも当てはまります。RTPストリームは、通常、異なる時計のペイロードタイプを運ばないことに注意してください。
The payload of the RTP retransmission packet comprises the retransmission payload header followed by the payload of the original RTP packet. The length of the retransmission payload header is 2 octets. This payload header contains only one field, OSN (original sequence number), which MUST be set to the sequence number of the associated original RTP packet. The original RTP packet payload, including any possible payload headers specific to the original payload type, MUST be placed right after the retransmission payload header.
RTP再送信パケットのペイロードは、再送信ペイロードヘッダーに続いて元のRTPパケットのペイロードを含みます。再送信ペイロードヘッダーの長さは2オクテットです。このペイロードヘッダーには、1つのフィールド、OSN（元のシーケンス番号）のみが含まれています。これは、関連する元のRTPパケットのシーケンス番号に設定する必要があります。元のペイロードタイプに固有の可能なペイロードヘッダーを含む元のRTPパケットペイロードは、再送信ペイロードヘッダーの直後に配置する必要があります。
For payload formats that support encoding at multiple rates, instead of retransmitting the same payload as the original RTP packet the sender MAY retransmit the same data encoded at a lower rate. This aims at limiting the bandwidth usage of the retransmission stream. When doing so, the sender MUST ensure that the receiver will still be able to decode the payload of the already sent original packets that might have been encoded based on the payload of the lost original packet. In addition, if the sender chooses to retransmit at a lower rate, the values in the payload header of the original RTP packet may no longer apply to the retransmission packet and may need to be modified in the retransmission packet to reflect the change in rate. The sender SHOULD trade off the decrease in bandwidth usage with the decrease in quality caused by resending at a lower rate.
複数のレートでエンコードをサポートするペイロード形式の場合、元のRTPパケットと同じペイロードを再送信する代わりに、送信者は低レートでエンコードされた同じデータを再送信することができます。これは、再送信ストリームの帯域幅の使用を制限することを目的としています。そうする場合、送信者は、紛失した元のパケットのペイロードに基づいてエンコードされた可能性のある、すでに送信された元のパケットのペイロードをレシーバーが引き続きデコードできるようにする必要があります。さらに、送信者がより低いレートで再送信することを選択した場合、元のRTPパケットのペイロードヘッダーの値は再送信パケットに適用されなくなる場合があり、レートの変更を反映するために再送信パケットで変更する必要があります。送信者は、帯域幅の使用量の減少をトレードオフする必要があり、低速度で復活することによって引き起こされる品質の低下を行います。
If the original RTP header carried any profile-specific extensions, the retransmission packet SHOULD include the same extensions immediately following the fixed RTP header as expected by applications running under this profile. In this case, the retransmission payload header MUST be placed after the profile-specific extensions.
元のRTPヘッダーがプロファイル固有の拡張機能を搭載した場合、再送信パケットには、このプロファイルの下で実行されているアプリケーションが予想していると同じように、固定RTPヘッダーの直後に同じ拡張機能を含める必要があります。この場合、再送信ペイロードヘッダーは、プロファイル固有の拡張機能の後に配置する必要があります。
If the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension. This header extension MUST be placed right after the fixed RTP header, as specified in RTP [3]. In this case, the retransmission payload header MUST be placed after the header extension.
元のRTPヘッダーがRTPヘッダー拡張機能を搭載した場合、再送信パケットは同じヘッダー拡張機能を搭載する必要があります。このヘッダー拡張は、RTP [3]で指定されているように、固定RTPヘッダーの直後に配置する必要があります。この場合、再送信ペイロードヘッダーは、ヘッダー拡張後に配置する必要があります。
If the original RTP packet contained RTP padding, that padding MUST be removed before constructing the retransmission packet. If padding of the retransmission packet is needed, padding MUST be performed as with any RTP packets and the padding bit MUST be set.
元のRTPパケットにRTPパディングが含まれていた場合、そのパディングは再送信パケットを作成する前に取り外す必要があります。再送信パケットのパディングが必要な場合は、RTPパケットと同様にパディングを実行する必要があり、パディングビットを設定する必要があります。
The marker bit (M), the CSRC count (CC), and the CSRC list of the original RTP header MUST be copied "as is" into the RTP header of the retransmission packet.
マーカービット（M）、CSRCカウント（CC）、および元のRTPヘッダーのCSRCリストは、再送信パケットのRTPヘッダーに「現状のまま」にコピーする必要があります。
In the case of session-multiplexing, a retransmission session MUST map to exactly one original session; i.e., the same retransmission session cannot be used for different original sessions.
セッションの倍率の場合、再送信セッションは正確に1つの元のセッションにマッピングする必要があります。つまり、同じ再送信セッションをさまざまなオリジナルセッションに使用することはできません。
If retransmission session sharing were allowed, it would be a problem for receivers, since they would receive retransmissions for original sessions they might not have joined. For example, a receiver wishing to receive only audio would receive also retransmitted video packets if an audio and video session shared the same retransmission session.
再送信セッションの共有が許可された場合、参加者が参加していない可能性のある元のセッションの再送信を受け取るため、受信者にとっては問題になります。たとえば、オーディオのみを受信したいレシーバーは、オーディオとビデオセッションが同じ再送信セッションを共有した場合に再送信されたビデオパケットも受信します。
In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same RTCP CNAME [3] for an original stream and its associated retransmission stream.
セッションのマルチプレックスとSSRCマルチプレックスの両方で、送信者は、元のストリームとそれに関連する再送信ストリームに同じRTCP CNAME [3]を使用する必要があります。
A receiver receiving multiple original and retransmission streams needs to associate each retransmission stream with its original stream. The association is done differently depending on whether session-multiplexing or SSRC-multiplexing is used.
複数のオリジナルおよび再送信ストリームを受信するレシーバーは、各再送信ストリームを元のストリームに関連付ける必要があります。関連性は、セッションの混乱またはSSRCマルチプレックスが使用されるかどうかによって異なる方法で行われます。
If session-multiplexing is used, the receiver associates the two streams having the same SSRC in the two sessions. Note that the payload type field cannot be used to perform the association as several media streams may have the same payload type value. The two sessions are themselves associated out-of-band. See Section 8 for how the grouping of the two sessions is done with SDP.
セッションの総屈曲を使用すると、受信者は2つのセッションで同じSSRCを持つ2つのストリームを関連付けます。いくつかのメディアストリームが同じペイロードタイプの値を持っている可能性があるため、ペイロードタイプフィールドを使用することはできないことに注意してください。2つのセッション自体が帯域外に関連付けられています。2つのセッションのグループ化がSDPでどのように行われるかについては、セクション8を参照してください。
If SSRC-multiplexing is used, the receiver should first of all look for two streams that have the same CNAME in the session. In some cases, the CNAME may not be enough to determine the association as multiple original streams in the same session may share the same CNAME. For example, there can be in the same video session multiple video streams mapping to different SSRCs and still using the same CNAME and possibly the same payload type (PT) values. Each (or some) of these streams may have an associated retransmission stream.
SSRC-Multiplexingが使用される場合、レシーバーはまずセッションで同じCNAMEを持つ2つのストリームを探す必要があります。場合によっては、同じセッションの複数の元のストリームが同じcnameを共有する可能性があるため、cnameは関連性を決定するのに十分ではない場合があります。たとえば、同じビデオセッションでは、複数のビデオストリームを異なるSSRCにマッピングし、同じCNAMEとおそらく同じペイロードタイプ（PT）値を使用することができます。これらのストリームのそれぞれ（または一部）には、関連する再送信ストリームがある場合があります。
In this case, in order to find out the association between original and retransmission streams having the same CNAME, the receiver SHOULD behave as follows.
この場合、同じcnameを持つ元の再送信ストリームと再送信ストリームの関連性を見つけるために、受信者は次のように動作する必要があります。
The association can generally be resolved when the receiver receives a retransmission packet matching a retransmission request that had been sent earlier. Upon reception of a retransmission packet whose original sequence number has been previously requested, the receiver can derive that the SSRC of the retransmission packet is associated to the sender SSRC from which the packet was requested.
協会は一般に、以前に送信された再送信要求に一致する再送信パケットを受信したときに解決できます。元のシーケンス番号が以前に要求された再送信パケットを受信すると、受信者は再送信パケットのSSRCがパケットが要求された送信者SSRCに関連付けられていることを導き出すことができます。
However, this mechanism might fail if there are two outstanding requests for the same packet sequence number in two different original streams of the session. Note that since the initial packet sequence numbers are random, the probability of having two outstanding requests for the same packet sequence number would be very small. Nevertheless, in order to avoid ambiguity in the unicast case, the receiver MUST NOT have two outstanding requests for the same packet sequence number in two different original streams before the association is resolved. In multicast, this ambiguity cannot be completely avoided, because another receiver may have requested the same sequence number from another stream. Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions.
ただし、セッションの2つの異なる元のストリームに同じパケットシーケンス番号に対して2つの未解決のリクエストがある場合、このメカニズムは失敗する可能性があります。最初のパケットシーケンス番号はランダムであるため、同じパケットシーケンス番号に対して2つの未解決のリクエストを持つ確率は非常に少ないことに注意してください。それにもかかわらず、ユニキャストの場合の曖昧さを避けるために、レシーバーは、関連が解決される前に、2つの異なる元のストリームで同じパケットシーケンス番号の2つの未解決の要求を持っている必要がありません。マルチキャストでは、別のレシーバーが別のストリームから同じシーケンス番号を要求した可能性があるため、このあいまいさを完全に回避することはできません。したがって、SSRCマルチプレックスは、マルチキャストセッションで使用してはなりません。
If the receiver discovers that two senders are using the same SSRC or if it receives an RTCP BYE packet, it MUST stop requesting retransmissions for that SSRC. Upon reception of original RTP packets with a new SSRC, the receiver MUST perform the SSRC association again as described in this section.
受信者が2人の送信者が同じSSRCを使用していることを発見した場合、またはRTCP Byeパケットを受信した場合、そのSSRCの再送信の要求を停止する必要があります。新しいSSRCを備えた元のRTPパケットを受信すると、受信者はこのセクションで説明されているようにSSRCアソシエーションを再度実行する必要があります。
This section gives general hints for the usage of this payload format with the extended RTP profile for RTCP-based feedback, denoted AVPF [1]. Note that the general RTCP send and receive rules and the RTCP packet format as specified in RTP apply, except for the changes that the AVPF profile introduces. In short, the AVPF profile relaxes the RTCP timing rules and specifies additional general-purpose RTCP feedback messages. See [1] for details.
このセクションでは、このペイロード形式の使用に関する一般的なヒントで、RTCPベースのフィードバックの拡張RTPプロファイルを使用して、AVPF [1]を示します。一般的なRTCPは、AVPFプロファイルが導入する変更を除き、RTPで指定されているルールとRTCPパケット形式を送信および受信します。要するに、AVPFプロファイルはRTCPタイミングルールをリラックスし、追加の汎用RTCPフィードバックメッセージを指定します。詳細については、[1]を参照してください。
In the case of session-multiplexing, Sender Report (SR) packets for the original stream are sent in the original session and SR packets for the retransmission stream are sent in the retransmission session according to the rules of RTP.
セッションマルチプレックスの場合、元のストリームの送信者レポート（SR）パケットは元のセッションで送信され、再送信ストリームのSRパケットはRTPのルールに従って再送信セッションで送信されます。
In the case of SSRC-multiplexing, SR packets for both original and retransmission streams are sent in the same session according to the rules of RTP. The original and retransmission streams are seen, as far as the RTCP bandwidth calculation is concerned, as independent senders belonging to the same RTP session and are thus equally sharing the RTCP bandwidth assigned to senders.
SSRCマルチプレックスの場合、元のストリームと再送信ストリームの両方のSRパケットは、RTPのルールに従って同じセッションで送信されます。RTCP帯域幅計算に関する限り、同じRTPセッションに属する独立した送信者であるため、送信者に割り当てられたRTCP帯域幅を等しく共有しているため、元の再送信ストリームが見られます。
Note that in both cases, session- and SSRC-multiplexing, BYE packets MUST still be sent for both streams as specified in RTP. In other words, it is not enough to send BYE packets for the original stream only.
どちらの場合も、セッションとSSRCマルチプレックスの両方で、RTPで指定されているように、両方のストリームに対してさようならパケットを送信する必要があることに注意してください。言い換えれば、元のストリームのみにさようならパケットを送信するだけでは不十分です。
In the case of session-multiplexing, the receiver will send report blocks for the original stream and the retransmission stream in separate Receiver Report (RR) packets belonging to separate RTP sessions. RR packets reporting on the original stream are sent in the original RTP session while RR packets reporting on the retransmission stream are sent in the retransmission session. The RTCP bandwidth for these two sessions may be chosen independently (e.g., through RTCP bandwidth modifiers [4]).
セッションマルチプレックスの場合、レシーバーは、個別のRTPセッションに属する個別のレシーバーレポート（RR）パケットで、元のストリームと再送信ストリームのレポートブロックを送信します。元のストリームでレポートされるRRパケットは、元のRTPセッションで送信され、再送信ストリームのRRパケットが再送信セッションで送信されます。これら2つのセッションのRTCP帯域幅は、独立して選択できます（たとえば、RTCP帯域幅修飾子[4]）。
In the case of SSRC-multiplexing, the receiver sends report blocks for the original and the retransmission streams in the same RR packet since there is a single session.
SSRCマルチプレックスの場合、レシーバーは、単一のセッションがあるため、同じRRパケットの元のパケットと再送信ストリームのレポートブロックを送信します。
The NACK feedback message format defined in the AVPF profile SHOULD be used by receivers to send retransmission requests. Whether or not a receiver chooses to request a packet is an implementation issue. An actual receiver implementation should take into account such factors as the tolerable application delay, the network environment, and the media type.
AVPFプロファイルで定義されているNACKフィードバックメッセージ形式は、再送信リクエストを送信するために受信機が使用する必要があります。受信者がパケットを要求することを選択するかどうかは、実装の問題です。実際のレシーバーの実装では、許容可能なアプリケーションの遅延、ネットワーク環境、メディアタイプなどの要因を考慮する必要があります。
The receiver should generally assess whether the retransmitted packet would still be useful at the time it is received. The timestamp of the missing packet can be estimated from the timestamps of packets preceding and/or following the sequence number gap caused by the missing packet in the original stream. In most cases, some form of linear estimate of the timestamp is good enough.
受信者は、一般に、再送信されたパケットが受信時に依然として役立つかどうかを評価する必要があります。欠落しているパケットのタイムスタンプは、元のストリームの欠落パケットによって引き起こされるシーケンス数ギャップの前後のパケットのタイムスタンプから推定できます。ほとんどの場合、タイムスタンプの何らかの形の線形推定で十分です。
Furthermore, a receiver should compute an estimate of the round-trip time (RTT) to the sender. This can be done, for example, by measuring the retransmission delay to receive a retransmission packet after a NACK has been sent for that packet. This estimate may also be obtained from past observations, RTCP report round-trip time if available, or any other means. A standard mechanism for the receiver to estimate the RTT is specified in "RTP Control Protocol Extended Reports (RTCP XR)" [11].
さらに、受信者は、往復時間（RTT）の推定値を送信者に計算する必要があります。これは、たとえば、再送信遅延を測定して、そのパケットにNACKが送信された後に再送信パケットを受信することで実行できます。この推定値は、過去の観測、RTCPレポートの往復時間、利用可能な場合、またはその他の手段からも取得できます。RTTを推定するレシーバーの標準メカニズムは、「RTP制御プロトコル拡張レポート（RTCP XR）」で指定されています[11]。
The receiver should not send a retransmission request as soon as it detects a missing sequence number but should add some extra delay to compensate for packet reordering. This extra delay may, for example, be based on past observations of the experienced packet reordering. It should be noted that, in environments where packet reordering is rare or does not take place, e.g., if the underlying datalink layer affords ordered delivery, the delay may be extremely low or even take the value zero. In such cases, an appropriate "reorder delay" algorithm may not actually be timer based, but packet based. For example, if n number of packets are received after a gap is detected, then it may be assumed that the packet was truly lost rather than out of order. This may turn out to be far easier to code on some platforms as a very short fixed FIFO packet buffer as opposed to the timer-based mechanism.
レシーバーは、欠落しているシーケンス番号を検出したらすぐに再送信リクエストを送信しないでください。たとえば、この余分な遅延は、経験豊富なパケットの並べ替えの過去の観察に基づいている場合があります。パケットの並べ替えがまれであるか、起こらない環境では、たとえば、基礎となるDatalinkレイヤーが順序付けられた配達を提供する場合、遅延が非常に低いか、値がゼロになる場合があることに注意してください。そのような場合、適切な「再注文遅延」アルゴリズムは、実際にはタイマーベースではなく、パケットベースである可能性があります。たとえば、ギャップが検出された後にnのパケット数が受信された場合、パケットが故障ではなく本当に失われたと想定される場合があります。これは、タイマーベースのメカニズムとは対照的に、非常に短い固定FIFOパケットバッファーとして一部のプラットフォームでコーディングするのがはるかに簡単であることが判明する場合があります。
To increase the robustness to the loss of a NACK or of a retransmission packet, a receiver may send a new NACK for the same packet. This is referred to as multiple retransmissions. Before sending a new NACK for a missing packet, the receiver should rely on a timer to be reasonably sure that the previous retransmission attempt has failed and so avoid unnecessary retransmissions. The timer value shall be based on the observed round-trip time. A static or an adaptive value MAY be used. For example, an adaptive timer could be one that changes its value with every new request for the same packet. This document does not provide any guidelines as to how this adaptive value should be calculated because no experiments have been done to find this out.
NACKまたは再送信パケットの損失に対する堅牢性を高めるために、受信者は同じパケットの新しいNACKを送信する場合があります。これは複数の再送信と呼ばれます。不足しているパケットのために新しいNACKを送信する前に、受信者は以前の再送信の試みが失敗したことを合理的に確実に確実にするためにタイマーに依存する必要があります。タイマーの値は、観測された往復時間に基づいています。静的値または適応値を使用できます。たとえば、適応型タイマーは、同じパケットの新しいリクエストごとに値を変更するものである可能性があります。このドキュメントでは、これを見つけるための実験が行われていないため、この適応値をどのように計算すべきかに関するガイドラインは提供していません。
NACKs MUST be sent only for the original RTP stream. Otherwise, if a receiver wanted to perform multiple retransmissions by sending a NACK in the retransmission stream, it would not be able to know the original sequence number and a timestamp estimation of the packet it requests.
NACKは、元のRTPストリームに対してのみ送信する必要があります。それ以外の場合、受信者が再送信ストリームにNACKを送信して複数の再送信を実行したい場合、元のシーケンス番号と要求するパケットのタイムスタンプの推定を知ることができません。
Appendix A gives some guidelines as to how to control the number of retransmissions.
付録Aは、再送信の数を制御する方法に関するいくつかのガイドラインを示しています。
The NACK feedback message may be sent in a regular full compound RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK in an early packet allows reacting more quickly to a given packet loss. However, in that case if a new packet loss occurs right after the early RTCP packet was sent, the receiver will then have to wait for the next regular RTCP compound packet after the early packet. Sending NACKs only in regular RTCP compound decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. Implementers should consider the possible implications of this fact for the application being used.
NACKフィードバックメッセージは、AVPF [1]に従って、通常の完全な複合RTCPパケットまたは初期のRTCPパケットで送信される場合があります。初期のパケットでNACKを送信すると、特定のパケット損失にもっと迅速に反応することができます。ただし、その場合、初期のRTCPパケットが送信された直後に新しいパケット損失が発生した場合、受信者は初期パケットの後に次の通常のRTCP化合物パケットを待つ必要があります。通常のRTCP化合物でのみNACKを送信すると、元のパケット損失を検出してからそのパケットのNACKを送信できる最大遅延が減少します。実装者は、使用されているアプリケーションに対するこの事実の可能な意味を考慮する必要があります。
Furthermore, receivers may make use of the minimum interval between regular RTCP compound packets. This interval can be used to keep regular receiver reporting down to a minimum, while still allowing receivers to send early RTCP packets during periods requiring more frequent feedback, e.g., times of higher packet loss rate. Note that although RTCP packets may be suppressed because they do not contain NACKs, the same RTCP bandwidth as if they were sent needs to be available. See AVPF [1] for details on the use of the minimum interval.
さらに、レシーバーは、通常のRTCP化合物パケット間の最小間隔を使用する場合があります。この間隔を使用して、通常のレシーバーのレポートを最小限に抑えながら、より頻繁にフィードバックを必要とする期間中にレシーバーが早期のRTCPパケットを送信できるようにすることができます。たとえば、パケット損失率が高い時間です。RTCPパケットはNACKを含んでいないため抑制される場合がありますが、送信されたかのように同じRTCP帯域幅が利用可能である必要があることに注意してください。最小間隔の使用に関する詳細については、AVPF [1]を参照してください。
RTP retransmission poses a risk of increasing network congestion. In a best-effort environment, packet loss is caused by congestion. Reacting to loss by retransmission of older data without decreasing the rate of the original stream would thus further increase congestion. Implementations SHOULD follow the recommendations below in order to use retransmission.
RTPの再送信は、ネットワークの混雑を増加させるリスクをもたらします。最良の環境では、パケットの損失は混雑によって引き起こされます。元のストリームの速度を減らすことなく、古いデータの再送信による損失に反応すると、混雑がさらに増加するでしょう。実装は、再送信を使用するために、以下の推奨事項に従う必要があります。
The RTP profile under which the retransmission scheme is used defines an appropriate congestion control mechanism in different environments. Following the rules under the profile, an RTP application can determine its acceptable bitrate and packet rate in order to be fair to other TCP or RTP flows.
再送信スキームが使用されるRTPプロファイルは、さまざまな環境で適切な輻輳制御メカニズムを定義します。プロファイルの下のルールに従って、RTPアプリケーションは、他のTCPまたはRTPフローに公平になるために、許容可能なビットレートとパケットレートを決定できます。
If an RTP application uses retransmission, the acceptable packet rate and bitrate include both the original and retransmitted data. This guarantees that an application using retransmission achieves the same fairness as one that does not. Such a rule would translate in practice into the following actions:
RTPアプリケーションが再送信を使用する場合、許容可能なパケットレートとビットレートには、元のデータと再送信されたデータの両方が含まれます。これにより、再送信を使用したアプリケーションが、そうでないものと同じ公平性を達成することが保証されます。このようなルールは、実際には次のアクションに変換されます。
If enhanced service is used, it should be made sure that the total bitrate and packet rate do not exceed that of the requested service. It should be further monitored that the requested services are actually delivered. In a best-effort environment, the sender SHOULD NOT send retransmission packets without reducing the packet rate and bitrate of the original stream (for example, by encoding the data at a lower rate).
強化されたサービスが使用されている場合、総ビットレートとパケットレートが要求されたサービスのそれを超えないようにする必要があります。要求されたサービスが実際に配信されることをさらに監視する必要があります。最良の環境では、送信者は、元のストリームのパケットレートとビットレートを減らすことなく、再送信パケットを送信しないでください（たとえば、データをより低いレートでエンコードして）。
In addition, the sender MAY selectively retransmit only the packets that it deems important and ignore NACK messages for other packets in order to limit the bitrate.
さらに、送信者は、ビットレートを制限するために、重要と思われるパケットのみを選択的に再送信し、他のパケットのNACKメッセージを無視することができます。
These congestion control mechanisms should keep the packet loss rate within acceptable parameters. In the context of congestion control, packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve, on a reasonable timescale, an average throughput that is not less than the one the RTP flow achieves. If congestion is not kept under control, then retransmission SHOULD NOT be used.
これらの混雑制御メカニズムは、パケット損失率を許容可能なパラメーター内に保つ必要があります。輻輳制御のコンテキストでは、同じネットワークパスを超えてTCPフローが同じネットワーク条件を経験すると、合理的なタイムスケールで、RTPフローが達成する平均スループットを達成する場合、パケット損失は許容できると見なされます。混雑が制御されていない場合、再送信を使用しないでください。
Retransmissions MAY still be sent in some cases, e.g., in wireless links where packet losses are not caused by congestion, if the server (or the client that makes the retransmission request) estimates that a particular packet or frame is important to continue play out, or if an RTSP PAUSE has been issued to allow the buffer to fill up (RTSP PAUSE does not affect the sending of retransmissions).
再送信は、場合によっては、たとえば、パケットの損失が輻輳によって引き起こされないワイヤレスリンクで、場合、サーバー（または再送信リクエストを行うクライアント）が特定のパケットまたはフレームがプレイし続けるために重要であると推定している場合、ワイヤレスリンクでまだ送信される場合があります。または、バッファーが満たされるようにRTSPの一時停止が発行された場合（RTSPの一時停止は再送信の送信に影響しません）。
Finally, it may further be necessary to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or to arrange for the receiver to leave the session.
最後に、送信速度（またはレイヤードマルチキャストセッションにサブスクライブするレイヤー数）を適応させるか、受信者がセッションを離れるよう手配する必要がある場合があります。
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt".
次のMIMEサブタイプ名とパラメーターは、このドキュメントで紹介されています：「RTX」、「RTX-Time」、および「APT」。
The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx".
ペイロードタイプ番号への再送信ストリームに使用されるバインディングは、RTPMAP属性によって示されます。バインディングで使用されるMIMEサブタイプ名は「RTX」です。
The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
「APT」（関連するペイロードタイプ）パラメーターを使用して、再送信ペイロードタイプを関連する元のストリームペイロードタイプにマッピングする必要があります。複数の元のペイロードタイプを使用する場合、各元のペイロードタイプを別の再送信ペイロードタイプにマッピングするには、複数の「APT」パラメーターを含める必要があります。
An OPTIONAL payload-format-specific parameter, "rtx-time", indicates the maximum time a sender will keep an original RTP packet in its buffers available for retransmission. This time starts with the first transmission of the packet.
オプションのペイロード形式固有のパラメーター「RTX-Time」は、送信者がバッファに元のRTPパケットを再送信に使用できる最大時間を示します。今回は、パケットの最初の送信から始まります。
The syntax is as follows:
構文は次のとおりです。
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
where
ただし
<number>: indicates the dynamic payload type number assigned to the retransmission payload format in an rtpmap attribute.
<number>：RTPMAP属性の再送信ペイロード形式に割り当てられた動的なペイロードタイプ番号を示します。
<apt-value>: is the value of the original stream payload type to which this retransmission stream payload type is associated.
<apt-value>：この再送信ストリームペイロードタイプが関連付けられている元のストリームペイロードタイプの値です。
<rtx-time-val>: specifies the time in milliseconds (measured from the time a packet was first sent) that a sender keeps an RTP packet in its buffers available for retransmission. The absence of the rtx-time parameter for a retransmission stream means that the maximum retransmission time is not defined, but MAY be negotiated by other means.
<rtx-time-val>：送信者が再送信に利用できるバッファーにRTPパケットを保持するミリ秒（パケットが最初に送信された時から測定）で時間を指定します。再送信ストリームにRTX-Timeパラメーターがないことは、最大再送信時間が定義されていないが、他の手段によって交渉される可能性があることを意味します。
MIME type: audio
MIMEタイプ：オーディオ
MIME subtype: rtx
MIMEサブタイプ：RTX
Required parameters:
必要なパラメーター：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
レート：RTPタイムスタンプクロックレートは、再送信されたメディアのRTPタイムスタンプクロックレートに等しくなります。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
APT：関連するペイロードタイプ。このパラメーターの値は、関連する元のストリームのペイロードタイプです。
Optional parameters:
オプションのパラメーター：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
RTX-Time：ミリ秒単位（パケットが最初に送信された時間から測定された）を示します。
Encoding considerations: this type is only defined for transfer via RTP.
考慮事項のエンコード：このタイプは、RTPを介した転送のみで定義されます。
Security considerations: see Section 12 of RFC 4588
セキュリティ上の考慮事項：RFC 4588のセクション12を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4588
公開された仕様：RFC 4588
Applications which use this media type: multimedia streaming applications
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングアプリケーション
Additional information: none
追加情報：なし
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
詳細については、連絡先の人とメールアドレス：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図された使用法：共通
Authors: Jose Rey David Leon
著者：ホセ・レイ・デイビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
MIME type: video
MIMEタイプ：ビデオ
MIME subtype: rtx
MIMEサブタイプ：RTX
Required parameters:
必要なパラメーター：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
レート：RTPタイムスタンプクロックレートは、再送信されたメディアのRTPタイムスタンプクロックレートに等しくなります。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
APT：関連するペイロードタイプ。このパラメーターの値は、関連する元のストリームのペイロードタイプです。
Optional parameters:
オプションのパラメーター：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
RTX-Time：ミリ秒単位（パケットが最初に送信された時間から測定された）を示します。
Encoding considerations: this type is only defined for transfer via RTP.
考慮事項のエンコード：このタイプは、RTPを介した転送のみで定義されます。
Security considerations: see Section 12 of RFC 4588
セキュリティ上の考慮事項：RFC 4588のセクション12を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4588
公開された仕様：RFC 4588
Applications which use this media type: multimedia streaming applications
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングアプリケーション
Additional information: none
追加情報：なし
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
詳細については、連絡先の人とメールアドレス：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図された使用法：共通
Authors: Jose Rey David Leon
著者：ホセ・レイ・デイビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
MIME type: text
MIMEタイプ：テキスト
MIME subtype: rtx
MIMEサブタイプ：RTX
Required parameters:
必要なパラメーター：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
レート：RTPタイムスタンプクロックレートは、再送信されたメディアのRTPタイムスタンプクロックレートに等しくなります。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
APT：関連するペイロードタイプ。このパラメーターの値は、関連する元のストリームのペイロードタイプです。
Optional parameters:
オプションのパラメーター：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
RTX-Time：ミリ秒単位（パケットが最初に送信された時間から測定された）を示します。
Encoding considerations: this type is only defined for transfer via RTP.
考慮事項のエンコード：このタイプは、RTPを介した転送のみで定義されます。
Security considerations: see Section 12 of RFC 4588
セキュリティ上の考慮事項：RFC 4588のセクション12を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4588
公開された仕様：RFC 4588
Applications which use this media type: multimedia streaming applications
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングアプリケーション
Additional information: none
追加情報：なし
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
詳細については、連絡先の人とメールアドレス：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図された使用法：共通
Authors: Jose Rey David Leon
著者：ホセ・レイ・デイビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
MIME type: application
MIMEタイプ：アプリケーション
MIME subtype: rtx
MIMEサブタイプ：RTX
Required parameters:
必要なパラメーター：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
レート：RTPタイムスタンプクロックレートは、再送信されたメディアのRTPタイムスタンプクロックレートに等しくなります。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
APT：関連するペイロードタイプ。このパラメーターの値は、関連する元のストリームのペイロードタイプです。
Optional parameters:
オプションのパラメーター：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
RTX-Time：ミリ秒単位（パケットが最初に送信された時間から測定された）を示します。
Encoding considerations: this type is only defined for transfer via RTP.
考慮事項のエンコード：このタイプは、RTPを介した転送のみで定義されます。
Security considerations: see Section 12 of RFC 4588
セキュリティ上の考慮事項：RFC 4588のセクション12を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4588
公開された仕様：RFC 4588
Applications which use this media type: multimedia streaming applications
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングアプリケーション
Additional information: none
追加情報：なし
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
詳細については、連絡先の人とメールアドレス：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図された使用法：共通
Authors: Jose Rey David Leon
著者：ホセ・レイ・デイビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
The information carried in the MIME media type specification has a specific mapping to fields in SDP [5], which is commonly used to describe RTP sessions. When SDP is used to specify retransmissions for an RTP stream, the mapping is done as follows:
MIMEメディアタイプの仕様にある情報には、SDP [5]のフィールドへの特定のマッピングがあり、これは一般にRTPセッションを説明するために使用されます。SDPを使用してRTPストリームの再送信を指定する場合、マッピングは次のように行われます。
- The MIME types ("video"), ("audio"), ("text"), and ("application") go in the SDP "m=" as the media name.
- mime型（ "ビデオ"）、（ "audio"）、（ "text"）、および（ "application"）は、メディア名としてsdp "m ="に移動します。
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding name. The RTP clockrate in "a=rtpmap" MUST be that of the retransmission payload type. See Section 4 for details on this.
- MIMEサブタイプ（ "rtx"）は、sdp "a = rtpmap"にエンコード名として掲載されます。「a = rtpmap」のRTPクロックレートは、再送信ペイロードタイプのそれでなければなりません。詳細については、セクション4を参照してください。
- The AVPF profile-specific parameters "ack" and "nack" go in SDP "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of feedback. See the AVPF profile [1] for details.
- AVPFプロファイル固有のパラメーター「ACK」と「NACK」はSDP "A = RTCP-FB"に移動します。いくつかのSDP「A = RTCP-FB」は、いくつかのタイプのフィードバックに使用されます。詳細については、AVPFプロファイル[1]を参照してください。
- The retransmission payload-format-specific parameters "apt" and "rtx-time" go in the SDP "a=fmtp" as a semicolon-separated list of parameter=value pairs.
- 再送信ペイロードファーマット固有のパラメーター「APT」および「RTX-TIME」は、SDP「A = FMTP」にGO IN THE SDP "A = FMTP"をパラメーター=値ペアのセミコロン分離リストとして獲得します。
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 残りのパラメーターは、MIMEメディアタイプの文字列から直接コピーすることにより、SDP "a = fmtp"属性に搭載されています。
In the following sections, some example SDP descriptions are presented. In some of these examples, long lines are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored.
次のセクションでは、SDPの説明の例を示します。これらの例のいくつかでは、このドキュメントの列幅の制約を満たすために長い線が折りたたまれています。行の終わりにあるバックスラッシュ（ "\"）とその後のキャリッジは無視する必要があります。
In the case of session-multiplexing, the SDP description contains one media specification "m" line per RTP session. The SDP MUST provide the grouping of the original and associated retransmission sessions' "m" lines, using the Flow Identification (FID) semantics defined in RFC 3388 [6].
セッションマルチプレックスの場合、SDP説明には、RTPセッションごとに1つのメディア仕様「M」行が含まれています。SDPは、RFC 3388 [6]で定義されたフロー識別（FID）セマンティクスを使用して、元の再送信セッション「M」ラインのグループ化を提供する必要があります。
The following example specifies two original, AMR and MPEG-4, streams on ports 49170 and 49174 and their corresponding retransmission streams on ports 49172 and 49176, respectively:
次の例では、2つのオリジナル、AMRとMPEG-4、ポート49170および49174のストリームと、それぞれポート49172および49176での対応する再送信ストリームを指定します。
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only.
SDP説明の特別なケースは、1つの元のセッション「M」行と1つの再送信セッション「M」行のみを含む説明です。その後、グループ化は明白であり、FIDセマンティクスはこの特別なケースでのみ省略できます。
This is illustrated in the following example, which is an SDP description for a single original MPEG-4 stream and its corresponding retransmission session:
これは、次の例に示されています。これは、単一の元のMPEG-4ストリームとその対応する再送信セッションのSDP説明です。
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The following is an example of an SDP description for an RTP video
session using SSRC-multiplexing with similar parameters as in the
single-session example above:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The Real Time Streaming Protocol (RTSP), RFC 2326 [7], is an application-level protocol for control over the delivery of data with real-time properties. This section looks at the issues involved in controlling RTP sessions that use retransmissions.
リアルタイムストリーミングプロトコル（RTSP）、RFC 2326 [7]は、リアルタイムプロパティを使用したデータの提供を制御するためのアプリケーションレベルのプロトコルです。このセクションでは、再送信を使用するRTPセッションの制御に伴う問題について説明します。
In the case of SSRC-multiplexing, the "m" line includes both original and retransmission payload types and has a single RTSP "control" attribute. The receiver uses the "m" line to request SETUP and TEARDOWN of the whole media session. The RTP profile contained in the Transport header MUST be the AVPF profile or another suitable profile allowing extended feedback. If the SSRC value is included in the SETUP response's Transport header, it MUST be that of the original stream.
SSRCマルチプレックスの場合、「M」ラインにはオリジナルと再送信の両方のペイロードタイプが含まれており、単一のRTSP「コントロール」属性があります。受信者は、「M」行を使用して、メディアセッション全体のセットアップと分解を要求します。トランスポートヘッダーに含まれるRTPプロファイルは、AVPFプロファイルまたは拡張フィードバックを可能にする別の適切なプロファイルでなければなりません。SSRC値がセットアップ応答のトランスポートヘッダーに含まれている場合、それは元のストリームのものでなければなりません。
In order to control the sending of the session original media stream, the receiver sends as usual PLAY and PAUSE requests to the sender for the session. The RTP-info header that is used to set RTP-specific parameters in the PLAY response MUST be set according to the RTP information of the original stream.
セッションのオリジナルメディアストリームの送信を制御するために、受信者はいつものように送信し、セッションの送信者にリクエストを一時停止します。PLAY応答でRTP固有のパラメーターを設定するために使用されるRTP-INFOヘッダーは、元のストリームのRTP情報に従って設定する必要があります。
When the receiver starts receiving the original stream, it can then request retransmission through RTCP NACKs without additional RTSP signalling.
レシーバーが元のストリームの受信を開始すると、追加のRTSPシグナリングなしでRTCP NACKを介して再送信を要求できます。
In the case of session-multiplexing, each SDP "m" line has an RTSP "control" attribute. Hence, when retransmission is used, both the original session and the retransmission have their own "control" attributes. The receiver can associate the original session and the retransmission session through the FID semantics as specified in Section 8.
セッションマルチプレックスの場合、各SDP「M」ラインにはRTSP「コントロール」属性があります。したがって、再送信が使用される場合、元のセッションと再送信の両方に独自の「制御」属性があります。受信者は、セクション8で指定されているように、FIDセマンティクスを通じて元のセッションと再送信セッションを関連付けることができます。
The original and the retransmission streams are set up and torn down separately through their respective media "control" attribute. The RTP profile contained in the Transport header MUST be the AVPF profile or another suitable profile allowing extended feedback for both the original and the retransmission sessions.
オリジナルと再送信のストリームは、それぞれのメディアの「制御」属性を介して個別にセットアップされ、引き裂かれます。トランスポートヘッダーに含まれるRTPプロファイルは、AVPFプロファイルまたは別の適切なプロファイルである必要があり、元のセッションと再送信セッションの両方に拡張フィードバックを可能にします。
The RTSP presentation SHOULD support aggregate control and SHOULD contain a session-level RTSP URL. The receiver SHOULD use aggregate control for an original session and its associated retransmission session. Otherwise, there would need to be two different 'session-id' values, i.e., different values for the original and retransmission sessions, and the sender would not know how to associate them.
RTSPプレゼンテーションには、集計制御をサポートし、セッションレベルのRTSP URLを含める必要があります。受信者は、元のセッションとそれに関連する再送信セッションに集約制御を使用する必要があります。それ以外の場合、2つの異なる「セッションID」値、つまり元の再送信セッションの異なる値が必要であり、送信者はそれらを関連付ける方法を知りません。
The session-level "control" attribute is then used as usual to control the playing of the original stream. When the receiver starts receiving the original stream, it can then request retransmissions through RTCP without additional RTSP signalling.
次に、セッションレベルの「コントロール」属性を通常どおり使用して、元のストリームの再生を制御します。レシーバーが元のストリームの受信を開始すると、追加のRTSPシグナリングなしでRTCPを介して再送信を要求できます。
Because of the nature of retransmissions, the sending of retransmission packets SHOULD NOT be controlled through RTSP PLAY and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect the retransmission stream. Retransmission packets are sent upon receiver requests in the original RTCP stream, regardless of the state.
再送信の性質上、再送信パケットの送信は、RTSPプレイと一時停止のリクエストを通じて制御されるべきではありません。プレイと一時停止のリクエストは、再送信ストリームに影響しないはずです。再送信パケットは、状態に関係なく、元のRTCPストリームの受信者リクエストに応じて送信されます。
Retransmission streams SHOULD NOT be cached.
再送信ストリームをキャッシュしてはなりません。
In the case of session-multiplexing, the "Cache-Control" header SHOULD be set to "no-cache" for the retransmission stream.
セッションマルチプレックスの場合、再送信ストリームの「キャッシュコントロール」ヘッダーを「ノーキャッシュ」に設定する必要があります。
In the case of SSRC-multiplexing, RTSP cannot specify independent caching for the retransmission stream, because there is a single "m" line in SDP. Therefore, the implementer should take this fact into account when deciding whether or not to cache an SSRC-multiplexed session.
SSRCマルチプレックスの場合、RTSPは、SDPに単一の「M」ラインがあるため、再送信ストリームの独立したキャッシュを指定できません。したがって、実装者は、SSRCマルチプレックスセッションをキャッシュするかどうかを決定する際に、この事実を考慮する必要があります。
This document mandates only the sender and receiver behaviours that are necessary for interoperability. In addition, certain algorithms, such as rate control or buffer management when targeted at specific environments, may enhance the retransmission efficiency.
このドキュメントは、相互運用性に必要な送信者と受信者の動作のみを義務付けています。さらに、特定の環境をターゲットにした場合のレート制御やバッファ管理などの特定のアルゴリズムは、再送信効率を高める可能性があります。
This section gives an overview of different implementation options allowed within this specification.
このセクションでは、この仕様内で許可されているさまざまな実装オプションの概要を説明します。
The first example describes a minimal receiver implementation. With this implementation, it is possible to retransmit lost RTP packets, detect efficiently the loss of retransmissions, and perform multiple retransmissions, if needed. Most of the necessary processing is done at the server.
最初の例では、最小限の受信機の実装について説明します。この実装により、失われたRTPパケットを再送信し、必要に応じて再送信の損失を効率的に検出し、複数の再送信を実行することができます。必要な処理のほとんどはサーバーで行われます。
The second example shows how retransmissions may be used in (small) multicast groups in conjunction with layered encoding. It illustrates that retransmissions and layered encoding may be complementary techniques.
2番目の例は、レイヤードエンコードと組み合わせて（小さな）マルチキャストグループで再送信をどのように使用するかを示しています。再送信と層状エンコードが補完的な手法である可能性があることを示しています。
This section gives an example of an implementation supporting multiple retransmissions. The sender transmits the original data in RTP packets using the MPEG-4 video RTP payload format. It is assumed that NACK feedback messages are used, as per [1]. An SDP description example with SSRC-multiplexing is given below:
このセクションでは、複数の再送信をサポートする実装の例を示します。送信者は、MPEG-4ビデオRTPペイロード形式を使用して、RTPパケットの元のデータを送信します。[1]に従って、NACKフィードバックメッセージが使用されると想定されています。SSRC-Multiplexingを使用したSDP説明の例を以下に示します。
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The format-specific parameter "rtx-time" indicates that the server will buffer the sent packets in a retransmission buffer for 3.0 seconds, after which the packets are deleted from the retransmission buffer and will never be sent again.
フォーマット固有のパラメーター「RTX-Time」は、サーバーが送信されたパケットを再送信バッファーに3.0秒間バッファリングすることを示し、その後、パケットが再送信バッファーから削除され、二度と送信されることはありません。
In this implementation example, the required RTP receiver processing to handle retransmission is kept to a minimum. The receiver detects packet loss from the gaps observed in the received sequence numbers. It signals lost packets to the sender through NACKs as defined in the AVPF profile [1]. The receiver should take into account the signalled sender retransmission buffer length in order to dimension its own reception buffer. It should also derive from the buffer length the maximum number of times the retransmission of a packet can be requested.
この実装の例では、再送信を処理するために必要なRTPレシーバー処理が最小限に抑えられます。受信機は、受信したシーケンス番号で観察されたギャップからのパケットの損失を検出します。AVPFプロファイル[1]で定義されているように、NACKSを介して送信者に失われたパケットを信号します。受信者は、独自の受信バッファーを寸法するために、信号送信者再送信バッファーの長さを考慮する必要があります。また、バッファーの長さから派生し、パケットの再送信が要求できる最大回数を導出する必要があります。
The sender should retransmit the packets selectively; i.e., it should choose whether to retransmit a requested packet depending on the packet importance, the observed Quality of Service (QoS), and congestion state of the network connection to the receiver. Obviously, the sender processing increases with the number of receivers as state information and processing load must be allocated to each receiver.
送信者は、パケットを選択的に再送信する必要があります。つまり、パケットの重要性、観測されたサービス品質（QoS）、およびレシーバーへのネットワーク接続の渋滞状態に応じて、要求されたパケットを再送信するかどうかを選択する必要があります。明らかに、州の情報と処理負荷を各受信者に割り当てる必要があるため、送信者の処理は受信機の数とともに増加します。
This section shows how to combine retransmissions with layered encoding in multicast sessions. Note that the retransmission framework is offered only for small multicast applications. Refer to RFC 2887 [10] for a discussion of the problems of NACK implosion, severe congestion caused by feedback traffic, in large-group reliable multicast applications.
このセクションでは、再送信をマルチキャストセッションで層状エンコードと組み合わせる方法を示します。再送信フレームワークは、小規模なマルチキャストアプリケーションにのみ提供されることに注意してください。NACKの爆発の問題、フィードバックトラフィックによる重大なうっ血、大規模なグループの信頼性の高いマルチキャストアプリケーションの議論については、RFC 2887 [10]を参照してください。
Packets of different importance are sent in different RTP sessions. The retransmission streams corresponding to the different layers can themselves be seen as different retransmission layers. The relative importance of the different retransmission streams should reflect the relative importance of the different original streams.
異なる重要なパケットは、異なるRTPセッションで送信されます。異なるレイヤーに対応する再送信ストリーム自体は、異なる再送信層と見なすことができます。異なる再送信ストリームの相対的な重要性は、異なる元のストリームの相対的な重要性を反映する必要があります。
In multicast, SSRC-multiplexing of the original and retransmission streams is not allowed as per Section 5.3 of this document. For this reason, the retransmission stream(s) MUST be sent in different RTP session(s) using session-multiplexing.
マルチキャストでは、このドキュメントのセクション5.3に従って、元のストリームと再送信ストリームのSSRCマルチプレックスは許可されていません。このため、再送信ストリームは、セッションマルチプレックスを使用して異なるRTPセッションで送信する必要があります。
An SDP description example of multicast retransmissions for layered encoded media is given below:
階層化されたエンコードされたメディアのマルチキャスト再送信のSDP説明例を以下に示します。
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
The server and the receiver may implement the retransmission methods illustrated in the previous examples. In addition, they may choose to request and retransmit a lost packet depending on the layer it belongs to.
サーバーとレシーバーは、前の例に示されている再送信方法を実装できます。さらに、属するレイヤーに応じて、失われたパケットを要求して再送信することを選択できます。
A new MIME subtype name, "rtx", has been registered for four different media types, as follows: "video", "audio", "text" and "application". An additional REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", are defined. See Section 8 for details.
新しいMIMEサブタイプの名前「RTX」は、次のように、4つの異なるメディアタイプに登録されています：「ビデオ」、「オーディオ」、「テキスト」、「アプリケーション」。追加の必要なパラメーター「APT」、およびオプションのパラメーター「RTX-Time」が定義されています。詳細については、セクション8を参照してください。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3], Section 9.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP [3]、セクション9で説明されている一般的なセキュリティ上の考慮事項の対象となります。
In common streaming scenarios message authentication, data integrity, replay protection, and confidentiality are desired.
一般的なストリーミングシナリオでは、メッセージ認証、データの整合性、リプレイ保護、および機密性が必要です。
The absence of authentication may enable man-in-the-middle and replay attacks, which can be very harmful for RTP retransmission. For example: tampered RTCP packets may trigger inappropriate retransmissions that effectively reduce the actual bitrate share allocated to the original data stream, tampered RTP retransmission packets could cause the client's decoder to crash, and tampered retransmission requests may invalidate the SSRC association mechanism described in Section 5 of this document. On the other hand, replayed packets could lead to false reordering and RTT measurements (required for the retransmission request strategy) and may cause the receiver buffer to overflow.
認証がないことで、中間の攻撃やリプレイ攻撃が可能になる可能性があります。これは、RTPの再送信に非常に有害な場合があります。例：改ざんされたRTCPパケットは、元のデータストリームに割り当てられた実際のビットレート共有を効果的に削減する不適切な再送信をトリガーする可能性があります。RTP再送信パケットは、クライアントのデコーダーをクラッシュさせ、再送信要求を改ざんする可能性があり、セクション5で説明されているSSRC関連の機構を無効にする可能性があります。このドキュメントの。一方、再生されたパケットは、誤った並べ替えとRTT測定（再送信要求戦略に必要）につながり、受信バッファーがオーバーフローする可能性があります。
Furthermore, in order to ensure confidentiality of the data, the original payload data needs to be encrypted. There is actually no need to encrypt the 2-byte retransmission payload header since it does not provide any hints about the data content.
さらに、データの機密性を確保するために、元のペイロードデータを暗号化する必要があります。実際には、データコンテンツに関するヒントを提供しないため、2バイトの再送信ペイロードヘッダーを暗号化する必要はありません。
Furthermore, it is RECOMMENDED that the cryptography mechanisms used for this payload format provide protection against known plaintext attacks. RTP recommends that the initial RTP timestamp SHOULD be random to secure the stream against known plaintext attacks. This payload format does not follow this recommendation as the initial timestamp will be the media timestamp of the first retransmitted packet. However, since the initial timestamp of the original stream is itself random, if the original stream is encrypted, the first retransmitted packet timestamp would also be random to an attacker. Therefore, confidentiality would not be compromised.
さらに、このペイロード形式に使用される暗号化メカニズムは、既知のプレーンテキスト攻撃に対する保護を提供することをお勧めします。RTPは、既知のプレーンテキスト攻撃に対してストリームを保護するために、最初のRTPタイムスタンプをランダムにすることを推奨しています。最初のタイムスタンプは最初の再送信パケットのメディアタイムスタンプになるため、このペイロード形式はこの推奨事項に従いません。ただし、元のストリームの最初のタイムスタンプ自体がランダムであるため、元のストリームが暗号化されている場合、最初の再送信パケットタイムスタンプも攻撃者にとってランダムになります。したがって、機密性は損なわれません。
If cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream. The use of the same key for the retransmitted stream and the original stream may lead to security problems, e.g., two-time pads. Refer to Section 9.1 of the Secure Real-Time Transport Protocol (SRTP) [12] for a discussion the implications of two-time pads and how to avoid them.
暗号化が元のストリームでセキュリティサービスを提供するために使用されている場合、同等の暗号強度を持つ同じサービスを再送信ストリームに提供する必要があります。再送信されたストリームと元のストリームに同じキーを使用すると、2回のパッドなどのセキュリティの問題が発生する可能性があります。2回のパッドの意味とそれらを回避する方法についての議論については、安全なリアルタイム輸送プロトコル（SRTP）[12]のセクション9.1を参照してください。
At the time of writing this document, SRTP does not provide all the security services mentioned. There are, at least, two reasons for this: 1) the occurrence of two-time pads and 2) the fact that this payload format typically works under the RTP/AVPF profile whereas SRTP only supports RTP/AVP. An adapted variant of SRTP shall solve these shortcomings in the future.
このドキュメントを書いている時点で、SRTPは言及されたすべてのセキュリティサービスを提供していません。少なくとも2つの理由があります。1）2回のパッドの発生と2）このペイロード形式は通常、RTP/AVPFプロファイルの下で機能するのに対し、SRTPはRTP/AVPのみをサポートします。SRTPの適応されたバリアントは、将来これらの欠点を解決するものとします。
Congestion control considerations with the use of retransmission are dealt with in Section 7 of this document.
再送信を使用した混雑制御の考慮事項は、このドキュメントのセクション7で対処されています。
We would like to express our gratitude to Carsten Burmeister for his participation in the development of this document. Our thanks also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, Go Hori, and Rahul Agarwal for their helpful comments.
Carsten Burmeisterに、この文書の開発に参加してくれたことに感謝の気持ちを表明したいと思います。また、hata、コリン・パーキンス、スティーブン・カスナー、マグナス・ウェスターランド、ゴー・ホリ、ラーフル・アガルワルの有益なコメントに感謝します。
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP profile for Real-time Transport Control Protocol (RTCP)-Based feedback", RFC 4585, July 2006.
[1] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバックのRTPプロファイルを拡張しました」、RFC 4585、2006年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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[4] Casner、S。、「RTPコントロールプロトコル（RTCP）帯域幅のセッション説明プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[6] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[7] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[8] Perkins、C。and O. Hodson、「ストリーミングメディアの修理のオプション」、RFC 2354、1998年6月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[9] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[10] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[10] Handley、M.、Floyd、S.、Whetten、B.、Kermode、R.、Vicisano、L。、およびM. Luby、「バルクデータ転送用の信頼できるマルチキャスト設計スペース」、RFC 2887、2000年8月。
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[11] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[12] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
Finding out the number of retransmissions (rtxs.) per packet for achieving the best possible transmission is a difficult task. Of course, the absolute minimum should be one (1); otherwise, do not use this payload format. Moreover, as of date of publication, the authors were not aware of any studies on the number of retransmissions per packet that should be used for best performance. To help implementers and researchers on this item, this section describes an estimate of the buffering time required for achieving a given number of retransmissions. Once this time has been calculated, it can be communicated to the client via SDP parameter "rtx-time", as defined in this document.
可能な限り最高の送信を達成するために、パケットごとの再送信の数（RTXS。）を見つけることは難しい作業です。もちろん、絶対最小値は1つでなければなりません。それ以外の場合は、このペイロード形式を使用しないでください。さらに、出版日の時点で、著者は、最高のパフォーマンスに使用する必要があるパケットごとの再送信の数に関する研究を認識していませんでした。この項目の実施者と研究者を支援するために、このセクションでは、特定の数の再送信を達成するために必要なバッファリング時間の推定について説明します。この時間が計算されると、このドキュメントで定義されているように、SDPパラメーター「RTX-Time」を介してクライアントに通信できます。
* Streaming scenario with relaxed delay bounds. Client and server are provided with buffering space as indicated by the parameter "rtx-time" in SDP.
* リラックスした遅延境界を備えたストリーミングシナリオ。クライアントとサーバーには、SDPのパラメーター「RTX-Time」で示されるように、バッファリングスペースが提供されます。
* RTP AVPF profile used with SSRC-multiplexing retransmission scheme: 1 SSRC for original packets, 1 for retransmission packets.
* ssrc-multiplexing再送信スキームで使用されるRTP AVPFプロファイル：1 SSRCオリジナルパケット用、1再送信パケット用に1。
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR = 0.05. We have senders (2) and receivers (1). Receivers and senders get equally 1/3 of the RTCP bandwidth share because the proportion of senders is greater than 1/4 of session members.
* SRSおよびRRSのデフォルトのRTCP帯域幅共有、つまりSR RR = 0.05。送信者（2）とレシーバー（1）があります。受信者と送信者は、送信者の割合がセッションメンバーの1/4を超えるため、RTCP帯域幅の共有の1/3を等しく獲得します。
* avg-rtcp-size is approximated by 120 bytes. This is a rounded-up average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes. Since senders and receivers share the RTCP bandwidth equally, then avg-rtcp-size = (157+105+105)/3 = 117.3 ~= 120 bytes. The important characteristic of this value is that it is something over 100 bytes, which seems to be a representative figure for typical configurations.
* AVG-RTCPサイズは120バイトで近似されています。これは、cnameを使用したIPv6/UDP/SR/SDEの40/8/28/32バイトを含む各SSRCに1つの2つのSRSの丸みを帯びた平均であり、それぞれ105バイトを作成します。IPv6/UDP/2*RR/SDEの40/8/64/32バイトのRR、157バイトを作成します。送信者と受信者はRTCP帯域幅を等しく共有しているため、AVG-RTCP-Size =（157 105 105）/3 = 117.3〜 = 120バイトです。この値の重要な特徴は、それが100バイトを超えるものであり、典型的な構成の代表的な数字であると思われることです。
* The profile used is AVPF [1] and Generic NACKs are used for requesting retransmissions. This adds 16 bytes of overhead for 1 NACK and 4 bytes more for every additional NACK Feedback Control Information (FCI) field.
* 使用されるプロファイルはAVPF [1]であり、一般的なNACKは再送信を要求するために使用されます。これにより、追加のNACKフィードバックコントロール情報（FCI）フィールドごとに16バイトのオーバーヘッドと4バイトのオーバーヘッドが追加されます。
* We assume a worst-case scenario in which each packet exhausts its corresponding number of available retransmissions, N, before it is received. This means that if a packet is requested for retransmission a maximum of 2 times, the corresponding generic NACK report block requesting that particular packet is sent in two consecutive RTCP compounds; likewise, if it is requested for retransmission 10 times, then the generic NACK is sent 10 times. This assumption makes the RTCP packet size approximately constant after N*RTCP intervals (seconds), namely, to avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver RTCP bandwidth share is 1/3; thus, avg-rtcp-size = 124 + 4*N/3.
* 各パケットが受信する前に、利用可能な再送信nの対応する数を排出する最悪のシナリオを想定しています。これは、パケットが最大2回の再送信の要求された場合、対応する汎用NACKレポートブロックが特定のパケットが2つの連続したRTCP化合物で送信されることを要求することを意味します。同様に、再送信が10回要求された場合、一般的なNACKは10回送信されます。この仮定により、rtcpパケットサイズは、n*rtcp間隔（秒）の後にほぼ一定になります。私たちの場合、受信者RTCP帯域幅の共有は1/3です。したがって、avg-rtcp-size = 124 4*n/3。
* Two delay parameters are difficult to approximate and may be implementation dependent. Therefore, we list them here explicitly without assigning them a particular value: one is the packet loss detection time (T2), and the other is feedback processing and queuing time for retransmissions (T5). Implementers shall assign appropriate values to these two parameters.
* 2つの遅延パラメーターを近似することは困難であり、実装に依存する場合があります。したがって、特定の値を割り当てることなく、ここに明示的にリストします。1つはパケット損失検出時間（T2）であり、もう1つはフィードバック処理と再送信（T5）のキューイングです。実装者は、これら2つのパラメーターに適切な値を割り当てるものとします。
Graphically, we have the following:
グラフィーには、次のことがあります。
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Legend:
=======
DL: downlink (client->server)
UL: uplink (server->client)
Time unit is seconds, s.
Bitrate unit is bits per second, bps.
DL transmission time: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Time to detect packet loss: T2 = pkt-loss-detect-time
パケット損失を検出する時間：T2 = PKT-LOSS-DETECT-TIME
Time to report packet loss: T3 = time-to-next-rtcp-report
パケット損失を報告する時間：T3 = next-rtcp-reportまで
UL transmission time: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
Retransmissions processing time: T5 = feedback-processing-time + rtx-queuing-time
再送信処理時間：T5 =フィードバック処理時間rtx-quuing-time
To find an estimate of the buffering time, T(), that a streaming server shall use in order to enable a given number of retransmissions for each packet, N. This time is approximately equal at the server and at the client, if one considers that the client starts buffering T1 seconds later.
バッファリング時間の推定値を見つけるために、t（）は、各パケットの特定の数の再送信を有効にするために使用するものとします。クライアントがT1秒後にバッファリングを開始すること。
First, we find the value of the estimate for 1 retransmission, T(1)=T:
まず、1回の再送信の推定値の値、t（1）= t：
T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT,
t1 t4〜 = rtt以来、
T = RTT + T2 + T3 + T5
The worst case for T3 would be that we assume that reporting has to wait a whole RTCP interval and that the maximum randomization factor of 1.5 is applied. Therefore, after applying the subsequent compensation to avoid traffic bursts (see Appendix A.7 of RTP [3]), we have that T3 = 1.5/1.21828*RTCP-Interval. Thus,
T3の最悪のケースは、レポートがRTCP全体の間隔全体を待たなければならず、最大ランダム化係数が1.5を適用していると仮定することです。したがって、トラフィックバーストを避けるために後続の補償を適用した後（RTP [3]の付録A.7を参照）、T3 = 1.5/1.21828*RTCP-Intervalがあります。したがって、
T = RTT + 1.2312*RTCP-Interval + T2 + T5
On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). In this scenario: sender + receivers = 3; RR+RS is the receiver report plus sender report bandwidth share, in this case, equal to the default 5% of session bandwidth, bw. We assume an average RTCP packet size, avg-rtcp-size = 120 bytes. Thus:
一方、rtcp-interval = avg-rtcp-size*8*（送信者レシーバー）/（rr rs）。このシナリオでは、送信者レシーバー= 3;RR RSは、受信者レポートと送信者レポート帯域幅の共有、この場合、セッション帯域幅のデフォルト5％に等しいBWに等しい。平均RTCPパケットサイズのAVG-RTCP-Size = 120バイトを想定しています。したがって：
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
for 1 retransmission.
1回の再送信。
For enabling N retransmissions, the available buffering time in a streaming server or client is approximately:
nの再送信を有効にするために、ストリーミングサーバーまたはクライアントで利用可能なバッファリング時間はほぼ次のとおりです。
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
where, as per above,
上記のように、
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N) = 120 + (1/3)*(12 + 4*N) = 124 + 4*N/3.
avg-rtcp-size = 120（receiver-rtcp-bw-share）*（12 4*n）= 120（1/3）*（12 4*n）= 124 4*n/3。
If we ignore the effect of T2 and T5, i.e., assume that all losses are detected immediately and that there is no additional delay due to feedback processing or retransmission queuing, we have the following buffering times for different values of N:
T2とT5の影響を無視した場合、つまり、すべての損失がすぐに検出され、フィードバック処理または再送信キューイングのために追加の遅延がないと仮定します。
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,21 2,44 6,28 8,97 13,18 128000 0,05 0,63 1,27 3,27 4,66 6,84 256000 0,05 0,34 0,68 1,76 2,50 3,67 512000 0,05 0,19 0,39 1,00 1,43 2,09 1024000 0,05 0,12 0,25 0,63 0,89 1,29 5000000 0,05 0,06 0,13 0,33 0,46 0,66 10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,05 1,21 2,44 6,28 8,97 13,18 128000 0,05 0,63 1,27 3,27 4,66 6,84 256000 0,05 0,34 0,68 1、76 2,50 3,67 512000 0,05 0,19 0,39 1,00 1,43 2,09 1024000 0,05 0,12 0,25 0,63 0,89 1,29 5000000 0,05 0、06 0,13 0,33 0,46 0,66 10000000 0,05 0,06 0,11 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68 128000 0,2 0,78 1,57 4,02 5,71 8,34 256000 0,2 0,49 0,98 2,51 3,55 5,17 512000 0,2 0,34 0,69 1,75 2,48 3,59 1024000 0,2 0,27 0,55 1,38 1,94 2,79 5000000 0,2 0,21 0,43 1,08 1,51 2,16 10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 0,2 1,36 2,74 7,03 10,02 14,68 128000 0,2 0,78 1,57 4,02 5,71 8,34 256000 0,2 0,49 0,98 2、51 3,55 5,17 512000 0,2 0,34 0,69 1,75 2,48 3,59 1024000 0,2 0,27 0,55 1,38 1,94 2,79 5000000 0,2 0、21 0,43 1,08 1,51 2,16 10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68 128000 1 1,58 3,17 8,02 11,31 16,34 256000 1 1,29 2,58 6,51 9,15 13,17 512000 1 1,14 2,29 5,75 8,08 11,59 1024000 1 1,07 2,15 5,38 7,54 10,79 5000000 1 1,01 2,03 5,08 7,11 10,16 10000000 1 1,01 2,01 5,04 7,06 10,08 To quantify the error of not taking the Generic NACKS into account, we can do the same numbers, but ignoring the Generic NACK contribution, avg-rtcp-size ~= 120 bytes. As we see from below, this may result in a buffer estimation error of 1-1.5 seconds (5-10%) for lower bandwidth values and higher number of retransmissions. This effect is low in this case. Nevertheless, it should be carefully evaluated for the particular scenario; that is why the formula includes it.
64000 1 2,16 4,34 11,03 15,62 22,68 128000 1 1,58 3,17 8,02 11,31 16,34 256000 1 1,29 2,58 6,51 9,15 13、17 512000 1 1,14 2,29 5,75 8,08 11,59 1024000 1 1,07 2,15 5,38 7,54 10,79 5000000 1 1,01 2,03 5,08 7,11 10、、16 10000000 1 1,01 2,01 5,04 7,06 10,08汎用NACKを考慮しないというエラーを定量化するには、同じ数字を実行できますが、一般的なNACKの貢献度を無視できます。AVG-RTCP-サイズ〜= 120バイト。下からわかるように、これにより、帯域幅の値が低く、再送信数が多い場合、バッファー推定誤差は1〜1.5秒（5〜10％）になります。この場合、この効果は低いです。それにもかかわらず、特定のシナリオについては慎重に評価する必要があります。そのため、式にはそれが含まれています。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
rtcp w/oジェネリックナック、固定パケットサイズ〜= 120バイト
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,16 2,32 5,79 8,11 11,58 128000 0,05 0,60 1,21 3,02 4,23 6,04 256000 0,05 0,33 0,65 1,64 2,29 3,27 512000 0,05 0,19 0,38 0,94 1,32 1,89 1024000 0,05 0,12 0,24 0,60 0,83 1,19 5000000 0,05 0,06 0,13 0,32 0,45 0,64 10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,05 1,16 2,32 5,79 8,11 11,58 128000 0,05 0,60 1,21 3,02 4,23 6,04 256000 0,05 0,33 0,65 1、64 2,29 3,27 512000 0,05 0,19 0,38 0,94 1,32 1,89 1024000 0,05 0,12 0,24 0,60 0,83 1,19 5000000 0,05 0、06 0,13 0,32 0,45 0,64 10000000 0,05 0,06 0,11 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08 128000 0,2 0,75 1,51 3,77 5,28 7,54 256000 0,2 0,48 0,95 2,39 3,34 4,77 512000 0,2 0,34 0,68 1,69 2,37 3,39 1024000 0,2 0,27 0,54 1,35 1,88 2,69 5000000 0,2 0,21 0,43 1,07 1,50 2,14 10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 0,2 1,31 2,62 6,54 9,16 13,08 128000 0,2 0,75 1,51 3,77 5,28 7,54 256000 0,2 0,48 0,95 2、39 3,34 4,77 512000 0,2 0,34 0,68 1,69 2,37 3,39 1024000 0,2 0,27 0,54 1,35 1,88 2,69 5000000 0,2 0、21 0,43 1,07 1,50 2,14 10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08 128000 1 1,55 3,11 7,77 10,88 15,54 256000 1 1,28 2,55 6,39 8,94 12,77 512000 1 1,14 2,28 5,69 7,97 11,39 1024000 1 1,07 2,14 5,35 7,48 10,69 5000000 1 1,01 2,03 5,07 7,10 10,14 10000000 1 1,01 2,01 5,04 7,05 10,07
64000 1 2,11 4,22 10,54 14,76 21,08 128000 1 1,55 3,11 7,77 10,88 15,54 256000 1 1,28 2,55 6,39 8,94 12、77 512000 1 1,14 2,28 5,69 7,97 11,39 1024000 1 1,07 2,14 5,35 7,48 10,69 5000000 1 1,01 2,03 5,07 7,10 10 10、14 10000000 1 1,01 2,01 5,04 7,05 10,07
Authors' Addresses
著者のアドレス
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセ・レイ・パナソニックR＆DセンタードイツGMBHモンザスト。4C D-63225 Langen、ドイツ
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
David Leon Consultant
デビッドレオンコンサルタント
EMail: davidleon123@yahoo.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
明氏宮崎matsushita Electric Industrial Co.、Ltd 1006、Kadoma、Kadoma City、大阪、日本
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: miyazaki.akihiro@jp.panasonic.com
Viktor Varsa Nokia Research Center 6000 Connection Drive Irving, TX. USA
Viktor Varsa Nokia Research Center 6000 Connection Drive Irving、Tx。アメリカ合衆国
Phone: 1-972-374-1861 EMail: viktor.varsa@nokia.com
電話：1-972-374-1861メール：viktor.varsa@nokia.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Rolf Hakenberg Panasonic R＆D CenterドイツGmbh Monzastr。4C D-63225 Langen、ドイツ
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。