RFC4588 日本語訳
4588 RTP Retransmission Payload Format. J. Rey, D. Leon, A. Miyazaki,V. Varsa, R. Hakenberg. July 2006. (Format: TXT=76630 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.レイの要求をネットワークでつないでください: 4588年のパナソニックカテゴリ: 標準化過程D.レオンコンサルタントA.宮崎パナソニックV.VarsaノキアR.Hakenbergパナソニック2006年7月
RTP Retransmission Payload Format
RTP Retransmission有効搭載量形式
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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 retransmissionは伸びやかな遅れ領域があるリアルタイムのアプリケーションのための効果的なパケット損失リカバリ技術です。 このドキュメントは、「再-トランスミッション」を実行するためにRTPペイロード形式について説明します。 元のRTPの流れから別々の流れで再送されたRTPパケットを送ります。 受信機から送付者までのフィードバックが利用可能であると思われます。 特に、RTCPベースのフィードバック(RTP/AVPFを指示する)のための拡張RTPプロフィールで定義されるレアル-時間Transport Controlプロトコル(RTCP)フィードバックがこのメモで利用可能であると思われます。
Rey, et al. Standards Track [Page 1] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[1ページ]。
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
1. 序論…3 2. 用語…3 3. Retransmission計画のための要件とデザイン原理…4 3.1. マルチプレクシング計画選択…6 4. Retransmission有効搭載量形式…7 5. Retransmissionとオリジナルの協会は流れます…9 5.1. Retransmissionセッション共有…9 5.2. CNAME使用…9 5.3. 受信機の協会…9 6. RTCPベースのフィードバックに拡張RTPプロフィールと共に使用します。11 6.1. 送付者のRTCP…11 6.2. RTCP受信機は報告します…11 6.3. Retransmission要求…12 6.4. タイミングは統治されます…13 7. 混雑コントロール…13 8. Retransmission有効搭載量形式MIMEの種類登録…15 8.1. 序論…15 8.2. オーディオ/rtxの登録…16 8.3. ビデオ/rtxの登録…17 8.4. テキスト/rtxの登録…18 8.5. アプリケーション/rtxの登録…19 8.6. SDPに写像します。20 8.7. セッションマルチプレクシングとのSDP記述…20 8.8. SSRC-マルチプレクシングとのSDP記述…21 9. RTSP問題…22 9.1. RTSPはSSRC-マルチプレクシングで制御します…22 9.2. RTSPはセッションマルチプレクシングで制御します…22 9.3. Retransmissionの流れのRTSPコントロール…23 9.4. コントロールをキャッシュしてください…23 10. 実現の例…23 10.1. 最小量の受信機実現の例…24 10.2. 層にされることのRetransmissionはマルチキャストにおけるメディアをコード化しました…25 11. IANA問題…26 12. セキュリティ問題…26 13. 承認…27 14. 参照…27 14.1. 標準の参照…27 14.2. 有益な参照…28付録、A. どうRtxsの数を制御するか、パケット単位で…29
Rey, et al. Standards Track [Page 2] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[2ページ]。
1. Introduction
1. 序論
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)(「再-トランスミッション」、またはインターリービング)が、パケット損失の弾性を増加させると考えられるかもしれません。 RFC2354[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.
特定用途のための修理のテクニックを選ぶとき、アプリケーションの許容できる潜在は考慮に入れられなければなりません。 マルチメディア会議の場合では、終わりから終わりへの遅れは、高々対話性(通常、「再-トランスミッション」の使用を除く)を保証する数100ミリセカンドでなければなりません。
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 retransmissionはそのようなアプリケーションのときに狙います。
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 retransmission方法はユニキャストと(小さい)のマルチキャストグループに適切です。 現在のドキュメントは、再送された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]、この「再-トランスミッション」ペイロード形式は拡張RTPプロフィールによるRTCPベースのフィードバックの使用のために設計されました。 また、それは将来定義される他の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プロフィールは頻繁なフィードバックと早めのフィードバックに関して以上を考慮します。 それはすなわち、汎用のフィードバックメッセージ、ナック、コーデック、およびアプリケーション特有のフィードバックメッセージを定義します。 詳細のための[1]を見てください。
2. Terminology
2. 用語
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の流れ。
Rey, et al. Standards Track [Page 3] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[3ページ]。
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.
Retransmissionパケット: 無くなっているオリジナルのパケットの代わりに受信機によって使用されることになっている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.
Retransmissionは以下を要求します。 RTP受信機が、RTP送付者が与えられたオリジナルのパケットのために「再-トランスミッション」パケットを送るべきであるよう要求できる手段。 通常、[1]の指定されるとしてのRTCP NACKパケットは無くなっているパケットに「再-トランスミッション」要求として使用されます。
Retransmission stream: the stream of retransmission packets associated with an original stream.
Retransmissionは流れます: 「再-トランスミッション」パケットの流れは元の流れと交際しました。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Requirements and Design Rationale for a Retransmission Scheme
3. Retransmission計画のための要件とデザイン原理
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 retransmissionは遅れに対して信頼性を交換するために1つを許容します。 すなわち、終点は、与えられたバッファリング時間が経過した後に無くなっているパケットを再送するのをやめるかもしれません。 TCPと異なって、ヘッドは全くその結果、いません。-線では、ブロッキングはRTP retransmissionsを引き起こしました。 implementerは完全な信頼性を必要とするか、または、より高い遅れとジターを許容できる場合では、TCPか他の輸送オプションが考えられるべきであるのを意識しているべきです。
The RTP retransmission scheme defined in this document is designed to fulfill the following set of requirements:
本書では定義されたRTP retransmission計画は以下のセットの要件を実現させるように設計されています:
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. それはセッションにおける複数のペイロードタイプの使用を防いではいけません。
Rey, et al. Standards Track [Page 4] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[4ページ]。
6. In order to support the largest variety of payload formats, the
RTP receiver must be able to derive how many and which RTP packets
were lost as a result of a gap in received RTP sequence numbers.
This requirement is referred to as sequence number preservation.
Without such a requirement, it would be impossible to use
retransmission with payload formats, such as conversational text
[9] or most audio/video streaming applications, that use the RTP
sequence number to detect lost packets.
6. 最も大きいバラエティーのペイロード形式を支持するために、RTP受信機はいくつ引き出すことができなければならないか、そして、どのRTPパケットが容認されたRTP一連番号におけるギャップの結果、失われましたか? この要件は一連番号保存と呼ばれます。 そのような要件がなければ、検出するRTP一連番号を使用する会話のテキスト[9]かほとんどのオーディオ/ビデオストリーミング・アプリケーションなどのペイロード形式がある「再-トランスミッション」がパケットを失ったのは、使用に不可能でしょう。
When designing a solution for RTP retransmission, several approaches may be considered for the multiplexing of the original RTP packets and the retransmitted RTP packets.
RTP retransmissionの解決策を設計するとき、いくつかのアプローチがオリジナルのRTPパケットと再送されたRTPパケットのマルチプレクシングのために考えられるかもしれません。
One approach may be to retransmit the RTP packet with its original sequence number and send original and retransmission packets in the same RTP stream. The retransmission packet would then be identical to the original RTP packet, i.e., the same header (and thus same sequence number) and the same payload. However, such an approach is not acceptable because it would corrupt the RTCP statistics. As a consequence, requirement 1 would not be met. Correct RTCP statistics require that for every RTP packet within the RTP stream, the sequence number be increased by one.
1つのアプローチは、元の一連番号でRTPパケットを再送して、同じRTPの流れでオリジナルと「再-トランスミッション」パケットを送ることであるかもしれません。 そして、「再-トランスミッション」パケットは、オリジナルのRTPパケットと同じで、すなわち、同じヘッダー(そして、その結果、同じ一連番号)と同じペイロードでしょう。 RTCP統計を崩壊させるでしょう、しかしながら、したがって、そのようなアプローチは許容できません。 結果として、必要条件1は満たされないでしょう。 正しいRTCP統計はあらゆるRTPパケットのためにRTPの流れ、一連番号の中でそれを必要とします。1つ増加します。
Another approach may be to multiplex original RTP packets and retransmission packets in the same RTP stream using different payload type values. With such an approach, the original packets and the retransmission packets would share the same sequence number space. As a result, the RTP receiver would not be able to infer how many and which original packets (which sequence numbers) were lost.
別のアプローチは同じRTPの流れで異なったペイロードタイプ値を使用することでオリジナルのRTPパケットと「再-トランスミッション」パケットを多重送信することであるかもしれません。 そのようなアプローチと、オリジナルのパケットと「再-トランスミッション」パケットは同じ一連番号スペースを共有するでしょう。 その結果、RTP受信機は(それの一連番号)が失われたどの何、とオリジナルのパケットを推論できないだろうか。
In other words, this approach does not satisfy the sequence number preservation requirement (requirement 6). This in turn implies that requirement 4 would not be met. Interoperability with mixers and translators would also be more difficult if they did not understand this new retransmission payload type in a sender RTP stream. For these reasons, a solution based on payload type multiplexing of original packets and retransmission packets in the same RTP stream is excluded.
言い換えれば、このアプローチは一連番号保存要件(要件6)を満たしません。 これは、必要条件4が満たされないのを順番に含意します。 また、彼らが送付者RTPの流れでこの新しい「再-トランスミッション」ペイロードタイプを理解していないなら、ミキサーと翻訳者がいる相互運用性も、より難しいでしょうに。 これらの理由で、同じRTPの流れでオリジナルのパケットと「再-トランスミッション」パケットのペイロードタイプマルチプレクシングに基づく解決策は除かれます。
Finally, the original and retransmission packets may be sent in two separate streams. These two streams may be multiplexed either by sending them in two different sessions , i.e., session-multiplexing, or in the same session using different SSRC values, i.e., SSRC- multiplexing. Since original and retransmission packets carry media of the same type, the objections in Section 5.2 of RTP [3] to RTP multiplexing do not apply in this case.
最終的に、2つの別々の流れでオリジナルと「再-トランスミッション」パケットを送るかもしれません。すなわち、2つの異なったセッション、セッションマルチプレクシングのときにそれらを送るか、または同じセッションのときに異なったSSRC値を使用することによって、これらの2つの小川を多重送信するかもしれません、すなわち、SSRCが多重送信して。 オリジナルと「再-トランスミッション」パケットが同じタイプのメディアを載せるので、RTPマルチプレクシングへのRTP[3]のセクション5.2における反論はこの場合適用されません。
Rey, et al. Standards Track [Page 5] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[5ページ]。
Mixers and translators may process the original stream and simply discard the retransmission stream if they are unable to utilise it.
彼らがそれを利用できないなら、ミキサーと翻訳者は、元の流れを処理して、単に「再-トランスミッション」の流れを捨てるかもしれません。
On the other hand, sending the original and retransmission packets in two separate streams does not alone satisfy requirements 1 and 6. For this purpose, this document includes the original sequence number in the retransmitted packets.
他方では、単独で2つの別々の流れのパケットが送らないオリジナルと「再-トランスミッション」を送って、要件1と6を満たしてください。 このために、このドキュメントは再送されたパケットに元の一連番号を含んでいます。
In this manner, using two separate streams satisfies all the requirements listed in this section.
この様に、2つの別々の流れを使用すると、このセクションでリストアップされたすべての要件が満たされます。
3.1. Multiplexing Scheme Choice
3.1. マルチプレクシング計画選択
Session-multiplexing and SSRC-multiplexing have different pros and cons:
セッションマルチプレクシングとSSRC-マルチプレクシングには、異なった賛否両論があります:
Session-multiplexing is based on sending the retransmission stream in a different RTP session (as defined in RTP [3]) from that of the original stream; i.e., the original and retransmission streams are sent to different network addresses and/or port numbers. Having a separate session allows more flexibility. In multicast, using two separate sessions for the original and the retransmission streams allows a receiver to choose whether or not to subscribe to the RTP session carrying the retransmission stream. The original session may also be single-source multicast while separate unicast sessions are used to convey retransmissions to each of the receivers, which as a result will receive only the retransmission packets they request.
異なったRTPセッションにおける「再-トランスミッション」の流れを送ることに基づいてセッションマルチプレクシングはいます。(オリジナルのものからRTP[3])で定義されるように、流れてください。 すなわち、オリジナルと「再-トランスミッション」小川を異なったネットワーク・アドレス、そして/または、ポートナンバーに送ります。 別々のセッションを過すと、より多くの柔軟性が許容されます。 マルチキャストでは、オリジナルと「再-トランスミッション」の流れに2つの別々のセッションを使用するのに、受信機は、「再-トランスミッション」の流れを運ぶRTPセッションに申し込むかどうかを選ぶことができます。 また、別々のユニキャストセッションがその結果それらが要求する「再-トランスミッション」パケットだけを受けるそれぞれの受信機まで「再-トランスミッション」を運ぶのに使用される間、オリジナルのセッションは単独のソースマルチキャストであるかもしれません。
The use of separate sessions also facilitates differential treatment by the network and may simplify processing in mixers, translators, and packet caches.
別々のセッションの使用も、ネットワークで差別待遇を容易にして、ミキサー、翻訳者、およびパケットキャッシュで処理を簡素化するかもしれません。
With SSRC-multiplexing, a single session is needed for the original and the retransmission streams. This allows streaming servers and middleware that are involved in a high number of concurrent sessions to minimise their port usage.
SSRC-マルチプレクシングで、ただ一つのセッションがオリジナルと「再-トランスミッション」の流れに必要です。これは、大きい数の同時発生のセッションにかかわるストリーミングサーバとミドルウェアがそれらのポート用法を最小とならせるのを許容します。
This retransmission payload format allows both session-multiplexing and SSRC-multiplexing for unicast sessions. From an implementation point of view, there is little difference between the two approaches. Hence, in order to maximise interoperability, both multiplexing approaches SHOULD be supported by senders and receivers. For multicast sessions, session-multiplexing MUST be used because the association of the original stream and the retransmission stream is problematic if SSRC-multiplexing is used with multicast sessions(see Section 5.3 for motivation).
この「再-トランスミッション」ペイロード形式はユニキャストセッションのためにセッションマルチプレクシングとSSRC-マルチプレクシングの両方を許容します。 実現観点から、少しの違いは2つのアプローチの間で来ています。 したがって、相互運用性を最大にするには、ともにアプローチSHOULDを多重送信して、送付者と受信機によって支持されてください。 マルチキャストセッションのために、SSRC-マルチプレクシングがマルチキャストセッションと共に使用されるなら(動機に関してセクション5.3を見てください)元の流れと「再-トランスミッション」の流れの協会が問題が多いので、セッションマルチプレクシングを使用しなければなりません。
Rey, et al. Standards Track [Page 6] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[6ページ]。
4. Retransmission Payload Format
4. Retransmission有効搭載量形式
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSN| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | オリジナルのRTPパケット有効搭載量| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-マルチプレクシングの場合では、RTPは元の流れと「再-トランスミッション」の流れに必要に応じて2つの異なったSSRC値を使用しなければなりません。 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タイムスタンプは無作為であるのではなく、再送される最初のパケットのオリジナルのタイムスタンプと等しいです。 本書ではセキュリティ含意に関してSecurity Considerations部を見てください。
Rey, et al. Standards Track [Page 7] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[7ページ]。
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.
Implementersはパケットが再送される時、そのオリジナルのタイムスタンプの間には、相関関係がほとんどあるはずがなかったので「再-トランスミッション」の流れのための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).
ペイロードタイプはダイナミックです。 「再-トランスミッション」を使用している複数のペイロードタイプが元の流れで出席しているなら、それぞれのこれらに関して、ダイナミックなペイロードタイプを「再-トランスミッション」ペイロード形式に写像しなければなりません。 Session記述プロトコルでどうオリジナルと「再-トランスミッション」ペイロードタイプの間のマッピングをするかに関する(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 retransmissionパケットのペイロードは「再-トランスミッション」ペイロードヘッダーを包括します、続いて、オリジナルのRTPパケットのペイロードを包括します。 「再-トランスミッション」ペイロードヘッダーの長さは2つの八重奏です。 このペイロードヘッダーは1つの分野だけ、関連オリジナルの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パケットのペイロードヘッダーの値は、もう「再-トランスミッション」パケットに申し込まないで、レートにおける変化を反映するように「再-トランスミッション」パケットで変更される必要があるかもしれません。 送付者SHOULDは低料金で再送することによって引き起こされた品質の減少がある帯域幅用法の減少を交換します。
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
オリジナルのRTPヘッダーが何かプロフィール特有の拡大を運んだなら、すぐにこのプロフィールの下を走るアプリケーションで予想されるように固定RTPヘッダーに続いて、「再-トランスミッション」パケットSHOULDは同じ拡大を含んでいます。 この場合
Rey, et al. Standards Track [Page 8] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[8ページ]。
retransmission payload header MUST be placed after the profile- specific extensions.
プロフィールの特定の拡張子の後に「再-トランスミッション」ペイロードヘッダーを置かなければなりません。
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ヘッダー拡張子を運んだなら、「再-トランスミッション」パケットSHOULDは同じヘッダー拡大を運びます。 このヘッダー拡大は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ヘッダーにコピーしなければなりません。
5. Association of Retransmission and Original Streams
5. Retransmissionと元の流れの協会
5.1. Retransmission Session Sharing
5.1. Retransmissionセッション共有
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.
「再-トランスミッション」であるなら、セッション共有は許されて、それは受信機のための問題でしょう、自分達がそれらが参加していないかもしれないオリジナルのセッションのために「再-トランスミッション」を受けるでしょう、したがって。 例えば、また、オーディオとビデオセッションが同じ「再-トランスミッション」セッションを共有したなら、受信専用オーディオに願っているのが受ける受信機はビデオパケットを再送しました。
5.2. CNAME Use
5.2. CNAME使用
In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same RTCP CNAME [3] for an original stream and its associated retransmission stream.
セッションマルチプレクシングとSSRC-マルチプレクシングケースの両方では、送付者は元の流れとその関連「再-トランスミッション」の流れに同じRTCP CNAME[3]を使用しなければなりません。
5.3. Association at the Receiver
5.3. 受信機の協会
A receiver receiving multiple original and retransmission streams needs to associate each retransmission stream with its original stream. The association is done differently depending on whether session-multiplexing or SSRC-multiplexing is used.
複数のオリジナルと「再-トランスミッション」の流れを受け取る受信機は、それぞれの「再-トランスミッション」の流れを元の流れに関連づける必要があります。 協会はセッションマルチプレクシングかSSRC-マルチプレクシングが使用されているかどうかに異なってより終わっています。
If session-multiplexing is used, the receiver associates the two streams having the same SSRC in the two sessions. Note that the payload type field cannot be used to perform the association as
セッションマルチプレクシングが使用されているなら、受信機は2つのセッションのときに同じSSRCを持っている2つの流れを関連づけます。 協会を実行するのにペイロードタイプ分野を使用できない注意
Rey, et al. Standards Track [Page 9] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[9ページ]。
several media streams may have the same payload type value. The two sessions are themselves associated out-of-band. See Section 8 for how the grouping of the two sessions is done with SDP.
いくつかのメディアの流れで、同じペイロードは値をタイプするかもしれません。 2つのセッションがバンドの外に関連づけられます。 SDPと共に2つのセッションの組分けをどうするかためにセクション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とことによると同じペイロードタイプ(太平洋標準時の)値があることができます。 それぞれ(または、いくつか)のこれらの流れには、関連「再-トランスミッション」の流れがあるかもしれません。
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を持ちながらオリジナルと「再-トランスミッション」の流れの間に協会を見つけるために、受信機SHOULDは以下の通り振る舞います。
The association can generally be resolved when the receiver receives a retransmission packet matching a retransmission request that had been sent earlier. Upon reception of a retransmission packet whose original sequence number has been previously requested, the receiver can derive that the SSRC of the retransmission packet is associated to the sender SSRC from which the packet was requested.
受信機が前に送られた「再-トランスミッション」要求に合っている「再-トランスミッション」パケットを受けるとき、一般に、協会を決議できます。 元の一連番号が要求されていて、以前に受信機がそれを引き出すことができるということである「再-トランスミッション」パケットのレセプションでは、「再-トランスミッション」パケットのSSRCはパケットが要求された送付者SSRCに関連づけられます。
However, this mechanism might fail if there are two outstanding requests for the same packet sequence number in two different original streams of the session. Note that since the initial packet sequence numbers are random, the probability of having two outstanding requests for the same packet sequence number would be very small. Nevertheless, in order to avoid ambiguity in the unicast case, the receiver MUST NOT have two outstanding requests for the same packet sequence number in two different original streams before the association is resolved. In multicast, this ambiguity cannot be completely avoided, because another receiver may have requested the same sequence number from another stream. Therefore, SSRC- multiplexing MUST NOT be used in multicast sessions.
しかしながら、セッションの2つの異なった元の流れに同じパケット一連番号を求める2つの傑出している要求があれば、このメカニズムは失敗するかもしれません。 初期のパケット一連番号が無作為であるので同じパケット一連番号を求める2つの傑出している要求を持っているという確率が非常にわずかであることに注意してください。 それにもかかわらず、ユニキャスト場合であいまいさを避けるために、協会が決議される前に受信機は2つの異なった元の流れで同じパケット一連番号を求める2つの傑出している要求を持ってはいけません。 マルチキャストでは、完全にこのあいまいさを避けることができるというわけではありません、別の受信機が別の流れから同じ一連番号に頼んだかもしれないので。 したがって、マルチキャストセッションのときにSSRCマルチプレクシングを使用してはいけません。
If the receiver discovers that two senders are using the same SSRC or if it receives an RTCP BYE packet, it MUST stop requesting retransmissions for that SSRC. Upon reception of original RTP packets with a new SSRC, the receiver MUST perform the SSRC association again as described in this section.
受信機が、2人の送付者が同じSSRCを使用していると発見するか、またはRTCP BYEパケットを受けるなら、それは、そのSSRCのために「再-トランスミッション」を要求するのを止めなければなりません。 新しいSSRCとのオリジナルのRTPパケットのレセプションに、受信機は再びこのセクションで説明されるようにSSRC協会を実行しなければなりません。
Rey, et al. Standards Track [Page 10] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[10ページ]。
6. Use with the Extended RTP Profile for RTCP-based Feedback
6. 拡張RTPプロフィールとのRTCPベースのフィードバックの使用
This section gives general hints for the usage of this payload format with the extended RTP profile for RTCP-based feedback, denoted AVPF [1]. Note that the general RTCP send and receive rules and the RTCP packet format as specified in RTP apply, except for the changes that the AVPF profile introduces. In short, the AVPF profile relaxes the RTCP timing rules and specifies additional general-purpose RTCP feedback messages. See [1] for details.
このセクションはRTCPベースのフィードバックのための拡張RTPプロフィールがあるこのペイロード形式の用法のための一般的なヒントを与えます、とAVPF[1]は指示しました。 一般的なRTCPが規則を送って、受け取るというメモとRTPの指定されるとしてのRTCPパケット・フォーマットは適用されます、AVPFプロフィールが導入する変化を除いて。 要するに、AVPFプロフィールは、RTCPタイミング規則を弛緩して、追加汎用RTCPフィードバックメッセージを指定します。 詳細のための[1]を見てください。
6.1. RTCP at the Sender
6.1. 送付者のRTCP
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.
セッションマルチプレクシングの場合では、オリジナルのセッションのときに元の流れのためのSender Report(SR)パケットを送ります、そして、RTPの規則に従って、「再-トランスミッション」セッションのときに「再-トランスミッション」の流れのためのSRパケットを送ります。
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-マルチプレクシングの場合では、RTPの規則に従って、同じセッションのときにオリジナルと「再-トランスミッション」の流れの両方のためのSRパケットを送ります。 オリジナルと「再-トランスミッション」の流れは、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に送るのは十分ではありません。
6.2. RTCP Receiver Reports
6.2. RTCP受信機レポート
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]).
セッションマルチプレクシングの場合では、受信機で、元の流れと「再-トランスミッション」の流れのための別々のReceiver Report(RR)パケットでのレポートブロックは、RTPセッションを切り離すために属するでしょう。 元の流れに関して報告するRRパケットは「再-トランスミッション」セッションのときに「再-トランスミッション」の流れに関して報告するRRパケットを送る間のオリジナルのRTPセッションのときに送られます。 これらの2つのセッションのためのRTCP帯域幅は独自に選ばれるかもしれません。(例えば、RTCP帯域幅修飾語[4])を通して。
In the case of SSRC-multiplexing, the receiver sends report blocks for the original and the retransmission streams in the same RR packet since there is a single session.
SSRC-マルチプレクシングの場合では、ただ一つのセッションがあるので、受信機は同じRRパケットでオリジナルのためのレポートブロックと「再-トランスミッション」の流れを送ります。
Rey, et al. Standards Track [Page 11] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[11ページ]。
6.3. Retransmission Requests
6.3. Retransmission要求
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でプロフィールSHOULDを定義しました。受信機で、「再-トランスミッション」要求を送るのが使用されてください。 受信機が、パケットを要求するのを選ぶかどうかが、導入問題です。 実際の受信機実現は許容できるアプリケーション遅れ、ネットワーク環境、およびメディアがタイプするような要素を考慮に入れるべきです。
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)の見積りを送付者に計算するはずです。 例えば、そのパケットのためにナックを送った後に「再-トランスミッション」パケットを受けるために「再-トランスミッション」遅れを測定することによって、これができます。 また、利用可能であるなら観測、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番号が受け取られているなら、故障しているというよりむしろ本当に、パケットが無くなったと思われるかもしれません。 これはタイマベースのメカニズムと対照的に非常に短い固定先入れ先出し法パケットバッファとしていくつかのプラットホームでコード化するのがはるかに簡単であると判明するかもしれません。
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
ナックか「再-トランスミッション」パケットの損失に丈夫さを増加させに、新しいナックは同じパケットに受信機で行くかもしれません。 これは複数の「再-トランスミッション」と呼ばれます。 なくなったパケットのために新しいナックを送る前に、受信機は、前の「再-トランスミッション」試みが失敗したのを合理的に確信しているので不要な「再-トランスミッション」を避けるためにタイマを当てにするはずです。 タイマ値は観測された往復の時間に基づくものとします。 静的な値か適応型の値が使用されるかもしれません。 例えば、適応型のタイマ
Rey, et al. Standards Track [Page 12] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[12ページ]。
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.
同じパケットを求めるあらゆる新しい要求に従って値を変えるものであるかもしれません。 この適応型の値がこれを見つけるために全く実験していないのでどう計算されるべきであるかに関してこのドキュメントはどんなガイドラインも提供しません。
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.
元のRTPの流れのためだけにNACKsを送らなければなりません。 さもなければ、受信機が「再-トランスミッション」の流れでナックを送ることによって複数の「再-トランスミッション」を実行したいなら、それが要求するパケットに関する元の一連番号とタイムスタンプ見積りを知ることができないでしょうに。
Appendix A gives some guidelines as to how to control the number of retransmissions.
付録Aはどう「再-トランスミッション」の数を制御するかに関していくつかのガイドラインを与えます。
6.4. Timing Rules
6.4. タイミング規則
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.
レギュラーの完全な合成RTCPパケットか早いRTCPパケットでナックフィードバックメッセージを送るかもしれません、AVPF[1]に従って。 早いパケットでナックを送るのは、より急速に与えられたパケット損失に反応するのを許容します。 しかしながら、その場合、早いRTCPパケットを送ったまさしく後に新しいパケット損失が起こるなら、そして、受信機は早いパケットの後に次のレギュラーのRTCP合成パケットを待っていなければなりません。 NACKsを通常のRTCPが合成する送るだけであるなら、オリジナルのパケット損失を検出して、そのパケットのためにナックを送ることができることの間の最大の遅れは減少します。 Implementersは使用されるアプリケーションのためのこの事実の関与の可能性を考えるはずです。
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パケットを送るのをまだ許容している間、定期的な受信機報告を最小限に下がるのに続けるためにこの間隔を費やすことができます、例えば、より高いパケット損失の倍は評価します。 NACKsを含んでいないのでRTCPパケットが抑圧されるかもしれませんが、同じRTCP帯域幅が、まるで彼らを送るかのように利用可能である必要に注意してください。 最小間隔の使用に関する詳細に関してAVPF[1]を見てください。
7. Congestion Control
7. 輻輳制御
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 retransmissionはネットワークの混雑を増加させるという危険を引き起こします。 ベストエフォート型環境で、パケット損失は混雑で引き起こされます。 その結果、元の流れの速度を減少させないで、より古いデータの「再-トランスミッション」による損失に反応するのは混雑をさらに増加させるでしょう。 実現SHOULDは、「再-トランスミッション」を使用するために以下での推薦に続きます。
Rey, et al. Standards Track [Page 13] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[13ページ]。
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に公正になるようにその許容できるbitrateとパケットレートを測定できますか、または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アプリケーションが「再-トランスミッション」を使用するなら、許容できるパケットレートとbitrateはオリジナルの、そして、再送されたデータを含んでいます。 これは、「再-トランスミッション」を使用するアプリケーションが1つと同じそうしないのに公正を実現するのを保証します。 そのような規則は実際には以下の動作に翻訳されるでしょう:
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).
高度サービスが使用されているなら、総bitrateとパケットレートが要求されたサービスのものを超えていないのが確実にされるべきです。 モニターされて、実際に要求されたサービスを提供するのは、より遠いはずです。 ベストエフォート型環境で、元の流れ(例えば低料金でデータをコード化することによって)のパケットレートとbitrateを低下させないで、送付者SHOULD NOTは「再-トランスミッション」パケットを送ります。
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.
さらに、送付者は、bitrateを制限するために選択的に、それが重要であると考えるパケットだけを再送して、他のパケットへのナックメッセージを無視するかもしれません。
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流動が実現するものである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 コントロール、当時のretransmission SHOULDであることは混雑で保たれないなら、使用されないでください。
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).
いくつかの場合、まだ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.
最終的に、通信速度(層の数は層にされたマルチキャストセッションのために申し込まれた)を適合させるか、または受信機がセッションを出発するように手配するのがさらに必要であるかもしれません。
Rey, et al. Standards Track [Page 14] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[14ページ]。
8. Retransmission Payload Format MIME Type Registration
8. Retransmission有効搭載量形式MIMEの種類登録
8.1. Introduction
8.1. 序論
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt".
以下のMIME「副-タイプ」名とパラメタは本書では紹介されます: 「rtx-時間」の、そして、「しやすい」"rtx"。
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-時間」というOPTIONALペイロード形式詳細パラメタは、最大の時間a送付者が「再-トランスミッション」に利用可能なバッファにオリジナルのRTPパケットを保つのを示します。 今回はパケットの最初のトランスミッションから始まります。
The syntax is as follows:
構文は以下の通りです:
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
a=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-時間val>: 送付者が「再-トランスミッション」に利用可能なバッファにRTPパケットであることを保つミリセカンド(パケットが最初に送られた時間から、測定されます)で時間を指定します。 「再-トランスミッション」の流れのためのrtx-時間パラメタの欠如は、最大の「再-トランスミッション」時間が定義されませんが、他の手段で交渉されるかもしれないことを意味します。
Rey, et al. Standards Track [Page 15] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[15ページ]。
8.2. Registration of audio/rtx
8.2. オーディオ/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タイムスタンプclockrateは再送されるメディアのRTPタイムスタンプclockrateと等しいです。
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
しやすい: 関連ペイロードタイプ。 このパラメタの値は関連元の流れのペイロードタイプです。
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
セキュリティ問題: RFC4588のセクション12を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4588
広められた仕様: RFC4588
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
意図している用法: 一般的
Authors: Jose Rey David Leon
作者: ホセ・レイデヴィッド・レオン
Change controller: IETF AVT WG delegated from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF AVT WG
Rey, et al. Standards Track [Page 16] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[16ページ]。
8.3. Registration of video/rtx
8.3. ビデオ/rtxの登録
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タイムスタンプclockrateは再送されるメディアのRTPタイムスタンプclockrateと等しいです。
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
しやすい: 関連ペイロードタイプ。 このパラメタの値は関連元の流れのペイロードタイプです。
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
セキュリティ問題: RFC4588のセクション12を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4588
広められた仕様: RFC4588
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
意図している用法: 一般的
Authors: Jose Rey David Leon
作者: ホセ・レイデヴィッド・レオン
Change controller: IETF AVT WG delegated from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF AVT WG
Rey, et al. Standards Track [Page 17] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[17ページ]。
8.4. Registration of text/rtx
8.4. テキスト/rtxの登録
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タイムスタンプclockrateは再送されるメディアのRTPタイムスタンプclockrateと等しいです。
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
しやすい: 関連ペイロードタイプ。 このパラメタの値は関連元の流れのペイロードタイプです。
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
セキュリティ問題: RFC4588のセクション12を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4588
広められた仕様: RFC4588
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
意図している用法: 一般的
Authors: Jose Rey David Leon
作者: ホセ・レイデヴィッド・レオン
Change controller: IETF AVT WG delegated from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF AVT WG
Rey, et al. Standards Track [Page 18] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[18ページ]。
8.5. Registration of application/rtx
8.5. アプリケーション/rtxの登録
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タイムスタンプclockrateは再送されるメディアのRTPタイムスタンプclockrateと等しいです。
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
しやすい: 関連ペイロードタイプ。 このパラメタの値は関連元の流れのペイロードタイプです。
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
セキュリティ問題: RFC4588のセクション12を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4588
広められた仕様: RFC4588
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
意図している用法: 一般的
Authors: Jose Rey David Leon
作者: ホセ・レイデヴィッド・レオン
Change controller: IETF AVT WG delegated from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF AVT WG
Rey, et al. Standards Track [Page 19] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[19ページ]。
8.6. Mapping to SDP
8.6. SDPへのマッピング
The information carried in the MIME media type specification has a specific mapping to fields in SDP [5], which is commonly used to describe RTP sessions. When SDP is used to specify retransmissions for an RTP stream, the mapping is done as follows:
MIMEで運ばれて、メディアが仕様をタイプするという情報はSDP[5]に特定のマッピングを分野に持っています。([5]は、RTPセッションについて説明するのに一般的に使用されます)。 RTPの流れに「再-トランスミッション」を指定するのにSDPを使用するとき、以下の通りマッピングをします:
- 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"に入ります。 "a=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"a=rtcp-fb"に入ります。 数個SDP"a=rtcp-fb"はいくつかのタイプのフィードバックに使用されます。 詳細のためのAVPFプロフィール[1]を見てください。
- The retransmission payload-format-specific parameters "apt" and
"rtx-time" go in the SDP "a=fmtp" as a semicolon-separated list of
parameter=value pairs.
- パラメタ=価値のセミコロンで切り離されたリストが対にされるとき、「しやすい」という「再-トランスミッション」ペイロード形式詳細パラメタと「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"a=fmtp"属性に入ります。
In the following sections, some example SDP descriptions are
presented. In some of these examples, long lines are folded to meet
the column width constraints of this document; the backslash ("\") at
the end of a line and the carriage return that follows it should be
ignored.
以下のセクションでは、いくつかの例のSDP記述が示されます。 これらの例のいくつかでは、長い線はこのドキュメントのカラム幅規制を満たすために折り重ねられます。 線の端とそれに続く復帰におけるバックスラッシュ(「\」)は無視されるべきです。
8.7. SDP Description with Session-Multiplexing
8.7. セッションマルチプレクシングとのSDP記述
In the case of session-multiplexing, the SDP description contains one media specification "m" line per RTP session. The SDP MUST provide the grouping of the original and associated retransmission sessions' "m" lines, using the Flow Identification (FID) semantics defined in RFC 3388 [6].
セッションマルチプレクシングの場合では、SDP記述はRTPセッションあたり1つのメディア仕様「m」線を含んでいます。 SDP MUSTはオリジナルの、そして、関連している「再-トランスミッション」セッションの「m」線の組分けを提供します、RFC3388[6]で定義されたFlow Identification(FID)意味論を使用して。
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:
以下の例はポート49172と49176の上でそれぞれ2オリジナル、AMR、MPEG-4、ポート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
=グループあたりv=0 o=mascha2980675221 2980675778IN IP4 host.example.net c=IN IP4 192.0.2.0: FID1 2
Rey, et al. Standards Track [Page 20] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[20ページ]。
a=group:FID 3 4 m=audio 49170 RTP/AVPF 96 a=rtpmap:96 AMR/8000 a=fmtp:96 octet-align=1 a=rtcp-fb:96 nack a=mid:1 m=audio 49172 RTP/AVPF 97 a=rtpmap:97 rtx/8000 a=fmtp:97 apt=96;rtx-time=3000 a=mid:2 m=video 49174 RTP/AVPF 98 a=rtpmap:98 MP4V-ES/90000 a=rtcp-fb:98 nack a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\ 0A21F a=mid:3 m=video 49176 RTP/AVPF 99 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98;rtx-time=3000 a=mid:4
グループ..オーディオ..八重奏..並べる..中間..オーディオ..しやすい..時間..中間..ビデオ..プロフィール..平ら..イド..コンフィグ..中間..ビデオ..しやすい..時間..等しい..中間
A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only.
SDP記述の特別なケースは1つの元のセッション「m」線と1つの「再-トランスミッション」セッション「m」線だけを含む記述です、そして、次に、組分けは明白です、そして、FID意味論はこの特別な場合だけで省略されるかもしれません。
This is illustrated in the following example, which is an SDP description for a single original MPEG-4 stream and its corresponding retransmission session:
これは以下の例で例証されます:(例はただ一つの元のMPEG-4の流れとその対応する「再-トランスミッション」セッションのためのSDP記述です)。
v=0 o=mascha 2980675221 2980675778 IN IP4 host.example.net c=IN IP4 192.0.2.0 m=video 49170 RTP/AVPF 96 a=rtpmap:96 MP4V-ES/90000 a=rtcp-fb:96 nack a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 0A21F m=video 49172 RTP/AVPF 97 a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96;rtx-time=3000
v=0 o=mascha2980675221 2980675778IN IP4 host.example.net cがIN IP4と等しい、192.0、.2、.0m、=ビデオ49170RTP/AVPF96a=rtpmap: 96MP4V-ES/90000a=rtcp-fb: 96nack a=fmtp: 96プロフィールビデオ49172RTP/AVPF97イド=01010000012000884006682C209 8;コンフィグ=%%BODY%%A21F m=a=rtpmap: 97rtx/90000a=fmtp: 97を平らにしているしやすい=96;rtx3000時間=
8.8. SDP Description with SSRC-Multiplexing
8.8. SSRC-マルチプレクシングとのSDP記述
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:
↓これは以下の上のただ一つのセッションの例のように同様のパラメタがあるSSRC-マルチプレクシングを使用するRTPビデオセッションのためのSDP記述に関する例です。
Rey, et al. Standards Track [Page 21] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[21ページ]。
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
v=0 o=mascha2980675221 2980675778IN IP4 host.example.net cがIN IP4と等しい、192.0、.2、.0m、=ビデオ49170RTP/AVPF96 97a=rtpmap: 96MP4V-ES/90000a=rtcp-fb: 96nack a=fmtp: 96プロフィールイド=01010000012000884006682C209 8;コンフィグ=%%BODY%%A21F a=rtpmap: 97rtx/90000a=fmtp: 97を平らにしているしやすい=96;rtx3000時間=
9. RTSP Considerations
9. RTSP問題
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.
レアルTime Streamingプロトコル(RTSP)(RFC2326[7])はリアルタイムの特性があるデータの配送のコントロールのためのアプリケーションレベルプロトコルです。 このセクションは「再-トランスミッション」を使用するRTPセッションを制御するのにかかわる問題を見ます。
9.1. RTSP Control with SSRC-Multiplexing
9.1. SSRC-マルチプレクシングとのRTSPコントロール
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「コントロール」属性を持っています。 受信機は、全体のメディアセッションのSETUPとTEARDOWNを要求するのに「m」線を使用します。 Transportヘッダーに含まれたRTPプロフィールは、AVPFプロフィールか拡張フィードバックを許す別の適当なプロフィールであるに違いありません。 SSRC値がSETUP応答のTransportヘッダーに含まれているなら、それは元の流れのものであるに違いありません。
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はセッションのために送付者に要求します。 元の流れのRTP情報によると、RTP特有のパラメタをPLAY応答にはめ込むのに使用されるRTP-インフォメーションヘッダーは用意ができなければなりません。
When the receiver starts receiving the original stream, it can then request retransmission through RTCP NACKs without additional RTSP signalling.
受信機が元の流れを受け始めると、それはRTCP NACKsを通して追加RTSP合図なしで「再-トランスミッション」を要求できます。
9.2. RTSP Control with Session-Multiplexing
9.2. セッションマルチプレクシングとのRTSPコントロール
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意味論を通してオリジナルのセッションと「再-トランスミッション」セッションを関連づけることができます。
Rey, et al. Standards Track [Page 22] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[22ページ]。
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.
それらのそれぞれのメディア「コントロール」属性を通してオリジナルと「再-トランスミッション」小川をセットアップして、別々に取りこわします。 Transportヘッダーに含まれた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プレゼンテーションSHOULDサポートの集合コントロールとSHOULDはセッションレベルRTSP URLを含んでいます。 受信機SHOULDはオリジナルのセッションとその関連「再-トランスミッション」セッションに集合コントロールを使用します。 さもなければ、そこでは、すなわち、2つの異なった'セッションイド'値、オリジナルと「再-トランスミッション」セッションのための異価であることが必要であるだろう、送付者はそれらを関連づける方法を知らないでしょう。
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.
そして、セッションレベル「コントロール」属性は、元の流れのプレーを制御するのにいつものように使用されます。 受信機が元の流れを受け始めると、それはRTCPを通して追加RTSP合図なしで「再-トランスミッション」を要求できます。
9.3. RTSP Control of the Retransmission Stream
9.3. Retransmissionの流れのRTSPコントロール
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.
「再-トランスミッション」の自然制御する、「再-トランスミッション」パケットSHOULD NOTを発信させて、RTSP PLAYとPAUSE要求で制御されてください。 PLAYとPAUSE要求SHOULD NOTは「再-トランスミッション」の流れに影響します。 状態にかかわらず元のRTCPの流れでRetransmissionパケットを受信機要求に送ります。
9.4. Cache Control
9.4. キャッシュ制御
Retransmission streams SHOULD NOT be cached.
RetransmissionはSHOULD NOTを流します。キャッシュされます。
In the case of session-multiplexing, the "Cache-Control" header SHOULD be set to "no-cache" for the retransmission stream.
セッションマルチプレクシングの場合で「「再-トランスミッション」のために「キャッシュしない」セットが流れであったなら」 ヘッダーSHOULDをキャッシュで制御してください。
In the case of SSRC-multiplexing, RTSP cannot specify independent caching for the retransmission stream, because there is a single "m" line in SDP. Therefore, the implementer should take this fact into account when deciding whether or not to cache an SSRC-multiplexed session.
SSRC-マルチプレクシングの場合では、RTSPは「再-トランスミッション」の流れのための独立しているキャッシュを指定できません、ただ一つの「m」線がSDPにあるので。 したがって、SSRCによって多重送信されたセッションをキャッシュするかどうか決めるとき、implementerはこの事実を考慮に入れるはずです。
10. Implementation Examples
10. 実現の例
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.
このドキュメントは相互運用性に必要な送付者と受信機のふるまいだけを強制します。 さらに、速度制御かバッファ管理などの特定の環境で狙うとあるアルゴリズムは「再-トランスミッション」効率を高めるかもしれません。
Rey, et al. Standards Track [Page 23] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[23ページ]。
This section gives an overview of different implementation options allowed within this specification.
このセクションはこの仕様の中に許容された異なった実現オプションの概観を与えます。
The first example describes a minimal receiver implementation. With this implementation, it is possible to retransmit lost RTP packets, detect efficiently the loss of retransmissions, and perform multiple retransmissions, if needed. Most of the necessary processing is done at the server.
最初の例は最小量の受信機実現について説明します。 この実現では、無くなっているRTPパケットを再送して、効率的に「再-トランスミッション」の損失を検出して、複数の「再-トランスミッション」を実行するのは可能です、必要であるなら。 サーバで必要な処理の大部分をします。
The second example shows how retransmissions may be used in (small) multicast groups in conjunction with layered encoding. It illustrates that retransmissions and layered encoding may be complementary techniques.
2番目の例は層にされたコード化に関連して「再-トランスミッション」が(小さい)のマルチキャストグループにどう使用されるかもしれないかを示しています。 「再-トランスミッション」と層にされたコード化が補足的なテクニックであるかもしれないことは例証します。
10.1. A Minimal Receiver Implementation Example
10.1. 最小量の受信機実現の例
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:
このセクションは複数の「再-トランスミッション」を支持する実現に関する例を出します。 送付者は、RTPパケットでMPEG-4ビデオRTPペイロード形式を使用することでオリジナルのデータを送ります。 ナックフィードバックメッセージが[1]に従って使用されると思われます。 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 o=mascha2980675221 2980675778IN IP4 host.example.net cがIN IP4と等しい、192.0、.2、.0m、=ビデオ49170RTP/AVPF96 97a=rtpmap: 96 MP4V-ES/90000a=rtcp-fb: 96 nack a=rtpmap: 97 rtx/90000a=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プロフィール[1]で定義されるようにNACKsを通して無くなっているパケットに送付者に合図します。 受信機が合図された送付者「再-トランスミッション」バッファ長を考慮に入れるはずである、寸法のそれ自身のレセプションバッファ。 また、それがバッファ長にパケットの「再-トランスミッション」を要求できるという回の最大数に由来しているべきです。
Rey, et al. Standards Track [Page 24] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[24ページ]。
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.
送付者は選択的にパケットを再送するべきです。 すなわち、それは、パケットの重要性による要求されたパケット、Service(QoS)の観測されたQuality、およびネットワーク接続の混雑状態を受信機に再送するかどうかを選ぶべきです。明らかに、州の情報と処理がロードされるとき、受信機の数に従った送付者処理増加を各受信機に割り当てなければなりません。
10.2. Retransmission of Layered Encoded Media in Multicast
10.2. マルチキャストにおける層にされたコード化されたメディアのRetransmission
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.
このセクションは、どのようにマルチキャストセッションにおける層にされたコード化に「再-トランスミッション」を結合するかを示します。 「再-トランスミッション」枠組みが小さいマルチキャストアプリケーションのためだけに提供されることに注意してください。 ナックの内部破裂の問題の議論のためのRFC2887[10]を参照してください、フィードバック交通で引き起こされた、厳しい混雑、大きいグループの高信頼のマルチキャストアプリケーションで。
Packets of different importance are sent in different RTP sessions. The retransmission streams corresponding to the different layers can themselves be seen as different retransmission layers. The relative importance of the different retransmission streams should reflect the relative importance of the different original streams.
異なったRTPセッションのときに異なった重要性のパケットを送ります。 「再-トランスミッション」は、自分たちで異なった層の缶に対応しながら、流れます。異なった「再-トランスミッション」層と考えられます。 異なった「再-トランスミッション」の流れの相対的な重要性は異なった元の流れの相対的な重要性を反映するべきです。
In multicast, SSRC-multiplexing of the original and retransmission streams is not allowed as per Section 5.3 of this document. For this reason, the retransmission stream(s) MUST be sent in different RTP session(s) using session-multiplexing.
マルチキャストでは、このドキュメントのセクション5.3に従ってオリジナルと「再-トランスミッション」の流れのSSRC-マルチプレクシングは許容されていません。 この理由で、セッションマルチプレクシングを使用して、異なったRTPセッションのときに「再-トランスミッション」小川を送らなければなりません。
An SDP description example of multicast retransmissions for layered encoded media is given below:
層にされたコード化されたメディアのためのマルチキャスト「再-トランスミッション」に関するSDP記述の例は以下に出されます:
m=video 8000 RTP/AVPF 98 c=IN IP4 224.2.1.0/127/3 a=rtpmap:98 MP4V-ES/90000 a=rtcp-fb:98 nack m=video 8000 RTP/AVPF 99 c=IN IP4 224.2.1.3/127/3 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98;rtx-time=3000
mがビデオ8000RTP/AVPFと等しい、98、c、= IN IP4 224.2.1.0/127/3a=rtpmap: 98MP4V-ES/90000a=rtcp-fb: 98nack mがビデオ8000RTP/AVPFと等しい、99、c、=IN IP4 224.2.1.3/127/3a=rtpmap: 99 rtx/90000a=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.
サーバと受信機は前の例で例証された「再-トランスミッション」方法を実行するかもしれません。 さらに、彼らは、それが属す層による無くなっているパケットを要求して、再送するのを選ぶかもしれません。
Rey, et al. Standards Track [Page 25] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[25ページ]。
11. IANA Considerations
11. IANA問題
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.
4つの異なったメディアタイプのために以下の通り新しいMIME「副-タイプ」名"rtx"を登録してあります: 「ビデオ」、「オーディオ」、「テキスト」、および「アプリケーション。」 追加REQUIREDパラメタ、「しやすい」、そして、およびOPTIONALパラメタ、「rtx-時間」は定義されます。 詳細に関してセクション8を見てください。
12. Security Considerations
12. セキュリティ問題
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 retransmissionに、反射攻撃は非常に有害である場合があります)。 例えば: いじられたRTCPパケットは事実上、元のデータ・ストリームに割り当てられた実際のbitrateシェアを下げる不適当な「再-トランスミッション」の引き金となるかもしれません、そして、クライアントのデコーダはいじられたRTP retransmissionパケットでクラッシュできました、そして、いじられた「再-トランスミッション」要求はこのドキュメントのセクション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.
その上、このペイロード形式に使用される暗号メカニズムが知られている平文攻撃に対する保護を提供するのは、RECOMMENDEDです。 RTPは、初期のRTPタイムスタンプSHOULDが知られている平文攻撃に対して流れを保証するために無作為であることを推薦します。 初期のタイムスタンプが最初の再送されたパケットに関するメディアタイムスタンプになるので、このペイロード形式はこの推薦に続きません。 しかしながら、元の流れがコード化されているなら元の流れの初期のタイムスタンプがそれ自体で無作為であるので、また、攻撃者にとって、最初の再送されたパケットタイムスタンプも無作為でしょう。 したがって、秘密性は妥協しないでしょう。
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
元の流れのときにセキュリティー・サービスを提供するのに暗号を使用するなら、「再-トランスミッション」の流れのときに同等な暗号の強さに同じサービスを提供しなければなりません。 使用
Rey, et al. Standards Track [Page 26] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[26ページ]。
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.
再送された流れと元の流れのための同じキーは警備上の問題、例えば、二度のパッドに通じるかもしれません。 議論のためのSecureレアル-時間Transportプロトコル(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人の発生) このペイロード形式が通常RTP/AVPFプロフィールにもかかわらず、SRTPの下で働くという事実はRTP/AVPを支持するだけです。 SRTPの適合している異形は将来、これらの短所を解決するものとします。
Congestion control considerations with the use of retransmission are dealt with in Section 7 of this document.
「再-トランスミッション」の使用がある輻輳制御問題はこのドキュメントのセクション7で対処されています。
13. Acknowledgements
13. 承認
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.
このドキュメントの開発への彼の参加のためにカルステン・バーマイスターに感謝したいと思います。 また、私たちの感謝は彼らの役に立つコメントにKoichi波田、コリン・パーキンス、スティーブンCasner、マグヌスWesterlund、Go Hori、およびRahul Agarwalに行きます。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[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] オット、J.、ウェンガー、S.、佐藤、N.、バーマイスター、C.、およびJ.レイは「レアル-時間Transport Controlプロトコル(RTCP)のベースのフィードバックのためにRTPプロフィールを広げました」、RFC4585、2006年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[4]Casner、S.、「RTP制御プロトコル(RTCP)帯域幅へのセッション記述プロトコル(SDP)帯域幅修飾語」、RFC3556、2003年7月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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)で立ち並んでいます」、RFC3388、2002年12月。
Rey, et al. Standards Track [Page 27] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[27ページ]。
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[7]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
14.2. Informative References
14.2. 有益な参照
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[8] パーキンスとC.とO.ホドソン、「ストリーミング・メディアの修理のためのオプション」、RFC2354、1998年6月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[9] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、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.、カーモード、R.、Vicisano、L.、およびM.Luby、「バルク・データ転送のための信頼できるマルチキャストデザインスペース」、RFC2887(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)」、RFC3611 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.
2004年の[12]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Rey, et al. Standards Track [Page 28] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[28ページ]。
Appendix A. How to Control the Number of Rtxs. per Packet
付録、A. どうRtxsの数を制御するか、パケット
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.
可能な限り良いトランスミッションを達成するために1パケットあたりの「再-トランスミッション」(rtxs)の数を見つけるのは、厄介な問題です。 もちろん、絶対最小値は1つ(1)であるべきである。 さもなければ、このペイロード形式を使用しないでください。 そのうえ、公表の日付の時点で、作者は1最も良い性能に使用されるべきであるパケットあたりの「再-トランスミッション」の数に関するどんな研究も意識していませんでした。 この項目の上でimplementersと研究者を助けるために、このセクションは時間が「再-トランスミッション」の与えられた数を達成するために必要としたバッファリングの見積りについて説明します。 今回がいったん計算されると、「rtx-時間」というSDPパラメタでそれをクライアントに伝えることができます、本書では定義されるように。
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.
* SSRC-マルチプレクシング「再-トランスミッション」計画と共に使用されるRTP AVPFプロフィール: 1 オリジナルのパケットのためのSSRC、「再-トランスミッション」パケットのための1。
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR = 0.05.
We have senders (2) and receivers (1). Receivers and senders get
equally 1/3 of the RTCP bandwidth share because the proportion of
senders is greater than 1/4 of session members.
* SRsとすなわち、RRs、SR+RRのためのデフォルトRTCP帯域幅シェアは0.05と等しいです。 私たちは送付者(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.
* avg-rtcp-サイズは120バイト近似されています。 これは2SRsの切り上げている平均です、各SSRCあたり1つ、CNAMEと共にIPv6/UDP/SR/SDESのための40/8/28/32バイトを含んでいて、その結果、105バイトをそれぞれにします。 そして、157バイトを作るIPv6/UDP/2*RR/SDESのための40/8/64/32バイトがあるRR。 送付者と受信機が等しくRTCP帯域幅を共有するので、そして、avg-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]です、そして、Generic NACKsは、「再-トランスミッション」を要求するのに使用されます。 これは1のために16バイトのオーバーヘッドをさらに各追加ナックFeedback Control Information(FCI)分野あたりナックと4バイト加えます。
* We assume a worst-case scenario in which each packet exhausts its
corresponding number of available retransmissions, N, before it is
received. This means that if a packet is requested for
retransmission a maximum of 2 times, the corresponding generic NACK
report block requesting that particular packet is sent in two
* 私たちは利用可能な「再-トランスミッション」の対応する番号が各パケットでくたくたになる最悪の事態のシナリオを仮定します、N、それが受け取られている前に。 これは、パケットが「再-トランスミッション」のために最大2回要求されるなら、その特定のパケットを要求する対応する一般的なナックレポートブロックが2で送られることを意味します。
Rey, et al. Standards Track [Page 29] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[29ページ]。
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.
連続したRTCP化合物。 同様に、「再-トランスミッション」のために10回それを要求するなら、10回を一般的なナックに送ります。 この仮定で、RTCPパケットサイズはすなわち、N*RTCP間隔(秒)の後にavg-rtcp-サイズ=120+ (RTCP-bwが共有する受信機)*(12+4*N)にほとんど一定になります。 私たちの場合では、受信機RTCP帯域幅シェアは1/3です。 124+4その結果、avg-rtcp-サイズ=*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つの遅れパラメタが、近似するのが難しく、実現に依存しているかもしれません。 したがって、特定の値をそれらに割り当てないで、私たちはここに明らかにそれらを記載します: もう片方が、「再-トランスミッション」(T5)のための1つはパケット損失検出時間(T2)であり、フィードバック処理と列を作り時間です。 Implementersはこれらの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
送付者、++---------------------------------^-----\----------------- \ \ / \ \ \ | | 'SN=0\\SN=1/\RTX(SN=0)\\/\X\/\'/\\/\\| | \ / \ ...... \ / \ -------------V----D--------/-----------------------V-------- T1 T2 T3 T4 T5 T1… 受信機
Legend: ======= DL: downlink (client->server) UL: uplink (server->client) Time unit is seconds, s. Bitrate unit is bits per second, bps.
伝説: ======= dl: ダウンリンク、(クライアント->、サーバ、)、UL: アップリンク、(サーバ->、クライアント、)、タイム・ユニットは秒、sです。 Bitrateユニットはbps、ビーピーエスです。
DL transmission time: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
DLトランスミッション時間: T1はinterarrival遅れtx遅れ物理的な遅れDL+DL(avg-pkt-サイズ/DL-bitrateと等しい)+ジターと等しいです。
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を遅らせている+interarrival遅れ物理的な遅れUL+ジターと等しいです。
Rey, et al. Standards Track [Page 30] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[30ページ]。
Retransmissions processing time: T5 = feedback-processing-time +
rtx-queuing-time
Retransmissions処理時間: 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()の見積りにわかるために、N.This時間はサーバにおいてクライアントでほとんど等しいです、人が、クライアントが、何秒も後に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の最大の無作為化要素が適用されていると思うということでしょう。 したがって、その後の補償を適用した後に、交通を避けるのははち切れます。(私たちには、RTP[3])のAppendix A.7を見てください、そして、そのT3=1.5/1.21828*RTCP-間隔があります。 このようにして
T = RTT + 1.2312*RTCP-Interval + T2 + T5
T=1.2312*RTCP RTT+間隔+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-間隔はavg-rtcpサイズ*8*(送付者+受信機)/(RR+RS)と等しいです。 このシナリオで: 送付者+受信機=3。 RR+RSは受信機レポートであり、この場合、デフォルトと等しい送付者レポート帯域幅シェアは5%のセッション帯域幅(bw)です。 私たちは、平均したRTCPがパケットサイズ、avg-rtcp-サイズであると= 120バイト思います。 このようにして:
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
Tは1.2312*avg-rtcp RTT+サイズ*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*avg-rtcpサイズ*8*3/(0.05*bw)+T2+T5)
Rey, et al. Standards Track [Page 31] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[31ページ]。
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.
124+4avg-rtcp-サイズ=120+(受信機RTCP-bwは共有しています)の*(12+4*N)=120+(1/3)*(12+4*N)=*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
数個のGeneric NACKsとRTCP。 124+4*N/3可変パケットサイズ=バイト
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
|============|=====|======================================| | RTP BW| RTT| N値| |============|=====| 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
Rey, et al. Standards Track [Page 32] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[32ページ]。
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.
Generic NACKSを考慮に入れない誤りを定量化するために、私たちは同じ数(120Genericナックの貢献、avg-rtcp-サイズ~、を無視するだけの=バイト)ができます。 私たちが下から見るように、これは「再-トランスミッション」の下側の帯域幅値と、より大きい数のための1-1.5秒(5-10%)のバッファ見積り誤りをもたらすかもしれません。 この効果はこの場合低いです。 それにもかかわらず、それは特定のシナリオのために慎重に評価されるべきです。 それは公式がそれを含む理由です。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
120固定パケットサイズ~=バイトのGenericナックのいないRTCP
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
|============|=====|======================================| | RTP BW| RTT| N値| |============|=====| 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
Rey, et al. Standards Track [Page 33] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[33ページ]。
Authors' Addresses
作者のアドレス
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセレイパナソニック研究開発センタードイツ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 Fax: +49-6103-766-166 メールしてください: 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
Akihiro宮崎松下電器産業社、Ltd1006、門真、門真市、大阪、日本
Phone: +81-6-6900-9172 Fax: +81-6-6900-9173 EMail: miyazaki.akihiro@jp.panasonic.com
以下に電話をしてください。 +81-6-6900-9172 Fax: +81-6-6900-9173 メールしてください: miyazaki.akihiro@jp.panasonic.com
Viktor Varsa Nokia Research Center 6000 Connection Drive Irving, TX. USA
ビクトールVarsaノキアResearch Center6000接続Driveアービング(テキサス)。 米国
Phone: 1-972-374-1861 EMail: viktor.varsa@nokia.com
以下に電話をしてください。 1-972-374-1861 メールしてください: viktor.varsa@nokia.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ロルフHakenbergパナソニック研究開発センタードイツ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 Fax: +49-6103-766-166 メールしてください: rolf.hakenberg@eu.panasonic.com
Rey, et al. Standards Track [Page 34] RFC 4588 RTP Retransmission Payload Format July 2006
レイ、他 規格はRTP Retransmission有効搭載量形式2006年7月にRFC4588を追跡します[34ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rey, et al. Standards Track [Page 35]
レイ、他 標準化過程[35ページ]
一覧
スポンサーリンク
