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
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
电影和电视工程师协会（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）在SMPTE ST 336中定义的KLV（密钥长度值）编码数据打包为实时传输协议（RTP）的有效载荷格式。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]中美国电影电视工程师学会（SMPTE）定义的KLV（键长值）编码数据打包成实时传输协议（RTP）[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.
简要介绍了SMPTEST336“使用密钥长度值的数据编码协议”。第4节规定了有效负载格式本身，包括RTP头字段的使用。还描述了媒体类型和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.
本文件中的术语“通用标签密钥”是指固定长度、16字节SMPTE管理的通用标签（见[SMPTE-ST298]），用作KLV项目中的识别密钥。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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]“使用密钥长度值的数据编码协议”定义了用于表示数据项和数据组的字节级数据编码协议。此编码协议定义与所使用的应用程序或传输方法无关。
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数据编码协议进行编码。此类集合可以以完整形式（通用集合）或四种日益位高效的形式（全局集合、局部集合、可变长度包和定义长度包）之一进行编码。该标准提供了每个数据结构的定义。
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数据被分解为KLVUnit。KLVunit仅仅是一个逻辑分组，该分组是基于源数据定时（见第4.2.1节）分组的非框架KLV数据。然后将每个KLVunit放入一个或多个RTP数据包有效载荷中。RTP报头标记位用于帮助接收机定位KLVUnit的边界。
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. |
+-----------+-------------------------------------------------------+
+-----------+-------------------------------------------------------+
| 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.
KLVunit是在特定时间呈现的所有KLV项目的逻辑集合。KLVunit由一个或多个KLV项目组成。根据[SMPTE-ST336]的规定，允许使用复合项目（套、包），但复合项目的内容不得在两个KLVUnit之间拆分。KLVunit中的多个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数据包有效载荷应包含且仅包含一个KLVunit或其片段。KLVUnice足够小以适合单个RTP分组（RTP分组大小取决于实现，但应考虑底层传输/网络因素，如MTU限制）直接放置到RTP分组的有效负载中，与KLVUnice（它是KLV通用标签密钥的第一个字节）的第一个字节一起被放置到RTP分组的有效载荷中。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.
KLVUnit太大而无法装入单个RTP数据包有效负载可能会跨越多个RTP数据包有效负载。当完成此操作时，必须以顺序字节顺序发送KLVunit数据，使得当组成KLVunit的所有RTP分组以序列号顺序排列时，将有效负载数据串联在一起精确地再现原始KLVunit。
Additionally, when a KLVunit is fragmented across multiple RTP packets, all RTP packets transporting the fragments of a KLVunit MUST have the same timestamp.
此外，当一个KLVunit在多个RTP数据包之间被分段时，所有传输KLVunit片段的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).
Klvunit以RTP数据包时间戳的变化为界。RTP数据包头中的标记（M）位标记最后一个包含KLVunit的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通常部署在可能发生数据包丢失的网络环境中。RTP报头字段可以检测丢失的数据包，如[RFC3550]中所述。当传输由该有效载荷格式描述的有效载荷数据时，分组丢失可导致整个klvUnit或其部分的丢失。
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
损坏的KLVunit是指在一个或多个RTP数据包中携带的任何已丢失的KLVunit。当检测到丢失的数据包时（通过使用序列号报头字段），接收器
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 必须考虑KLVUnk部分接收之前丢失的包损坏。此损坏的KLVunit包括丢失的数据包之前的所有数据包（按序列号顺序）返回到但不包括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 必须考虑丢失的数据包被损坏后接收到的第一个KLVU单元。此损坏的KLVunit包括丢失的数据包之后的第一个数据包（按序列号顺序），如果第一个数据包的RTP报头中的M位设置为“0”，则所有后续数据包（包括RTP报头中的M位设置为“1”的下一个数据包）。
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位，以确定受损KLVUnit的外部边界。例如，当M位设置为“1”的数据包丢失时，丢失的数据包本应终止的KLVunit被视为已损坏，由丢失数据包之后接收的数据包组成的KLVunit也被视为已损坏（直到并包括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
+---------+-------------+ +--------------+
| 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的KLVunit的部分。由于序列号为6的RTP数据包丢失，此KLVunit被视为“已损坏”，这可能是此KLVunit的一部分。时间戳30的KLVunit（以序列号为5的数据包结束）不受丢失数据包的影响。在序列号为9的分组中携带的用于时间戳55的KLVunit也不受丢失分组的影响，并且被认为是完整和完整的。
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数据流的构建方式可以部分恢复流中的错误或丢失数据。如何处理受损KLVUnit的具体细节留给每个实现，因为不同的实现在其下游KLV有效负载处理中可能具有不同的功能和健壮性。由于某些实现在处理损坏的KLVUnit的能力上可能特别有限，接收器可能会完全丢弃损坏的KLVUnit。
The general congestion control considerations for transporting RTP data apply; see RTP [RFC3550] and any applicable RTP profile, like AVP [RFC3551].
传输RTP数据的一般拥塞控制注意事项适用；参见RTP[RFC3550]和任何适用的RTP配置文件，如AVP[RFC3551]。
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有效负载格式使用应用程序/smpte336m媒体类型标识，该媒体类型根据[RFC4855]注册，并使用[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.
速率：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]的媒体格式（例如，材料交换格式（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>
Person & email address to contact for further information: J. Downs
<jeff_downs@partech.com>; IETF Payload Working Group
<payload@ietf.org>
Intended usage: 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. Downs <jeff_downs@partech.com>
J. Arbeiter <jimsgti@gmail.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]中使用会话描述协议（SDP）或以声明方式（例如，实时流协议（RTSP）[RFC2326]或会话公告协议（SAP）[RFC2974]中的SDP）通过RTP提供SMPTE ST 336编码数据时，没有具体的考虑事项。
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节的规定注册了申请/smpte336m。媒体类型已添加到IANA注册表中，用于“RTP有效负载格式媒体类型”(http://www.iana.org/assignments/rtp-parameters).
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和有效负载提供安全性的适当机制可能会有所不同。它取决于应用程序、传输和所采用的信令协议。因此，单一机制是不够的，尽管如果合适，建议使用安全实时传输协议（SRTP）[RFC3711]。可以使用的其他机制有IPsec[RFC4301]和传输层安全（TLS）[RFC5246]（TCP上的RTP），但也可能存在其他替代方案。
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编码数据项的长度基本上是无界的，因此在分配处理中使用的资源时，接收器必须小心。构造病理数据很容易，这会导致幼稚的解码器分配大量资源，从而导致拒绝服务威胁。接收方应在使用中的任何应用程序配置文件规定的范围内对资源分配进行限制。
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
此RTP有效负载格式不包含任何固有的活动内容。然而，可以定义单个SMPTE ST 336 KLV项目，以在特定应用中传送活动内容。因此，能够解码和解释此类数据项的接收器应采取适当的谨慎和安全措施。特别是，从缺乏真实性或可用性的流中接受活动内容
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.
完整性保护机制使接收器面临使用伪造数据包进行攻击的风险。不能解码此类数据项的接收器不存在风险；根据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：实时应用的传输协议”，STD 64，RFC 35502003年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，“介质类型规范和注册程序”，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 48552007年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，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，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]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年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，“传输层安全（TLS）协议版本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]电影和电视工程师学会，“SMPTE RP 210v12:2010数据元素词典”，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]电影和电视工程师学会，“SMPTE ST 298:2009数字数据唯一标识通用标签”，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]电影和电视工程师学会，“SMPTE ST 335:2012元数据元素字典结构”，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]电影和电视工程师学会，“SMPTE ST 336:2007使用密钥长度值的数据编码协议”，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]电影和电视工程师学会，“SMPTE ST 377-1:2011材料交换格式（MXF）-文件格式规范”，2011<http://www.smpte.org>.
Authors' Addresses
作者地址
J. Downs (editor) PAR Government Systems Corp. US
J. Downs（编辑）PAR政府系统公司
EMail: jeff_downs@partech.com
EMail: jeff_downs@partech.com
J. Arbeiter (editor) US
J.Arbeiter（编辑）美国
EMail: jimsgti@gmail.com
EMail: jimsgti@gmail.com