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
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).
著作権（C）インターネット協会（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プロファイルで定義され、特に、それはそのリアルタイムトランスポート制御プロトコル（RTCP）フィードバックを想定しているこのメモで利用可能である（RTP / AVPFに示します）。
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.
この再送ペイロードフォーマットはAVPF [1]は、RTCPベースのフィードバックのための拡張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、ならびにコーデックとアプリケーション固有のフィードバック・メッセージを規定します。詳細については、[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多重：スキームオリジナルストリームと再送ストリームは異なる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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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の再送信は、1つの遅延対信頼性をトレードオフすることを可能にします。即ち、エンドポイントは、経過した所定のバッファリング時間の後に失われたパケットの再送をあきらめることができます。 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.
前記ペイロード・フォーマットの最大の多様性をサポートするために、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.
一つのアプローチは、元のシーケンス番号を有する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つの別個のストリームで送信されてもよいです。これら二つの流れは、SSRC多重化、即ち、異なるSSRC値を使用して、2つの異なるセッションで、すなわち、セッション多重化して送信することによって、または同じセッションのいずれかに多重化されてもよいです。元の再送パケットは同一種類のメディアを搬送するので、RTPの5.2節に反対[3] RTP多重この場合には適用されません。
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.
一方、二つの別々のストリームにオリジナルと再送パケットを送信するだけでは、この目的のための要件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.
セッション多重化は、元のストリームのものから（[3] RTPで定義されるように）異なるRTPセッションで再送ストリームを送信に基づいています。すなわち、元の再送ストリームは、異なるネットワークアドレス及び/又はポート番号に送信されます。別のセッションを持つことは、より柔軟に行うことができます。マルチキャストでは、元の再送ストリームのための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-多重化を使用すると、単一のセッションは、オリジナルと再送ストリームのために必要とされています。これは彼らのポートの使用を最小限に抑えるために同時セッション数が多いに関与しているストリーミングサーバやミドルウェアを可能にします。
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多重化の両方を可能にします。実装の観点からは、二つのアプローチの間にはほとんど違いがあります。したがって、相互運用性を最大にするために、両方の多重化アプローチは、送信者と受信者によってサポートされてください。 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 BYEパケットは衝突が起こったセッションで送信されなければならないことを要求します。また、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多重の場合には、二つの異なるSSRC値は、元のストリームとRTPによって要求される再送ストリームのために使用されなければなりません。 SSRC衝突がオリジナルストリームまたは再送ストリームのいずれかのために検出された場合には、RTP仕様は、RTCP BYEパケットは、このストリームのために送信されなければならないことを要求します。 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.
再送パケットのタイムスタンプは、元のメディアのタイムスタンプを運ぶように、再送ペイロードタイプによって使用されるタイムスタンプclockrateは、関連元のペイロードタイプによって使用されるものと同じでなければなりません。 RTPストリームは異なるclockratesのペイロードタイプを搬送する場合したがって、これは、関連する再送ストリームのためのケースであろう。 RTPストリームは通常、異なるclockratesのペイロードタイプを運ばないことに注意してください。
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つのオクテットです。このペイロード・ヘッダは、関連元のRTPパケットのシーケンス番号に設定しなければならない唯一のフィールド、OSN（元のシーケンス番号）を含んでいます。元のペイロードタイプに固有の任意の可能なペイロードヘッダを含む元の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多重両方の場合において、送信者は、元のストリームとそれに関連する再送ストリームの[3]と同じRTCP CNAMEを使用しなければなりません。
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.
セッション多重化が使用される場合、受信機は、二つのセッションで同じSSRCを有する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-多重化を使用する場合、受信機は、最初にすべてのセッションで同じCNAMEを持つ2つのストリームを探してください。いくつかのケースでは、CNAMEは、同じセッション内の複数の元のストリームが同じCNAMEを共有することができるように関連付けを決定するのに十分ではないかもしれません。例えば、そこに異なるSSRCsに同じビデオ・セッション複数のビデオストリームのマッピングであっても、依然として同じ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つの未処理の要求があってはなりません。別の受信機が別のストリームから同じシーケンス番号を要求した可能性があるため、マルチキャストでは、このあいまいさを完全に回避することができません。したがって、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プロファイルでこのペイロードフォーマットの使用のための一般的なヒントを与えて、[1] AVPFで示さ。一般的なRTCPセンドことに注意してくださいとRTPに指定されているルールとRTCPパケットフォーマットを受信AVPFプロファイルが導入されていることを、変更を除き、適用されます。要するに、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.
RTPで指定されるように、両方の場合において、セッション - 及びSSRC多重、BYEパケットはまだ両方のストリームのために送信しなければならないことに留意されたいです。言い換えれば、それだけで元のストリームのためにBYEパケットを送信するだけでは十分ではありません。
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パケットを再送セッションで送られながら、元のストリームに報告RRパケットは、元のRTPセッションに送信されます。これらの二つのセッションの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.
受信機はすぐにそれが欠落しているシーケンス番号を検出しますが、パケットの並べ替えを補償するためのいくつかの余分な遅延を追加する必要がありますよう再送要求を送信するべきではありません。この余分な遅延は、例えば、経験豊富なパケット並べ替えの過去の観測に基づいてもよいです。基本となるデータリンク層は、配達を注文もたらす場合にパケットの並べ替えがまれであるか、場所をとらない環境では、例えば、遅延が極めて低いこと、さらにはゼロの値をとることができ、ことに留意すべきです。このような場合には、適切な「再発注遅れ」アルゴリズムは、実際にタイマー基づいていますが、パケットベースではないかもしれません。ギャップが検出された後にパケットの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フィードバックメッセージは、[1] AVPFに従って、定期的な完全な複合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パケットを送信することを可能にしながら、この間隔は、規則的な受信機は、最小まで報告維持するために使用することができます。彼らはNACKを含んでいないため、RTCPパケットを抑制することができるが、それらが送られたかのように同じ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のPAUSEは、バッファがいっぱいできるようにするために発行された場合や（RTSPのPAUSEは、再送信の送信には影響しません）。
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".
「RTX」、「RTX-時間」、および「傾向」：次のMIMEサブタイプ名とパラメータは、本書で紹介されています。
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.
「傾向」（関連するペイロード・タイプ）パラメータは、関連する元のストリーム・ペイロード・タイプに再送信ペイロードタイプをマップするために使用されなければなりません。複数の元のペイロードタイプが使用される場合、複数の「傾向」パラメータが異なる再送ペイロードタイプに各オリジナルペイロードタイプをマップするために含まれなければなりません。
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-時間」は、送信者が再送信のために利用できるそのバッファ内のオリジナルのRTPパケットを維持する最大時間を示します。この時間は、パケットの最初の送信を開始します。
The syntax is as follows:
構文は次のとおりです。
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
=のfmtp：<番号>やすい= <やすく値>; RTX-時間= <RTX-時間-VAL>
where
どこ
<number>: indicates the dynamic payload type number assigned to the retransmission payload format in an rtpmap attribute.
<番号>：rtpmap属性に再送ペイロードフォーマットに割り当てられたダイナミックペイロードタイプ番号を示します。
<apt-value>: is the value of the original stream payload type to which this retransmission stream payload type is associated.
<やすい値>：この再送ストリームペイロードタイプが関連付けられている元のストリーム・ペイロード・タイプの値です。
<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-時間ヴァル>：送信者が再送信のために利用できるそのバッファにRTPパケットを保持していること（パケットが最初に送信された時刻から測定）の時間をミリ秒単位で指定します。再送ストリームのためのRTX-時間パラメータが存在しない場合は、最大再送時間が定義されていないが、他の手段によってネゴシエートされ得ることを意味します。
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-時間：送信者が再送信のために利用できるそのバッファにRTPパケットを保持していること（パケットが最初に送信された時刻から測定）ミリ秒単位の時間を示しています。
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
人とEメールアドレスは、詳細についての問い合わせ先：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図している用法：COMMON
Authors: Jose Rey David Leon
著者：ホセ・レイデビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
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-時間：送信者が再送信のために利用できるそのバッファにRTPパケットを保持していること（パケットが最初に送信された時刻から測定）ミリ秒単位の時間を示しています。
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
人とEメールアドレスは、詳細についての問い合わせ先：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図している用法：COMMON
Authors: Jose Rey David Leon
著者：ホセ・レイデビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
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-時間：送信者が再送信のために利用できるそのバッファにRTPパケットを保持していること（パケットが最初に送信された時刻から測定）ミリ秒単位の時間を示しています。
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
人とEメールアドレスは、詳細についての問い合わせ先：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図している用法：COMMON
Authors: Jose Rey David Leon
著者：ホセ・レイデビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
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-時間：送信者が再送信のために利用できるそのバッファにRTPパケットを保持していること（パケットが最初に送信された時刻から測定）ミリ秒単位の時間を示しています。
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
人とEメールアドレスは、詳細についての問い合わせ先：jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
意図している用法：COMMON
Authors: Jose Rey David Leon
著者：ホセ・レイデビッド・レオン
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
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メディアタイプの仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されている[5] SDP、のフィールドに特定のマッピングを有します。 SDPは、RTPストリームのための再送信を指定するために使用される場合、次のようにマッピングが行われます。
- The MIME types ("video"), ("audio"), ("text"), and ("application") go in the SDP "m=" as the media name.
- MIMEタイプ（ "ビデオ"）、（ "オーディオ"）、（ "テキスト"）、および（ "アプリケーション"）はメディア名として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" に進みます。 「= rtpmap」でのRTP clockrate再送ペイロードタイプのものでなければなりません。これに関する詳細については、第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に "= RTCP-FB" を行きます。いくつかのSDP「= RTCP-FBは、」フィードバックのいくつかのタイプのために使用されます。詳細については、[1] AVPFプロファイルを参照してください。
- 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.
- 「RTX時間」再送ペイロードフォーマット固有のパラメータ「やすい」とパラメータ=値のペアのセミコロンで区切られたリストとして、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に「=の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セッションごとにメディア仕様「M」の行を含んでいます。 SDP [6] RFC 3388で定義されたフロー識別（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を指定し、それぞれ、ポート49172と49176のポート49170と49174とそれに対応する再送ストリームに対してストリーム。
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
V = 0 0 = mascha 2980675221 2980675778 IN IP4 host.example.net C = IN IP4 192.0.2.0 A =基：FID 1 2 A =基：FID 3~4 M =オーディオ49170 RTP / AVPF 96 = rtpmap：96 AMR / 8000 =のfmtp：96オクテット整列= 1 A = RTCP-FB：96 NACK A =ミッド：1 M =オーディオ49172 RTP / AVPF 97 = rtpmap：97 RTX / 8000 =のfmtp：97やすい= 96。 = 3000 RTX-時間=半ば：2 M =ビデオ49174 RTP / AVPF 98 = rtpmap：98 MP4V-ES / 90000 A = RTCP-FB：98 NACK A =のfmtp：98プロファイルレベルID = 8;コンフィグ= 01010000012000884006682C209 \ 0A21F A =ミッド：3 M =ビデオ49176 RTP / AVPF 99 = rtpmap：99 RTX / 90000 =のfmtp：99やすい= 98; RTX-時間= 3000 =ミッド：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」の行と一つ再送セッション「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
V = 0 0 = mascha 2980675221 2980675778 IN IP4 host.example.net C = IN IP4 192.0.2.0のM =ビデオ49170 RTP / AVPF 96 = rtpmap：96 MP4V-ES / 90000 A = RTCP-FB：96 NACK A = fmtp：96プロファイルレベルID = 8;コンフィグ= 01010000012000884006682C209 \ 0A21F M =ビデオ49172 RTP / AVPF 97 = rtpmap：97 RTX / 90000 =のfmtp：97やすい= 96; RTX-時間= 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
IP4 192.0 IN V = 0 0 = mascha 2980675221 2980675778 IN IP4 host.example.net C =次は、上記シングルセッション例と同様のパラメータを有するSSRC多重化を使用してRTPビデオセッションのSDP記述の例であります.2.0 M =ビデオ49170 RTP / AVPF 96 97 = rtpmap：96 MP4V-ES / 90000 A = RTCP-FB：96 NACK A =のfmtp：96プロファイルレベルID = 8;コンフィグ= 01010000012000884006682C209 \ 0A21F A = rtpmap ：97 RTX / 90000 =のfmtp：97やすい= 96; RTX-時間= 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値は、SETUP応答のトランスポートヘッダに含まれている場合、それは元のストリームのものでなければなりません。
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とPAUSE要求として送信します。 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のPLAYとPAUSE要求を介して制御されるべきではありません。 PLAYとPAUSE要求が再送ストリームに影響を与えるべきではありません。再送パケットは、状態に関係なく、元の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.
SDP内の単一の「M」行があるためSSRC多重の場合には、RTSPは、再送ストリームのための独立したキャッシュを指定することはできません。 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.
第二の例では、再送が階層符号化と連動して（小）マルチキャストグループに使用することができる方法を示しています。これは、再送信と階層符号化は、相補的な技術であり得ることを示しています。
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多重化と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
V = 0 0 = mascha 2980675221 2980675778 IN IP4 host.example.net C = IN IP4 192.0.2.0のM =ビデオ49170 RTP / AVPF 96 97 = rtpmap：96 MP4V-ES / 90000 A = RTCP-FB：96 NACK A = rtpmap：97 RTX / 90000 =のfmtp：97やすい= 96; RTX-時間= 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-時間」は、サーバがパケットを再送バッファから削除され、再送信されることはありませんその後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プロファイルに定義されたように、それはNACKを介して送信側にパケットを失った信号[1]。受信機は、自身の受信バッファをディメンションするために考慮シグナリング送信側再送バッファ長を取るべきです。また、バッファ長からのパケットの再送を要求することができる最大回数を導き出す必要があります。
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.
マルチキャストでは、元の再送ストリームのSSRC多重は、このドキュメントのセクション5.3に従って許可されません。この理由のため、再送ストリーム（単数または複数）は、セッション多重化を使用して、異なる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
M =映像8000 RTP / AVPF 98個のC = IP4 224.2.1.0/127/3 IN = rtpmap：98 MP4V-ES / 90000 A = RTCP-FB：IP4 224.2 98 NACK M =映像8000 RTP / AVPF 99個のC = .1.3 / 3分の127 A = rtpmap：99 RTX / 90000 =のfmtp：99やすい= 98; RTX-時間= 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つの異なるメディアタイプのために登録されている：「ビデオ」、「オーディオ」、「テキスト」と「アプリケーション」。追加の必要なパラメータ、「傾向」、およびオプションのパラメータ、「RTX-時間」、定義されています。詳細については、セクション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の再送信のために非常に有害であることができ、のman-in-the-middleを有効にして、リプレイ攻撃があります。たとえば、次のように改ざん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.
暗号は、元のストリーム上でセキュリティサービスを提供するために使用されている場合は、同じサービスでは、同等の暗号強度で、再送ストリームに提供されなければなりません。再送されたストリームと元のストリームに同じ鍵を使用することは、セキュリティ上の問題、例えば、二度のパッドにつながる可能性があります。議論のためのセキュアリアルタイムトランスポートプロトコル（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）SRTPのみRTP / AVPをサポートし、一方、このペイロードフォーマットは、典型的には、RTP / AVPFプロファイルで動作するという事実。 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.
私たちは、この文書の開発に彼の参加のためカーステンBurmeisterへの感謝の意を表したいと思います。私たちのおかげでも彼らの役に立つコメントに浩一秦、コリンパーキンス、スティーブンCasner、マグヌスウェスター、ゴー堀、およびラーフルAgarwalさんに行きます。
[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]、RFC 4585、 "リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバックのための拡張RTPプロファイル" オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイを2006年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月に。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.および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]キャマリロ、G.、エリクソン、G.、大声、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.とラオと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]パーキンス、C.およびO.ホドソン、 "ストリーミングメディアの修理のためのオプション"、RFC 2354、1998年6月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[9]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のための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]ハンドリー、M.、フロイド、S.、Whetten、B.、Kermode、R.、Vicisano、L.、およびM.ルビー、 "大量データ転送のための信頼できるマルチキャストデザインスペース"、RFC 2887、2000年8月。
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[11]フリードマン、T.、カセレス、R.、およびA.クラーク、 "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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
Appendix A. How to Control the Number of Rtxs. per Packet
Rtxsの数を制御する方法付録A.。パケットあたり
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-時間」を介してクライアントに伝達することができます。
A.1. Scenario and Assumptions
A.1。シナリオと仮定
* 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-時間」によって示されるように、クライアントとサーバーは、緩衝空間が設けられています。
* RTP AVPF profile used with SSRC-multiplexing retransmission scheme: 1 SSRC for original packets, 1 for retransmission packets.
元のパケットの1 SSRC、再送パケット用の1：SSRC多重再送方式で使用される* RTP AVPFプロファイル。
* 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.
*リポジトリとのRR、すなわち、SR + RR = 0.05のデフォルトRTCP帯域幅シェア。我々は持っている送信者（2）と受信機（1）。送信者の割合は、セッションメンバーの1/4よりも大きいので、レシーバおよび送信者が均等に1/3 RTCP帯域幅シェアのを取得します。
* 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.
*平均-RTCPサイズは120バイトで近似されます。これにより105のバイト毎に行う、CNAMEとのIPv6 / UDP / SR / SDESため40/8/28/32バイトを含む、2つのSR、各SSRCに対して1つの切り上げ平均です。 157のバイトを作るのIPv6 / UDP / 2 * RR / SDESため40/8/64/32バイトとRR。送信側と受信側は、RTCP帯域幅に等しく、次いで平均-RTCPサイズ=（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は、再送を要求するために使用されます。これは、1 NACK及びあらゆる追加のNACKフィードバック制御情報（FCI）フィールドの4バイト以上のオーバーヘッドの16バイトを追加します。
* 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サイズ= 120 +（受信-RTCP-BW-株）*（12 + 4 * N）に、即ち、N * RTCP間隔（秒）後にRTCPパケットサイズがほぼ一定となります。我々の場合には、受信機RTCP帯域幅シェアは1/3です。従って、平均-RTCPサイズ= 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）であり、もう一つは再送信（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：ダウンリンク（クライアント - >サーバー）UL：アップリンク（サーバ - >クライアント）時間単位は秒、秒です。ビットレートの単位は、秒あたりのビット、BPSです。
DL transmission time: T1 = physical-delay-DL + tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
DL伝送時間：T1 =物理遅延-DL + TX-遅延-DL（=平均-PKTサイズ/ DL-ビットレート）+到着間遅延ジッタ
Time to detect packet loss: T2 = pkt-loss-detect-time
T2 = PKT-損失検出時：パケットの損失を検出するための時間
Time to report packet loss: T3 = time-to-next-rtcp-report
パケット損失を報告するための時間：T3 =タイム・ツー・次のRTCP-レポート
UL transmission time: T4 = physical-delay-UL + transmission-delay-UL + interarrival-delay-jitter
UL伝送時間：T4 =物理遅延-UL +送信遅延-UL +到着間遅延ジッタ
Retransmissions processing time: T5 = feedback-processing-time + rtx-queuing-time
再送処理時間：T5 =フィードバック処理時間+ RTXキューイング時間
A.2. Goal
A.2。ゴール
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（）の推定値を見つけるには1が考えれば、N.はこの時間は、サーバーのクライアントでほぼ同じですクライアントが後でT1秒のバッファリングを開始します。
A.3. Solution
A.3。解決
First, we find the value of the estimate for 1 retransmission, T(1)=T:
まず、1回の再送の推定値、T（1）= Tの値を見つけます：
T = T1 + T2 + T3 + T4 + T5
T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT,
T1 + T4〜= RTT以来、
T = RTT + T2 + T3 + T5
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の最大のランダム化率が適用されていることを前提としていることだろう。したがって、（[3] RTPの付録A.7を参照）トラフィックバーストを避けるために、その後の補償を適用した後、我々は、T3 = 1.5 / 1.21828 * RTCP-間隔ことがあります。したがって
T = RTT + 1.2312*RTCP-Interval + T2 + T5
T = RTT + 1.2312 * RTCP間隔+ 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間隔=平均-RTCPサイズ* 8 *（センダ+レシーバ）/（RR + RS）。このシナリオでは：送信者+受信機= 3; RR + RSは、BW、セッション帯域幅のデフォルトは5％に相当する。この場合、送信者レポート帯域幅を共有し、プラスレシーバレポートです。我々は、平均RTCPパケットサイズ、平均-RTCPサイズ= 120バイトをとります。したがって
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
T = RTT + 1.2312 *平均-RTCPサイズ* 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)
T（N）= N *（RTT + 1.2312 *平均-RTCPサイズ* 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.
平均-RTCPサイズ= 120 +（受信-RTCP-BW-株）*（12 + 4 * N）= 120 +（1/3）*（12 + 4 * N）= 124 + 4 * N / 3。
A.4. Numbers
A.4。数字
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の効果を無視した場合、すなわち、すべての損失は直ちに追加の遅延が原因フィードバック処理や再送待ち行列に存在しないことが検出され、我々は、N個の異なる値について、次のバッファリング時間を有することを前提と
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3 bytes
いくつかの一般的なのNACK / wのRTCP。可変パケットサイズ= 124 + 4 * N / 3バイト
|============|=====|======================================|
| 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,29 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
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.
アカウントにジェネリックNACKSを取っていないの誤差を定量化するために、我々は同じ番号を行うことができますが、一般的なNACKの貢献、平均-RTCPサイズ〜= 120のバイトを無視しました。我々は、下から見るように、これは1-1.5低帯域幅の値について秒（5〜10％）と再送信のより多数のバッファ推定誤差をもたらすことができます。この効果は低くなります。それにもかかわらず、慎重に特定のシナリオのために評価されるべきです。式には、それを含んでいる理由です。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
RTCP W /ジェネリックNACK 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,29 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,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社Monzastr。図4c D-63225ランゲン、ドイツ
Phone: +49-6103-766-134 Fax: +49-6103-766-166 EMail: jose.rey@eu.panasonic.com
電話：+ 49-6103-766-134ファックス：+ 49-6103-766-166 Eメール：jose.rey@eu.panasonic.com
David Leon Consultant
デビッド・レオンコンサルタント
EMail: davidleon123@yahoo.com
メールアドレス：davidleon123@yahoo.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
あきひろ みやざき まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 Ｌｔｄ １００６、 かどま、 かどま しｔｙ、 おさか、 じゃぱん
Phone: +81-6-6900-9172 Fax: +81-6-6900-9173 EMail: miyazaki.akihiro@jp.panasonic.com
電話：+ 81-6-6900-9172ファックス：+ 81-6-6900-9173 Eメール：miyazaki.akihiro@jp.panasonic.com
Viktor Varsa Nokia Research Center 6000 Connection Drive Irving, TX. USA
ヴィクトルVarsaノキア・リサーチセンター6000接続のドライブアーヴィング、テキサス州。米国
Phone: 1-972-374-1861 EMail: viktor.varsa@nokia.com
電話：1-972-374-1861 Eメール：viktor.varsa@nokia.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ロルフHakenbergパナソニックR＆DセンタードイツGmbH社Monzastr。図4c D-63225ランゲン、ドイツ
Phone: +49-6103-766-162 Fax: +49-6103-766-166 EMail: rolf.hakenberg@eu.panasonic.com
電話：+ 49-6103-766-162ファックス：+ 49-6103-766-166 Eメール：rolf.hakenberg@eu.panasonic.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。