[要約] 要約：RFC 6597は、SMPTE ST 336エンコードデータのRTPペイロード形式に関する規格です。 目的：このRFCの目的は、SMPTE ST 336エンコードデータをRTPパケットに効果的に格納するための標準化を提供することです。
Internet Engineering Task Force (IETF) J. Downs, Ed.
Request for Comments: 6597 PAR Government Systems Corp.
Category: Standards Track J. Arbeiter, Ed.
ISSN: 2070-1721 April 2012
RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data
Society of Motion Picture and Television Engineers（SMPTE）ST 336エンコードデータのRTPペイロード形式
Abstract
概要
This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP).
このドキュメントでは、SMPTE ST 336でSociety of Motion Picture and Television Engineers（SMPTE）によって定義されている、KLV（Key-Length-Value）エンコードデータをリアルタイム転送プロトコル（RTP）にパケット化するためのペイロード形式を指定します。
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/rfc6597.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6597で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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 ....................................................2
2. Conventions, Definitions, and Acronyms ..........................3
3. Media Format Background .........................................3
4. Payload Format ..................................................4
4.1. RTP Header Usage ...........................................5
4.2. Payload Data ...............................................5
4.2.1. The KLVunit .........................................5
4.2.2. KLVunit Mapping to RTP Packet Payload ...............6
4.3. Implementation Considerations ..............................6
4.3.1. Loss of Data ........................................6
4.3.1.1. Damaged KLVunits ...........................7
4.3.1.2. Treatment of Damaged KLVunits ..............9
5. Congestion Control ..............................................9
6. Payload Format Parameters .......................................9
6.1. Media Type Definition ......................................9
6.2. Mapping to SDP ............................................10
6.2.1. Offer/Answer Model and Declarative Considerations ..10
7. IANA Considerations ............................................11
8. Security Considerations ........................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in [SMPTE-ST336], into the Real-time Transport Protocol (RTP) [RFC3550].
このドキュメントは、[SMPTE-ST336]でSociety of Motion Picture and Television Engineers（SMPTE）によって定義されている、リアルタイム転送プロトコル（RTP）へのKLV（Key-Length-Value）エンコードデータのパケット化のペイロード形式を指定します）[RFC3550]。
The payload format is defined in such a way that arbitrary KLV data can be carried. No restrictions are placed on which KLV data keys can be used.
ペイロードのフォーマットは、任意のKLVデータを伝送できるように定義されています。使用できるKLVデータキーに制限はありません。
A brief description of SMPTE ST 336, "Data Encoding Protocol Using Key-Length-Value", is given. The payload format itself, including use of the RTP header fields, is specified in Section 4. The media type and IANA considerations are also described. This document concludes with security considerations relevant to this payload format.
SMPTE ST 336「Key-Length-Valueを使用したデータエンコーディングプロトコル」について簡単に説明します。 RTPヘッダーフィールドの使用を含むペイロード形式自体は、セクション4で指定されています。メディアタイプとIANAの考慮事項についても説明します。このドキュメントの最後には、このペイロード形式に関連するセキュリティの考慮事項があります。
The term "Universal Label Key" is used in this document to refer to a fixed-length, 16-byte SMPTE-administered Universal Label (see [SMPTE-ST298]) that is used as an identifying key in a KLV item.
このドキュメントでは、「ユニバーサルラベルキー」という用語は、KLVアイテムの識別キーとして使用される、固定長の16バイトのSMPTE管理のユニバーサルラベル（[SMPTE-ST298]を参照）を指します。
The term "KLV item" is used in this document to refer to one single Universal Label Key, length, and value triplet encoded as described in [SMPTE-ST336].
このドキュメントでは「KLVアイテム」という用語を使用して、[SMPTE-ST336]で説明されているようにエンコードされた単一のユニバーサルラベルキー、長さ、および値のトリプレットを指します。
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]で説明されているように解釈されます。
[SMPTE-ST336], "Data Encoding Protocol Using Key-Length-Value", defines a byte-level data encoding protocol for representing data items and data groups. This encoding protocol definition is independent of the application or transportation method used.
[SMPTE-ST336]、「Key-Length-Valueを使用したデータエンコーディングプロトコル」は、データ項目とデータグループを表すためのバイトレベルのデータエンコーディングプロトコルを定義します。このエンコードプロトコルの定義は、使用するアプリケーションや転送方法に依存しません。
SMPTE ST 336 data encoding can be applied to a wide variety of binary data. This encoding has been used to provide diverse and rich metadata sets that describe or enhance associated video presentations. Use of SMPTE ST 336 encoded metadata in conjunction with video has enabled improvements in multimedia presentations, content management and distribution, archival and retrieval, and production workflow.
SMPTE ST 336データエンコーディングは、さまざまなバイナリデータに適用できます。このエンコーディングは、関連するビデオプレゼンテーションを説明または強化する多様で豊富なメタデータセットを提供するために使用されています。 SMPTE ST 336でエンコードされたメタデータをビデオと組み合わせて使用することで、マルチメディアプレゼンテーション、コンテンツの管理と配信、アーカイブと検索、および制作ワークフローの改善が可能になりました。
The SMPTE ST 336 standard defines a KLV triplet as a data interchange protocol for data items or data groups where the Key identifies the data, the Length specifies the length of the data, and the Value is the data itself. The KLV protocol provides a common interchange point for all compliant applications irrespective of the method of implementation or transport.
SMPTE ST 336規格では、キーがデータを識別し、長さがデータの長さを指定し、値がデータ自体であるデータ項目またはデータグループのデータ交換プロトコルとしてKLVトリプレットを定義しています。 KLVプロトコルは、実装方法や転送方法に関係なく、すべての準拠アプリケーションに共通の交換ポイントを提供します。
The Key of a KLV triplet (a Universal Label Key) is coded using a fixed-length 16-byte SMPTE-administered Universal Label. [SMPTE-ST298] further details the structure of 16-byte SMPTE-administered Universal Labels. Universal Label Keys are maintained in registries published by SMPTE (see, for example, [SMPTE-ST335] and [SMPTE-RP210]).
KLVトリプレットのキー（ユニバーサルラベルキー）は、固定長の16バイトのSMPTE管理のユニバーサルラベルを使用してコード化されます。 [SMPTE-ST298]は、16バイトのSMPTE管理のユニバーサルラベルの構造をさらに詳しく説明しています。ユニバーサルラベルキーは、SMPTEによって公開されたレジストリで維持されます（たとえば、[SMPTE-ST335]および[SMPTE-RP210]を参照）。
The standard also provides methods for combining associated KLV triplets in data sets where the set of KLV triplets is itself coded with the KLV data coding protocol. Such sets can be coded in either full form (Universal Sets) or one of four increasingly bit-efficient forms (Global Sets, Local Sets, Variable Length Packs, and Defined Length Packs). The standard provides a definition of each of these data constructs.
この規格は、KLVトリプレットのセット自体がKLVデータコーディングプロトコルでコーディングされている場合に、関連するKLVトリプレットをデータセットに結合する方法も提供します。このようなセットは、完全な形式（ユニバーサルセット）または4つのビット効率の高い形式（グローバルセット、ローカルセット、可変長パック、および定義長パック）のいずれかでコーディングできます。標準は、これらの各データ構造の定義を提供します。
Additionally, the standard defines the use of KLV coding to provide a means to carry information that is registered with a non-SMPTE external agency.
さらに、この標準は、KLVコーディングの使用を定義して、非SMPTE外部機関に登録された情報を伝達する手段を提供します。
The main goal of the payload format design for SMPTE ST 336 data is to provide carriage of SMPTE ST 336 data over RTP in a simple, yet robust manner. All forms of SMPTE ST 336 data can be carried by the payload format. The payload format maintains simplicity by using only the standard RTP headers and not defining any payload headers.
SMPTE ST 336データのペイロード形式設計の主な目的は、シンプルでありながら堅牢な方法で、RTPを介してSMPTE ST 336データの搬送を提供することです。 SMPTE ST 336データのすべての形式は、ペイロード形式で伝送できます。ペイロード形式は、標準のRTPヘッダーのみを使用し、ペイロードヘッダーを定義しないことで、シンプルさを維持しています。
SMPTE ST 336 KLV data is broken into KLVunits. A KLVunit is simply a logical grouping of otherwise unframed KLV data, grouped based on source data timing (see Section 4.2.1). Each KLVunit is then placed into one or more RTP packet payloads. The RTP header marker bit is used to assist receivers in locating the boundaries of KLVunits.
SMPTE ST 336 KLVデータはKLVユニットに分割されます。 KLVユニットは、ソースデータのタイミングに基づいてグループ化された、他のフレーム化されていないKLVデータの論理グループです（セクション4.2.1を参照）。各KLVユニットは、1つ以上のRTPパケットペイロードに配置されます。 RTPヘッダーマーカービットは、レシーバーがKLVユニットの境界を見つけるのを支援するために使用されます。
This payload format uses the RTP packet header fields as described in the table below:
このペイロード形式は、以下の表で説明されているRTPパケットヘッダーフィールドを使用します。
+-----------+-------------------------------------------------------+
| Field | Usage |
+-----------+-------------------------------------------------------+
| Timestamp | The RTP Timestamp encodes the instant along a |
| | presentation timeline that the entire KLVunit encoded |
| | in the packet payload is to be presented. When one |
| | KLVunit is placed in multiple RTP packets, the RTP |
| | timestamp of all packets comprising that KLVunit MUST |
| | be the same. The timestamp clock frequency is |
| | defined as a parameter to the payload format |
| | (Section 6). |
| | |
| M-bit | The RTP header marker bit (M) is used to demarcate |
| | KLVunits. Senders MUST set the marker bit to '1' for |
| | any RTP packet that contains the final byte of a |
| | KLVunit. For all other packets, senders MUST set the |
| | RTP header marker bit to '0'. This allows receivers |
| | to pass a KLVunit for parsing/decoding immediately |
| | upon receipt of the last RTP packet comprising the |
| | KLVunit. Without this, a receiver would need to wait |
| | for the next RTP packet with a different timestamp to |
| | arrive, thus signaling the end of one KLVunit and the |
| | start of another. |
+-----------+-------------------------------------------------------+
The remaining RTP header fields are used as specified in [RFC3550].
残りのRTPヘッダーフィールドは、[RFC3550]での指定に従って使用されます。
A KLVunit is a logical collection of all KLV items that are to be presented at a specific time. A KLVunit is comprised of one or more KLV items. Compound items (sets, packs) are allowed as per [SMPTE-ST336], but the contents of a compound item MUST NOT be split across two KLVunits. Multiple KLV items in a KLVunit occur one after another with no padding or stuffing between items.
KLVユニットは、特定の時間に提示されるすべてのKLVアイテムの論理的なコレクションです。 KLVユニットは、1つ以上のKLVアイテムで構成されます。複合アイテム（セット、パック）は[SMPTE-ST336]に従って許可されていますが、複合アイテムのコンテンツは2つのKLVユニットに分割してはなりません。 KLVユニット内の複数のKLVアイテムは、アイテム間にパディングまたはスタッフィングなしで次々に発生します。
An RTP packet payload SHALL contain one, and only one, KLVunit or a fragment thereof. KLVunits small enough to fit into a single RTP packet (RTP packet size is up to the implementation but should consider underlying transport/network factors such as MTU limitations) are placed directly into the payload of the RTP packet, with the first byte of the KLVunit (which is the first byte of a KLV Universal Label Key) being the first byte of the RTP packet payload.
RTPパケットペイロードには、KLVユニットまたはそのフラグメントが1つだけ含まれている必要があります（SHALL）。単一のRTPパケットに収まるほど小さいKLVユニット（RTPパケットサイズは実装次第ですが、MTUの制限などの根本的なトランスポート/ネットワーク要因を考慮する必要があります）は、KLVユニットの最初のバイトとともに、RTPパケットのペイロードに直接配置されます（KLVユニバーサルラベルキーの最初のバイト）は、RTPパケットペイロードの最初のバイトです。
KLVunits too large to fit into a single RTP packet payload MAY span multiple RTP packet payloads. When this is done, the KLVunit data MUST be sent in sequential byte order, such that when all RTP packets comprising the KLVunit are arranged in sequence number order, concatenating the payload data together exactly reproduces the original KLVunit.
KLVユニットが大きすぎて単一のRTPパケットペイロードに収まらない場合は、複数のRTPパケットペイロードにまたがる場合があります。この場合、KLVユニットデータはシーケンシャルバイトオーダーで送信する必要があるため、KLVユニットを構成するすべてのRTPパケットがシーケンス番号順に配置されている場合、ペイロードデータを連結すると、元のKLVユニットが正確に再現されます。
Additionally, when a KLVunit is fragmented across multiple RTP packets, all RTP packets transporting the fragments of a KLVunit MUST have the same timestamp.
さらに、KLVユニットが複数のRTPパケットにわたってフラグメント化されている場合、KLVユニットのフラグメントを転送するすべてのRTPパケットは同じタイムスタンプを持つ必要があります。
KLVunits are bounded with changes in RTP packet timestamps. The marker (M) bit in the RTP packet headers marks the last RTP packet comprising a KLVunit (see Section 4.1).
KLVユニットは、RTPパケットのタイムスタンプの変更に制限されます。 RTPパケットヘッダーのマーカー（M）ビットは、KLVユニットを構成する最後のRTPパケットをマークします（セクション4.1を参照）。
RTP is generally deployed in network environments where packet loss might occur. RTP header fields enable detection of lost packets, as described in [RFC3550]. When transmitting payload data described by this payload format, packet loss can cause the loss of whole KLVunits or portions thereof.
RTPは通常、パケット損失が発生する可能性のあるネットワーク環境に導入されます。 [RFC3550]で説明されているように、RTPヘッダーフィールドは、失われたパケットの検出を有効にします。このペイロード形式で記述されたペイロードデータを送信する場合、パケット損失により、KLVユニット全体またはその一部が失われる可能性があります。
A damaged KLVunit is any KLVunit that was carried in one or more RTP packets that have been lost. When a lost packet is detected (through use of the sequence number header field), the receiver
損傷したKLVユニットは、失われた1つ以上のRTPパケットで運ばれたKLVユニットです。失われたパケットが（シーケンス番号ヘッダーフィールドを使用して）検出されると、レシーバー
o MUST consider the KLVunit partially received before a lost packet as damaged. This damaged KLVunit includes all packets prior to the lost one (in sequence number order) back to, but not including, the most recent packet in which the M-bit in the RTP header was set to '1'.
o 失われたパケットの前に部分的に受信されたKLVユニットが損傷していると見なす必要があります。この損傷したKLVユニットには、失われたパケットの前のすべてのパケット（シーケンス番号順）が含まれますが、RTPヘッダーのMビットが「1」に設定された最新のパケットは含まれません。
o MUST consider the first KLVunit received after a lost packet as damaged. This damaged KLVunit includes the first packet after the lost one (in sequence number order) and, if the first packet has its M-bit in the RTP header set to '0', all subsequent packets up to and including the next one with the M-bit in the RTP header set to '1'.
o 失われたパケットの後に受信された最初のKLVユニットを損傷していると見なす必要があります。この破損したKLVユニットには、失われたパケットの後の最初のパケット（シーケンス番号順）が含まれ、最初のパケットのRTPヘッダーのMビットが「0」に設定されている場合、次のパケットまでのすべての後続のパケットが含まれます。 「1」に設定されたRTPヘッダーのMビット。
The above applies, regardless of the M-bit value in the RTP header of the lost packet itself. This enables very basic receivers to look solely at the M-bit to determine the outer boundaries of damaged KLVunits. For example, when a packet with the M-bit set to '1' is lost, the KLVunit that the lost packet would have terminated is considered damaged, as is the KLVunit comprised of packets received subsequent to the lost packet (up to and including the next received packet with the M-bit set to '1').
上記は、失われたパケット自体のRTPヘッダーのMビット値に関係なく適用されます。これにより、非常に基本的なレシーバーがMビットのみを調べて、損傷したKLVユニットの外側の境界を特定できます。たとえば、Mビットが「1」に設定されたパケットが失われると、失われたパケットが終了したKLVユニットは、失われたパケットの後に受信されたパケット（最大Mビットが「1」に設定された次の受信パケット）。
The example below illustrates how a receiver would handle a lost packet in another possible packet sequence:
次の例は、受信者が失われたパケットを別の可能なパケットシーケンスでどのように処理するかを示しています。
+---------+-------------+ +--------------+
| RTP Hdr | Data | | |
+---------+-------------+ +--------------+
.... | ts = 30 | KLV KLV ... | | | >---+
| M = 1 | | | | |
| seq = 5 | ... KLV KLV | | | |
+---------+-------------+ +--------------+ |
Last RTP pkt for time 30 Lost RTP Pkt |
(seq = 6) |
|
+--------------------------------------------------------+
|
| +---------+-------------+ +---------+-------------+
| | RTP Hdr | Data | | RTP Hdr | Data |
| +---------+-------------+ +---------+-------------+
+--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+
| M = 0 | | | M = 1 | | |
| seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | |
+---------+-------------+ +---------+-------------+ |
RTP pkt for time 45 Last RTP pkt for time 45 |
KLVunit carried in these two packets is "damaged" |
|
+----------------------------------------------------------------+
|
| +---------+-------------+
| | RTP Hdr | Data |
| +---------+-------------+
+--> | ts = 55 | KLV KLV ... | ....
| M = 1 | |
| seq = 9 | ... KLV ... |
+---------+-------------+
Last and only RTP pkt
for time 55
In this example, the packets with sequence numbers 7 and 8 contain portions of a KLVunit with a timestamp of 45. This KLVunit is considered "damaged" due to the missing RTP packet with sequence number 6, which might have been part of this KLVunit. The KLVunit for timestamp 30 (ended in packet with sequence number 5) is unaffected by the missing packet. The KLVunit for timestamp 55, carried in the packet with sequence number 9, is also unaffected by the missing packet and is considered complete and intact.
この例では、シーケンス番号7と8のパケットには、タイムスタンプが45のKLVユニットの一部が含まれています。このKLVユニットは、シーケンス番号6のRTPパケットが欠落しているため「破損」していると見なされます。タイムスタンプ30（シーケンス番号5のパケットで終了）のKLVユニットは、失われたパケットの影響を受けません。シーケンス番号9のパケットで運ばれるタイムスタンプ55のKLVユニットも、欠落しているパケットの影響を受けず、完全で無傷と見なされます。
SMPTE ST 336 KLV data streams are built in such a way that it is possible to partially recover from errors or missing data in a stream. Exact specifics of how damaged KLVunits are handled are left to each implementation, as different implementations can have differing capabilities and robustness in their downstream KLV payload processing. Because some implementations can be particularly limited in their capacity to handle damaged KLVunits, receivers MAY drop damaged KLVunits entirely.
SMPTE ST 336 KLVデータストリームは、ストリーム内のエラーまたは欠落データから部分的に回復できるように構築されています。実装ごとにダウンストリームKLVペイロード処理の機能と堅牢性が異なる場合があるため、損傷したKLVユニットの処理方法の詳細は各実装に任されています。一部の実装では、損傷したKLVユニットを処理する能力が特に制限される可能性があるため、レシーバーは損傷したKLVユニットを完全にドロップする場合があります。
The general congestion control considerations for transporting RTP data apply; see RTP [RFC3550] and any applicable RTP profile, like AVP [RFC3551].
RTPデータの転送に関する一般的な輻輳制御の考慮事項が適用されます。 RTP [RFC3550]およびAVP [RFC3551]などの該当するRTPプロファイルを参照してください。
Further, SMPTE ST 336 data can be encoded in different schemes that reduce the overhead associated with individual data items within the overall stream. SMPTE ST 336 grouping constructs, such as local sets and data packs, provide a mechanism to reduce bandwidth requirements.
さらに、SMPTE ST 336データは、ストリーム全体の個々のデータ項目に関連するオーバーヘッドを削減するさまざまなスキームでエンコードできます。ローカルセットやデータパックなどのSMPTE ST 336グループ化構造は、帯域幅要件を削減するメカニズムを提供します。
This RTP payload format is identified using the application/smpte336m media type, which is registered in accordance with [RFC4855], and using the template of [RFC4288].
このRTPペイロード形式は、[RFC4855]に従って登録されているapplication / smpte336mメディアタイプと[RFC4288]のテンプレートを使用して識別されます。
Type name: application
タイプ名：アプリケーション
Subtype name: smpte336m
サブタイプ名：smpte336m
Required parameters:
必須パラメーター：
rate: RTP timestamp clock rate. Typically chosen based on sampling rate of metadata being transmitted, but other rates can be specified.
rate：RTPタイムスタンプクロックレート。通常、送信されるメタデータのサンプリングレートに基づいて選択されますが、他のレートを指定することもできます。
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: This media type is framed and binary; see Section 4.8 of [RFC4288].
エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください。
Security considerations: See Section 8 of RFC 6597.
セキュリティに関する考慮事項：RFC 6597のセクション8をご覧ください。
Interoperability considerations: Data items in smpte336m can be very diverse. Receivers might only be capable of interpreting a subset of the possible data items; unrecognized items are skipped. Agreement on data items to be used out of band, via application profile or similar, is typical.
相互運用性に関する考慮事項：smpte336mのデータ項目は非常に多様である可能性があります。レシーバーは、可能なデータ項目のサブセットを解釈することしかできない場合があります。認識されないアイテムはスキップされます。アプリケーションプロファイルなどを介して、帯域外で使用されるデータ項目に関する合意が一般的です。
Published specification: RFC 6597
公開された仕様：RFC 6597
Applications that use this media type: Streaming of metadata associated with simultaneously streamed video and transmission of [SMPTE-ST336]-based media formats (e.g., Material Exchange Format (MXF) [SMPTE-ST377]).
このメディアタイプを使用するアプリケーション：同時にストリーミングされるビデオに関連付けられたメタデータのストリーミングと、[SMPTE-ST336]ベースのメディアフォーマット（Material Exchange Format（MXF）[SMPTE-ST377]など）の送信。
Additional Information: none
追加情報：なし
Person & email address to contact for further information: J. Downs
<jeff_downs@partech.com>; IETF Payload Working Group
<payload@ietf.org>
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:
著者：
J. Downs <jeff_downs@partech.com>
J. Arbeiter <jimsgti@gmail.com>
Change controller: IETF Payload working group delegated from the IESG.
変更コントローラー：IESGから委任されたIETFペイロードワーキンググループ。
The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of [RFC4855].
上記で定義されたペイロード形式のメディアタイプとそのパラメータのマッピングは、[RFC4855]のセクション3に従って行う必要があります。
This payload format has no configuration or optional format parameters. Thus, when offering SMPTE ST 336 Encoded Data over RTP using the Session Description Protocol (SDP) in an Offer/Answer model [RFC3264] or in a declarative manner (e.g., SDP in the Real-Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974]), there are no specific considerations.
このペイロード形式には、構成またはオプションの形式パラメーターはありません。したがって、オファー/アンサーモデル[RFC3264]または宣言的な方法（例：リアルタイムストリーミングプロトコル（RTSP）のSDP [RFC2326]でセッション記述プロトコル（SDP）を使用してRTPでSMPTE ST 336エンコードデータを提供する場合または、Session Announcement Protocol（SAP）[RFC2974]）、特定の考慮事項はありません。
IANA has registered application/smpte336m as specified in Section 6.1. The media type has been added to the IANA registry for "RTP Payload Format media types" (http://www.iana.org/assignments/rtp-parameters).
IANAはセクション6.1で指定されているapplication / smpte336mを登録しています。メディアタイプは、「RTP Payload Formatメディアタイプ」（http://www.iana.org/assignments/rtp-parameters）のIANAレジストリに追加されました。
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 encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Cryptographic systems may 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 whether or not an RTP packet is from a member of the RTP session.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適用可能なすべてのRTPプロファイルで説明されているセキュリティの考慮事項に従います。このメモ内で定義されたRTPペイロード形式を運ぶRTPパケットの主なセキュリティの考慮事項は、機密性、完全性、およびソースの信頼性です。機密性は、RTPペイロードの暗号化によって実現されます。 RTPパケットの整合性は、適切な暗号化整合性保護メカニズムによって実現されます。暗号化システムは、ペイロードのソースの認証も許可する場合があります。このRTPペイロード形式に適したセキュリティメカニズムは、機密性、完全性保護、およびRTPパケットがRTPセッションのメンバーからのものかどうかを判断できるソース認証を提供する必要があります。
Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of 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), but other alternatives may exist as well.
このメモに続くRTPとペイロードにセキュリティを提供する適切なメカニズムは異なる場合があることに注意してください。これは、使用するアプリケーション、トランスポート、およびシグナリングプロトコルによって異なります。したがって、単一のメカニズムでは不十分ですが、適切な場合は、Secure Real-time Transport Protocol（SRTP）[RFC3711]の使用が推奨されます。使用できる他のメカニズムは、IPsec [RFC4301]とトランスポート層セキュリティ（TLS）[RFC5246]（RTP over TCP）ですが、他の代替手段も存在する場合があります。
This RTP payload format presents the possibility for significant non-uniformity in the receiver-side computational complexity during processing of SMPTE ST 336 payload data. Because the length of SMPTE ST 336 encoded data items is essentially unbounded, receivers must take care when allocating resources used in processing. It is easy to construct pathological data that would cause a naive decoder to allocate large amounts of resources, resulting in denial-of-service threats. Receivers SHOULD place limits on resource allocation that are within the bounds set forth by any application profile in use.
このRTPペイロード形式は、SMPTE ST 336ペイロードデータの処理中に受信側の計算の複雑さが著しく不均一になる可能性を示しています。 SMPTE ST 336でエンコードされたデータアイテムの長さは本質的に無制限であるため、受信側は処理に使用されるリソースを割り当てるときに注意する必要があります。単純なデコーダが大量のリソースを割り当て、サービス拒否の脅威をもたらす病理データを簡単に作成できます。受信者は、使用中のアプリケーションプロファイルによって設定された範囲内のリソース割り当てに制限を設定する必要があります（SHOULD）。
This RTP payload format does not contain any inherently active content. However, individual SMPTE ST 336 KLV items could be defined to convey active content in a particular application. Therefore, receivers capable of decoding and interpreting such data items should use appropriate caution and security practices. In particular, accepting active content from streams that lack authenticity or integrity protection mechanisms places a receiver at risk of attacks using spoofed packets. Receivers not capable of decoding such data items are not at risk; unknown data items are skipped over and discarded according to SMPTE ST 336 processing rules.
このRTPペイロード形式には、本質的にアクティブなコンテンツは含まれていません。ただし、個々のSMPTE ST 336 KLVアイテムを定義して、特定のアプリケーションでアクティブコンテンツを伝達できます。したがって、そのようなデータ項目をデコードおよび解釈できる受信機は、適切な注意とセキュリティ慣行を使用する必要があります。特に、認証または整合性保護メカニズムが不足しているストリームからアクティブコンテンツを受け入れると、受信者はスプーフィングされたパケットを使用した攻撃のリスクにさらされます。このようなデータ項目をデコードできない受信者は危険にさらされません。不明なデータ項目は、SMPTE ST 336処理ルールに従ってスキップされ、破棄されます。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、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月。
[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月。
[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.ノーマン、「Secure Real-time Transport Protocol（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月。
[SMPTE-RP210] Society of Motion Picture and Television Engineers, "SMPTE RP 210v12:2010 Data Element Dictionary", 2010, <http://www.smpte-ra.org/mdd/>.
[SMPTE-RP210] Society of Motion Picture and Television Engineers、「SMPTE RP 210v12：2010 Data Element Dictionary」、2010、<http://www.smpte-ra.org/mdd/>。
[SMPTE-ST298] Society of Motion Picture and Television Engineers, "SMPTE ST 298:2009 Universal Labels for Unique Identification of Digital Data", 2009, <http://www.smpte.org>.
[SMPTE-ST298] Society of Motion Picture and Television Engineers、「SMPTE ST 298：2009 Universal Labels for Unique Identification of Digital Data」、2009年、<http://www.smpte.org>。
[SMPTE-ST335] Society of Motion Picture and Television Engineers, "SMPTE ST 335:2012 Metadata Element Dictionary Structure", 2012, <http://www.smpte.org>.
[SMPTE-ST335] Society of Motion Picture and Television Engineers、「SMPTE ST 335：2012 Metadata Element Dictionary Structure」、2012、<http://www.smpte.org>。
[SMPTE-ST336] Society of Motion Picture and Television Engineers, "SMPTE ST 336:2007 Data Encoding Protocol Using Key-Length-Value", 2007, <http://www.smpte.org>.
[SMPTE-ST336] Society of Motion Picture and Television Engineers、「SMPTE ST 336：2007 Data Encoding Protocol Using Key-Length-Value」、2007年、<http://www.smpte.org>。
[SMPTE-ST377] Society of Motion Picture and Television Engineers, "SMPTE ST 377-1:2011 Material Exchange Format (MXF) - File Format Specification", 2011, <http://www.smpte.org>.
[SMPTE-ST377] Society of Motion Picture and Television Engineers、「SMPTE ST 377-1：2011 Material Exchange Format（MXF）-File Format Specification」、2011、<http://www.smpte.org>。
Authors' Addresses
著者のアドレス
J. Downs (editor) PAR Government Systems Corp. US
J.ダウンズ（編集者）PARガバメントシステムズコーポレーション米国
EMail: jeff_downs@partech.com
J. Arbeiter (editor) US
J.ワーカー（編集者）米国
EMail: jimsgti@gmail.com