RFC 6682 - RTP Payload Format for Raptor Forward Error Correction (FEC) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6682
タイトル : RFC 6682 - Raptor Forward Error Correction（FEC）のRTPペイロード形式
翻訳編集 : 自動生成

[要約] RFC 6682は、Raptor Forward Error Correction（FEC）のためのRTPペイロード形式に関する規格です。このRFCの目的は、RTPストリームのエラー訂正を向上させるために、Raptor FECスキームを使用する方法を提供することです。

Internet Engineering Task Force (IETF)                         M. Watson
Request for Comments: 6682                                       Netflix
Category: Standards Track                                 T. Stockhammer
ISSN: 2070-1721                                           Nomor Research
                                                                 M. Luby
                                                   Qualcomm Incorporated
                                                             August 2012

RTP Payload Format for Raptor Forward Error Correction (FEC)

Raptor Forward Error Correction（FEC）のRTPペイロード形式

Abstract

概要

This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows.

このドキュメントでは、Raptor FECスキームによって生成されるForward Error Correction（FEC）修復データのRTPペイロード形式を指定します。 Raptor FECスキームは、UDPとRTPの両方を介した修復データの転送をサポートするIETF FECフレームワークで使用するために指定されています。このドキュメントでは、RTPを使用してRaptor修復フローを伝送するために必要なペイロード形式を指定しています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6682.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6682で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
   2. Conventions, Definitions, and Acronyms ..........................3
   3. Media Format Background .........................................3
   4. Payload Format for FEC Repair Packets ...........................4
      4.1. RTP Header Usage ...........................................4
      4.2. Payload Header .............................................5
      4.3. Payload Data ...............................................5
   5. Congestion Control Considerations ...............................5
   6. Media Types .....................................................5
      6.1. Registration of the 'application/raptorfec' Media Type .....5
           6.1.1. Media Type Definition ...............................5
      6.2. Registration of the 'video/raptorfec' Media Type ...........7
           6.2.1. Media Type Definition ...............................7
      6.3. Registration of the 'audio/raptorfec' Media Type ...........8
           6.3.1. Media Type Definition ...............................8
      6.4. Registration of the 'text/raptorfec' Media Type ...........10
           6.4.1. Media Type Definition ..............................10
   7. Mapping to the Session Description Protocol (SDP) ..............12
   8. Offer/Answer Considerations ....................................12
   9. Declarative SDP Considerations .................................13
   10. Repair Flow Generation and Recovery Procedures ................13
      10.1. Overview .................................................13
      10.2. Repair Packet Construction ...............................14
      10.3. Usage of RTCP ............................................14
      10.4. Source Packet Reconstruction .............................14
   11. Session Description Protocol (SDP) Example ....................14
   12. IANA Considerations ...........................................15
   13. Security Considerations .......................................15
   14. References ....................................................16
      14.1. Normative References .....................................16
      14.2. Informative References ...................................17

1. Introduction

1. はじめに

The FEC Framework [RFC6363] defines a general framework for the use of Forward Error Correction in association with arbitrary packet flows, including flows over UDP and RTP [RFC3550]. Forward Error Correction operates by generating redundant data packets ("repair data") that can be sent independently from the original flow. At a receiver, the original flow can be reconstructed provided a sufficient set of redundant data packets and possibly original data packets are received.

FECフレームワーク[RFC6363]は、UDPおよびRTP [RFC3550]を介したフローを含む、任意のパケットフローに関連する転送エラー訂正の使用のための一般的なフレームワークを定義します。前方誤り訂正は、元のフローとは独立して送信できる冗長データパケット（「修復データ」）を生成することによって動作します。受信機では、冗長データパケットの十分なセットと、場合によっては元のデータパケットが受信されれば、元のフローを再構築できます。

The FEC Framework provides for independence between application protocols and FEC codes. The use of a particular FEC code within the framework is defined by means of a FEC Scheme, which may then be used with any application protocol compliant to the framework.

FECフレームワークは、アプリケーションプロトコルとFECコード間の独立性を提供します。フレームワーク内での特定のFECコードの使用は、FECスキームによって定義されます。これは、フレームワークに準拠するアプリケーションプロトコルで使用できます。

Repair data flows may be sent directly over a transport protocol, such as UDP, or they may be encapsulated within specialized transports for multimedia, such as RTP.

修復データフローは、UDPなどのトランスポートプロトコルを介して直接送信することも、RTPなどのマルチメディア専用のトランスポート内にカプセル化することもできます。

This document defines the RTP payload format for the Raptor FEC Schemes defined in [RFC6681].

このドキュメントでは、[RFC6681]で定義されているRaptor FECスキームのRTPペイロード形式を定義しています。

2. Conventions, Definitions, and Acronyms

2. 表記法、定義、および頭字語

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Media Format Background

3. メディア形式の背景

The Raptor and RaptorQ codes are efficient block-based fountain codes, meaning that from any group of source packets (or 'source block'), one can generate an arbitrary number of repair packets. The Raptor and RaptorQ codes have the property that the original group of source symbols can be recovered with a very high probability from any set of symbols (source and repair) only slightly greater in number than the original number of source symbols. The RaptorQ code additionally has the property that the probability that the original group of source symbols can be recovered from a set of symbols (source and repair) equal in number to the original number of source symbols is in many cases also very high.

RaptorおよびRaptorQコードは、効率的なブロックベースのファウンテンコードです。つまり、任意のグループのソースパケット（または「ソースブロック」）から、任意の数の修復パケットを生成できます。 RaptorコードとRaptorQコードには、元のソースシンボルの数よりもわずかに多い数のシンボル（ソースと修復）のセットから、元のソースシンボルのグループを非常に高い確率で復元できるという特性があります。さらに、RaptorQコードには、元のソースシンボルの数と同じ数のシンボル（ソースと修復）のセットから元のソースシンボルのグループを復元できる確率が非常に高いという特性もあります。

[RFC6681] defines six FEC Schemes for the use of the Raptor and RaptorQ codes with arbitrary packet flows. The first two schemes are fully applicable to arbitrary packet flows (using Raptor and RaptorQ respectively). The third and fourth schemes are slightly optimized versions of the first two schemes, which are applicable in applications with relatively small block sizes. The fifth and sixth schemes are variants of the third and fourth schemes, which are applicable to a single source flow that already has some kind of identifiable sequence number. The presence of a sequence number in the source flow allows for backwards-compatible operation (the source flows do not need to be modified in order to apply FEC). In this case, in the language of the FEC Framework, there is no need for an explicit FEC Source Payload ID; therefore, it is not included in the packets.

[RFC6681]は、任意のパケットフローでRaptorおよびRaptorQコードを使用するための6つのFECスキームを定義しています。最初の2つのスキームは、任意のパケットフローに完全に適用できます（それぞれRaptorおよびRaptorQを使用）。 3番目と4番目のスキームは、最初の2つのスキームのわずかに最適化されたバージョンであり、ブロックサイズが比較的小さいアプリケーションに適用できます。 5番目と6番目のスキームは、3番目と4番目のスキームのバリアントです。これは、ある種の識別可能なシーケンス番号がすでにある単一のソースフローに適用できます。ソースフローにシーケンス番号が存在すると、下位互換性のある操作が可能になります（FECを適用するためにソースフローを変更する必要はありません）。この場合、FECフレームワークの言語では、明示的なFECソースペイロードIDは必要ありません。したがって、パケットには含まれません。

This document specifies the payload format for RTP repair flows and can be used with any of the FEC Schemes defined in [RFC6681].

このドキュメントは、RTP修復フローのペイロード形式を指定し、[RFC6681]で定義されている任意のFECスキームで使用できます。

4. Payload Format for FEC Repair Packets

4. FEC修理パケットのペイロード形式

4.1. RTP Header Usage

4.1. RTPヘッダーの使用

Header fields SHALL be set according to the rules of [RFC3550]. In addition, the following rules and definitions apply for the RTP headers used with FEC repair packets:

ヘッダーフィールドは[RFC3550]のルールに従って設定されるべきです[SHALL]。さらに、FEC修復パケットで使用されるRTPヘッダーには、次のルールと定義が適用されます。

o Marker bit: The marker bit SHALL be set to 1 for the last protection RTP packet sent for each source block, and otherwise set to 0.

o マーカービット：各ソースブロックに対して送信された最後の保護RTPパケットに対してマーカービットを1に設定する必要があります（SHALL）。それ以外の場合は0に設定します。

o Payload Type (PT): The payload type codes SHALL be assigned dynamically through non-RTP means. If the Session Description Protocol (SDP) is used for signaling, the rules in Section 7 apply.

o ペイロードタイプ（PT）：ペイロードタイプコードは、RTP以外の方法で動的に割り当てる必要があります。シグナリングにセッション記述プロトコル（SDP）が使用されている場合、セクション7のルールが適用されます。

o Timestamp: This field contains the time at which the packet is transmitted. The time SHOULD be as close as possible to the packet's actual time of transmission. The timestamp value has no use in the actual FEC protection process. However, implementations SHOULD supply a value that can be used for packet-arrival timing or jitter calculations. The timestamp rate is specified using the "rate" media type parameter defined in Section 6. The operator SHALL select a "rate" larger than 1000 Hz to provide sufficient resolution to the Real-Time Transport Control Protocol (RTCP) operations, and the operator SHOULD select the rate that matches the rate of the protected source RTP stream.

o タイムスタンプ：このフィールドには、パケットが送信された時刻が含まれます。時間は、パケットの実際の送信時間に可能な限り近くする必要があります。タイムスタンプ値は、実際のFEC保護プロセスでは使用されません。ただし、実装では、パケット到着タイミングまたはジッターの計算に使用できる値を提供する必要があります（SHOULD）。タイムスタンプレートは、セクション6で定義された「レート」メディアタイプパラメータを使用して指定されます。オペレータは、リアルタイムトランスポートコントロールプロトコル（RTCP）操作に十分な解像度を提供するために、1000 Hzより大きい「レート」を選択する必要があります。保護されたソースRTPストリームのレートと一致するレートを選択する必要があります。

o Synchronization Source (SSRC): The SSRC values MUST be set according to [RFC3550]. The SSRC value of the RTP repair flow MUST be different from the SSRC value of the protected source flow.

o 同期ソース（SSRC）：SSRC値は[RFC3550]に従って設定する必要があります。 RTP修復フローのSSRC値は、保護されたソースフローのSSRC値とは異なる必要があります。

4.2. Payload Header

4.2. ペイロードヘッダー

There is no payload header in this payload format.

このペイロード形式のペイロードヘッダーはありません。

4.3. Payload Data

4.3. ペイロードデータ

Procedures and data formats for the use of Raptor Forward Error Correction in a FECFRAME context are fully defined in [RFC6363] and [RFC6681] and are not duplicated here. The procedures of those documents apply in order to generate repair data streams to be carried by the payload formats defined in this document.

FECFRAMEコンテキストでRaptor Forward Error Correctionを使用するための手順とデータ形式は、[RFC6363]と[RFC6681]で完全に定義されており、ここでは重複していません。これらのドキュメントの手順は、このドキュメントで定義されているペイロード形式で伝送される修復データストリームを生成するために適用されます。

The RTP Payload SHALL contain a Repair FEC Payload ID as defined in [RFC6363] and [RFC6681].

RTPペイロードには、[RFC6363]と[RFC6681]で定義されている修復FECペイロードIDが含まれている必要があります（SHALL）。

5. Congestion Control Considerations

5. 輻輳制御に関する考慮事項

See [RFC6363].

[RFC6363]を参照してください。

6. Media Types

6. メディアタイプ

6.1. Registration of the 'application/raptorfec' Media Type

6.1. 「application / raptorfec」メディアタイプの登録

This RTP payload format is identified using the 'application/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].

このRTPペイロード形式は、[RFC4855]に従って登録され、[RFC4288]のテンプレートを使用する「application / raptorfec」メディアタイプを使用して識別されます。

6.1.1. Media Type Definition

6.1.1. メディアタイプの定義

Type name: application

タイプ名：アプリケーション

Subtype name: raptorfec

サブタイプ名：raptorfec

Required parameters:

必須パラメーター：

o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.

o rate：RTPタイムスタンプ（クロック）レート。 RTPタイムスタンプ（クロック）レートはHzで指定され、形式は符号なし整数です。

o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].

o raptor-scheme-id：このパラメーターの値は、[RFC6681]で定義されているように使用される特定のRaptor FECスキームのFECスキームIDです。

o Kmax: The value of this parameter is the FEC Framework Configuration Information element, Maximum Source Block Length (MSBL), as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].

o Kmax：このパラメーターの値は、[RFC6681]で定義されているFECフレームワーク構成情報要素の最大ソースブロック長（MSBL）であり、符号なし整数としてエンコードされます。この値の特定の要件については、[RFC6681]を参照してください。

o T: The value of this parameter is the FEC Framework Configuration Information element, encoding symbol size, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].

o T：このパラメーターの値は、[RFC6681]で定義されている、符号なし整数としてエンコードされた、FECフレームワーク構成情報要素、エンコードシンボルサイズです。この値の特定の要件については、[RFC6681]を参照してください。

o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.

o repair-window：ソースパケットと対応する修復パケットにまたがる最大時間。修復ウィンドウのサイズはマイクロ秒で指定され、形式は符号なし整数です。

Optional parameters:

オプションのパラメーター：

o P: The value of this parameter is the FEC Framework Configuration Information element, Payload ID Format, as defined in [RFC6681]. The default value of this parameter (when it does not appear explicitly) is 'A'.

o P：このパラメーターの値は、[RFC6681]で定義されているFECフレームワーク構成情報要素、ペイロードID形式です。このパラメーターのデフォルト値（明示的に表示されない場合）は「A」です。

Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288]

エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください

Security considerations: Please see the security considerations in [RFC6363].

セキュリティに関する考慮事項：[RFC6363]のセキュリティに関する考慮事項を参照してください。

Interoperability considerations:

相互運用性に関する考慮事項：

Published specification: [RFC6681]

公開された仕様：[RFC6681]

Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.

このメディアタイプを使用するアプリケーション：ビデオストリーミング、オーディオストリーミング、ビデオ会議などのリアルタイムマルチメディアアプリケーション。

Additional information:

追加情報：

   Magic number(s): <none defined>

   File extension(s): <none defined>

   Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de

詳細について連絡する人とメールアドレス：Thomas Stockhammer、stockhammer @ nomor.de

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.

使用制限：このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。

Author: Thomas Stockhammer, Nomor Research Change controller: IETF PAYLOAD working group delegated from the IESG.

著者：Thomas Stockhammer、Nomor Research Changeコントローラー：IESGから委任されたIETF PAYLOADワーキンググループ。

6.2. Registration of the 'video/raptorfec' Media Type

6.2. 「video / raptorfec」メディアタイプの登録

This RTP payload format is identified using the 'video/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].

このRTPペイロード形式は、[RFC4855]に従って登録され、[RFC4288]のテンプレートを使用する「video / raptorfec」メディアタイプを使用して識別されます。

6.2.1. Media Type Definition

6.2.1. メディアタイプの定義

Type name: video

タイプ名：ビデオ

Subtype name: raptorfec

サブタイプ名：raptorfec

Required parameters:

必須パラメーター：

o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.

o rate：RTPタイムスタンプ（クロック）レート。 RTPタイムスタンプ（クロック）レートはHzで指定され、形式は符号なし整数です。

o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].

o raptor-scheme-id：このパラメーターの値は、[RFC6681]で定義されているように使用される特定のRaptor FECスキームのFECスキームIDです。

o Kmax: The value of this parameter is the FEC Framework Configuration Information element, MSBL, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].

o Kmax：このパラメーターの値は、[RFC6681]で定義されているFECフレームワーク構成情報要素MSBLであり、符号なし整数としてエンコードされます。この値の特定の要件については、[RFC6681]を参照してください。

o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds, and the format is unsigned integer.

Optional parameters:

オプションのパラメーター：

Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].

エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください。

Security considerations: Please see the security considerations in [RFC6363].

セキュリティに関する考慮事項：[RFC6363]のセキュリティに関する考慮事項を参照してください。

Interoperability considerations:

相互運用性に関する考慮事項：

Published specification: [RFC6681]

公開された仕様：[RFC6681]

Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.

Additional information:

追加情報：

   Magic number(s): <none defined>

   File extension(s): <none defined>

   Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de

詳細について連絡する人とメールアドレス：Thomas Stockhammer、stockhammer @ nomor.de

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

著者：トーマス・ストックハンマー、Nomor Research。

Change controller: IETF PAYLOAD working group delegated from the IESG.

コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。

6.3. Registration of the 'audio/raptorfec' Media Type

6.3. 「audio / raptorfec」メディアタイプの登録

This RTP payload format is identified using the 'audio/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].

このRTPペイロード形式は、[RFC4855]に従って登録され、[RFC4288]のテンプレートを使用する「audio / raptorfec」メディアタイプを使用して識別されます。

6.3.1. Media Type Definition

6.3.1. メディアタイプの定義

Type name: audio

タイプ名：オーディオ

Subtype name: raptorfec Required parameters:

サブタイプ名：raptorfec必須パラメーター：

o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.

o rate：RTPタイムスタンプ（クロック）レート。 RTPタイムスタンプ（クロック）レートはHzで指定され、形式は符号なし整数です。

o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].

o raptor-scheme-id：このパラメーターの値は、[RFC6681]で定義されているように使用される特定のRaptor FECスキームのFECスキームIDです。

o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.

Optional parameters:

オプションのパラメーター：

Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].

エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください。

Security considerations: Please see the security considerations in [RFC6363].

セキュリティに関する考慮事項：[RFC6363]のセキュリティに関する考慮事項を参照してください。

Interoperability considerations:

相互運用性に関する考慮事項：

Published specification: [RFC6681]

公開された仕様：[RFC6681]

Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.

Additional information:

追加情報：

   Magic number(s): <none defined>
   File extension(s): <none defined>

   Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de

詳細について連絡する人とメールアドレス：Thomas Stockhammer、stockhammer @ nomor.de

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

著者：トーマス・ストックハンマー、Nomor Research。

Change controller: IETF PAYLOAD working group delegated from the IESG.

コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。

6.4. Registration of the 'text/raptorfec' Media Type

6.4. 「text / raptorfec」メディアタイプの登録

This RTP payload format is identified using the 'text/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].

このRTPペイロード形式は、[RFC4855]に従って登録され、[RFC4288]のテンプレートを使用する「text / raptorfec」メディアタイプを使用して識別されます。

6.4.1. Media Type Definition

6.4.1. メディアタイプの定義

Type name: text

タイプ名：テキスト

Subtype name: raptorfec

サブタイプ名：raptorfec

Required parameters:

必須パラメーター：

o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.

o rate：RTPタイムスタンプ（クロック）レート。 RTPタイムスタンプ（クロック）レートはHzで指定され、形式は符号なし整数です。

o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].

o raptor-scheme-id：このパラメーターの値は、[RFC6681]で定義されているように使用される特定のRaptor FECスキームのFECスキームIDです。

o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.

Optional parameters:

オプションのパラメーター：

Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].

エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください。

Security considerations: Please see the security considerations in [RFC6363].

セキュリティに関する考慮事項：[RFC6363]のセキュリティに関する考慮事項を参照してください。

Interoperability considerations:

相互運用性に関する考慮事項：

Published specification: [RFC6681]

公開された仕様：[RFC6681]

Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.

Additional information:

追加情報：

   Magic number(s): <none defined>

   File extension(s): <none defined>

   Macintosh file type code(s): <none defined>

Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de

詳細について連絡する人とメールアドレス：Thomas Stockhammer、stockhammer @ nomor.de

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

著者：トーマス・ストックハンマー、Nomor Research。

Change controller: IETF PAYLOAD working group delegated from the IESG.

コントローラの変更：IESGから委任されたIETF PAYLOADワーキンググループ。

7. Mapping to the Session Description Protocol (SDP)

7. セッション記述プロトコル（SDP）へのマッピング

Applications that are using RTP transport commonly use the Session Description Protocol (SDP) [RFC4566] to describe their RTP sessions. The information that is used to specify the media types in an RTP session has specific mappings to the fields in an SDP description. Note that if an application does not use SDP to describe the RTP sessions, an appropriate mapping must be defined and used to specify the media types and their parameters for the control/description protocol employed by the application.

RTPトランスポートを使用しているアプリケーションは、通常、Session Description Protocol（SDP）[RFC4566]を使用して、RTPセッションを記述します。 RTPセッションでメディアタイプを指定するために使用される情報には、SDP記述のフィールドへの特定のマッピングがあります。アプリケーションがSDPを使用してRTPセッションを記述しない場合は、適切なマッピングを定義して使用し、アプリケーションが使用する制御/記述プロトコルのメディアタイプとそのパラメーターを指定する必要があります。

The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of [RFC4855], following the suggestion therein regarding the mapping of payload-format-specific parameters into the "a=fmtp" field.

上記で定義されたペイロード形式のメディアタイプとそのパラメータのマッピングは、[RFC4855]のセクション3に従って、ペイロード形式固有のパラメータの「a = fmtp」フィールドへのマッピングに関する提案に従って行われる必要があります。

When the RTP payload formats defined in this document are used, the media type parameters defined above MUST use the media types in this document and MUST NOT use those specified in [RFC6364].

このドキュメントで定義されているRTPペイロード形式が使用される場合、上で定義されたメディアタイプパラメータはこのドキュメントのメディアタイプを使用しなければならず（MUST）、[RFC6364]で指定されているものを使用してはならない（MUST NOT）。

8. Offer/Answer Considerations

8. オファー/アンサーの考慮事項

When offering Raptor FEC over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply:

オファー/アンサーモデル[RFC3264]でSDPを使用してRTP over RTPでRaptor FECを提供する場合、次の考慮事項が適用されます。

o Each combination of the Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender application MAY desire to provide multiple offers with different sets of Kmax and T values, which is possible as long as the parameter values are valid. The receiver SHOULD normally choose the offer with the largest value of the product of Kmax and T that it supports.

o KmaxパラメーターとTパラメーターの組み合わせごとに異なるFECデータが生成され、他の組み合わせとは互換性がありません。送信側アプリケーションは、パラメーター値が有効である限り可能である、KmaxおよびT値の異なるセットを使用して複数のオファーを提供することを望む場合があります。レシーバーは通常、サポートするKmaxとTの積の最大値を持つオファーを選択する必要があります（SHOULD）。

o The size of the repair window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side and the receiver must consider this when choosing an offer.

o 修復ウィンドウのサイズは、ソースパケットの送信と関連する修復パケットの送信との間の最大遅延に関連しています。これはレシーバー側のバッファリング要件に直接影響し、オファーを選択する際にレシーバーはこれを考慮する必要があります。

o When the P parameter is not present, the receiver MUST use FEC Payload ID Format A. In an answer that selects an offer in which the P parameter was omitted, the P parameter MUST either be omitted, or included with value "A".

o Pパラメータが存在しない場合、受信者はFEC Payload ID Format Aを使用する必要があります。Pパラメータが省略されたオファーを選択する回答では、Pパラメータは省略されるか、値「A」とともに含まれる必要があります。

9. Declarative SDP Considerations

9. 宣言的なSDPの考慮事項

In declarative usage, like SDP in the Real-Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], the following considerations apply:

Real-Time Streaming Protocol（RTSP）[RFC2326]またはSession Announcement Protocol（SAP）[RFC2974]のSDPのような宣言的な使用法では、次の考慮事項が適用されます。

o The payload format configuration parameters are all declarative and a participant MUST use the configuration that is provided for the session.

o ペイロード形式の構成パラメーターはすべて宣言型であり、参加者はセッションに提供される構成を使用する必要があります。

o More than one configuration MAY be provided (if desired) by declaring multiple RTP payload types. In this case, the receivers should choose the repair session that is best for them.

o 複数のRTPペイロードタイプを宣言することにより、（必要に応じて）複数の構成を提供できます（MAY）。この場合、受信者は自分に最適な修復セッションを選択する必要があります。

10. Repair Flow Generation and Recovery Procedures

10. 修復フローの生成と回復手順

10.1. Overview

10.1. 概観

This document only specifies repair flow construction when the repair packets are delivered with RTP. Source packet construction is covered in [RFC6681]. This section provides an overview on how to generate a repair flow, including the repair packets and how to reconstruct missing source packets from a set of available source and repair packets. Detailed algorithms for the generation of Raptor and RaptorQ symbols are provided in [RFC5053] and [RFC6330], respectively.

このドキュメントでは、修復パケットがRTPで配信される場合の修復フローの構築のみを指定しています。ソースパケットの構築は[RFC6681]でカバーされています。このセクションでは、修復パケットを含む修復フローを生成する方法、および使用可能なソースと修復パケットのセットから欠落しているソースパケットを再構築する方法の概要について説明します。 RaptorおよびRaptorQシンボルを生成するための詳細なアルゴリズムは、それぞれ[RFC5053]および[RFC6330]で提供されています。

As per the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes, among others, the identification of the repair flow(s) and the source flow(s). Methods to convey FEC Framework Configuration Information are provided in [FEC-SIG]. Specifically, the reader is referred to the SDP elements document [RFC6364], which describes the usage of the 'SDP' encoding format as an example encoding format for FEC Framework Configuration Information.

FECフレームワークドキュメント[RFC6363]に従って、FECフレームワーク構成情報には、特に、修復フローとソースフローの識別が含まれます。 FECフレームワーク構成情報を伝える方法は、[FEC-SIG]で提供されています。具体的には、読者はSDP要素のドキュメント[RFC6364]を参照します。これは、FECフレームワーク構成情報のエンコード形式の例として「SDP」エンコード形式の使用法を説明しています。

For the generation of a repair flow:

修復フローの生成：

o repair packets SHALL be constructed according to Section 10.2, and

o 修復パケットは、セクション10.2に従って構築する必要があります。

o RTCP SHALL be used according to Section 10.3.

o RTCPは、セクション10.3に従って使用する必要があります。

For the reconstruction of a source packet of a source RTP session at the receiver, based on the availability of a source RTP session and a repair RTP session, the procedures in Section 10.4 may be used.

受信機でのソースRTPセッションのソースパケットの再構築では、ソースRTPセッションと修復RTPセッションの可用性に基づいて、セクション10.4の手順を使用できます。

10.2. Repair Packet Construction

10.2. 修理パケット建設

The construction of the repair packet is fully specified in Section 4. A repair packet is constructed by the concatenation of

修復パケットの構築は、セクション4で完全に指定されています。修復パケットは、次の連結によって構築されます。

o an RTP header as specified in Section 4.1, and

o セクション4.1で指定されたRTPヘッダー、および

o payload data as defined in Section 4.3.

o セクション4.3で定義されているペイロードデータ。

Repair Packet Construction may make use of the Sender Operation for RTP repair flows as specified in see [RFC6363], Section 4.2.

[RFC6363]のセクション4.2で指定されているように、修理パケット構築では、RTP修理フローの送信者操作を利用できます。

10.3. Usage of RTCP

10.3. RTCPの使用法

RTCP SHALL be used according to [RFC3550]. If the repair RTP session is sent in a separate RTP session, the two sessions MUST be associated using RTCP CNAME (Canonical Name).

RTCPは[RFC3550]に従って使用する必要があります。修復RTPセッションが別のRTPセッションで送信される場合、RTCP CNAME（正規名）を使用して2つのセッションを関連付ける必要があります。

10.4. Source Packet Reconstruction

10.4. ソースパケットの再構築

Source Packet Reconstruction may make use of the receiver operation for the case of RTP repair flows as specified in [RFC6363], Section 4.3. Depending on the FEC Scheme using the ones defined in [RFC6681], the appropriate source blocks are formed. If enough data for decoding any or all of the missing source payloads in the source block has been received, the respective FEC decoding procedures are applied.

[RFC6363]のセクション4.3で指定されているように、RTP修復フローの場合には、ソースパケット再構築でレシーバー操作を使用できます。 [RFC6681]で定義されたものを使用するFECスキームに応じて、適切なソースブロックが形成されます。ソースブロック内の欠落しているソースペイロードのいずれかまたはすべてをデコードするのに十分なデータが受信された場合、それぞれのFECデコード手順が適用されます。

In case the FEC Scheme uses Raptor codes as defined in [RFC5053], then the Example FEC Decoder, as specified in [RFC5053], Section 5.5, may be used.

FECスキームが[RFC5053]で定義されているラプターコードを使用する場合、[RFC5053]のセクション5.5で指定されているサンプルFECデコーダーを使用できます。

In case the FEC Scheme uses RaptorQ codes as defined in [RFC6330], then the Example FEC Decoder, as specified in [RFC6330], Section 5.4, may be used.

FECスキームが[RFC6330]で定義されているRaptorQコードを使用する場合、[RFC6330]のセクション5.4で指定されているサンプルFECデコーダーを使用できます。

11. Session Description Protocol (SDP) Example

11. セッション記述プロトコル（SDP）の例

This section provides an SDP [RFC4566] example. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). The 'group' attribute and the FEC grouping semantics defined in [RFC5888] and [RFC5956], respectively, are used to associate source and repair flows. We form one FEC group with the "a=group:FEC S1 R1" line. The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms.

このセクションでは、SDP [RFC4566]の例を示します。 1つのソースビデオストリーム（mid：S1）と1つのFEC修復ストリーム（mid：R1）があるとします。 [RFC5888]と[RFC5956]でそれぞれ定義されている「グループ」属性とFECグループ化セマンティクスは、ソースフローと修復フローを関連付けるために使用されます。「a = group：FEC S1 R1」行で1つのFECグループを形成します。ソースストリームと修復ストリームは、異なるマルチキャストグループの同じポートに送信されます。修復ウィンドウは200 msに設定されています。

   v=0
   o=ali 1122334455 1122334466 IN IP4 fec.example.com
   s=Raptor RTP FEC Example
   t=0 0
   a=group:FEC-FR S1 R1
   m=video 30000 RTP/AVP 100
   c=IN IP4 233.252.0.1/127
   a=rtpmap:100 MP2T/90000
   a=fec-source-flow: id=0
   a=mid:S1
   m=application 30000 RTP/AVP 110
   c=IN IP4 233.252.0.2/127
   a=rtpmap:110 raptorfec/90000
   a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128;
           P=A; repair-window=200000
   a=mid:R1

12. IANA Considerations

12. IANAに関する考慮事項

IANA has registered 'application/raptorfec' as specified in Section 6.1.1, 'video/raptorfec' as specified in Section 6.2.1, 'audio/raptorfec' as specified in Section 6.3.1, and 'text/raptorfec' as specified in Section 6.4.1. The media type has also been added to the IANA registry for "RTP Payload Format media types" (http://www.iana.org/assignments/rtp-parameters).

IANAは、セクション6.1.1で指定された「application / raptorfec」、セクション6.2.1で指定された「video / raptorfec」、セクション6.3.1で指定された「audio / raptorfec」、および指定された「text / raptorfec」を登録しています。セクション6.4.1。メディアタイプは、「RTP Payload Formatメディアタイプ」（http://www.iana.org/assignments/rtp-parameters）のIANAレジストリにも追加されています。

13. Security Considerations

13. セキュリティに関する考慮事項

Security Considerations related to the use of the FEC Framework are addressed in [RFC6363]. These considerations apply in full to users of the RTP payload formats defined in this document, since these are defined in terms of the FEC Framework.

FECフレームワークの使用に関するセキュリティの考慮事項は、[RFC6363]で対処されています。これらの考慮事項は、FECフレームワークの観点から定義されているため、このドキュメントで定義されているRTPペイロード形式のユーザーに完全に適用されます。

No further security considerations related specifically to the Raptor FEC Schemes defined in [RFC6681] have been identified.

[RFC6681]で定義されているRaptor FECスキームに特に関連するセキュリティ上の考慮事項はこれ以上確認されていません。

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system can also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo MAY vary. It is dependent on the application, transport, and signaling protocol employed. Therefore, a single mechanism is not sufficient; although, if suitable, using the Secure Real-Time Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives exist.

この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適用可能なすべてのRTPプロファイルで説明されているセキュリティの考慮事項に従います。このメモ内で定義されたRTPペイロード形式を運ぶRTPパケットの主なセキュリティの考慮事項は、機密性、完全性、およびソースの信頼性です。機密性は、RTPペイロードを暗号化することによって実現されます。 RTPパケットの整合性は、適切な暗号化整合性保護メカニズムによって実現されます。このような暗号化システムは、ペイロードのソースの認証も可能にします。このRTPペイロード形式に適したセキュリティメカニズムは、機密性、整合性保護、およびRTPパケットがRTPセッションのメンバーからのものかどうかを判別できるソース認証を提供する必要があります。このメモに続くRTPとペイロードにセキュリティを提供する適切なメカニズムは異なるかもしれないことに注意してください。これは、使用するアプリケーション、トランスポート、およびシグナリングプロトコルによって異なります。したがって、単一のメカニズムでは不十分です。ただし、適切な場合は、Secure Real-Time Transport Protocol（SRTP）[RFC3711]を使用することをお勧めします。使用できる他のメカニズムには、IPsec [RFC4301]とトランスポート層セキュリティ（TLS）[RFC5246]（RTP over TCP）があります。他の選択肢があります。

14. References

14. 参考文献

14.1. Normative References

14.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。

[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.

[RFC4855] Casner、S。、「RTPペイロード形式のメディアタイプ登録」、RFC 4855、2007年2月。

[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.

[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。

[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.

[RFC6364] Begen、A。、「Forward Error Correction（FEC）フレームワークのセッション記述プロトコル要素」、RFC 6364、2011年10月。

[RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, August 2012.

[RFC6681] Watson、M.、Stockhammer、T。、およびM. Luby、「FECFRAMEのラプター転送エラー訂正（FEC）スキーム」、RFC 6681、2012年8月。

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

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。

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

[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「セキュアなリアルタイム転送プロトコル（SRTP）」、RFC 3711、2004年3月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007.

[RFC5053] Luby、M.、Shokrollahi、A.、Watson、M。、およびT. Stockhammer、「Raptor Forward Error Correction Scheme for Object Delivery」、RFC 5053、2007年10月。

[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, August 2011.

[RFC6330] Luby、M.、Shokrollahi、A.、Watson、M.、Stockhammer、T。、およびL. Minder、「RaptorQ Forward Error Correction Scheme for Object Delivery」、RFC 6330、2011年8月。

14.2. Informative References

14.2. 参考引用

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

[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。

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

[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。

[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

[RFC5888] Camarillo、G。およびH. Schulzrinne、「Session Description Protocol（SDP）Grouping Framework」、RFC 5888、2010年6月。

[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.

[RFC5956] Begen、A。、「Session Description ProtocolのForward Error Correction Grouping Semantics」、RFC 5956、2010年9月。

[FEC-SIG] Asati, R., "Methods to convey FEC Framework Configuration Information", Work in Progress, February 2012.

[FEC-SIG]アサティR。、「FECフレームワーク構成情報を伝達する方法」、作業中、2012年2月。

Authors' Addresses

著者のアドレス

Mark Watson Netflix 100 Winchester Circle Los Gatos, CA 95032 United States

Mark Watson Netflix 100 Winchester Circle Los Gatos、CA 95032アメリカ合衆国

   EMail: watsonm@netflix.com

Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany

Thomas Stockhammer Nomor Research Brecherspitzstrasse 8ミュンヘン81541ドイツ

   EMail: stockhammer@nomor.de

Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley, CA 94704 United States

Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley、CA 94704アメリカ合衆国

   EMail: luby@qualcomm.com