RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data
Extracted elements (24)
KLVunits can span multiple RTP packets to accommodate data that exceeds MTU limits. Packet size is left to the implementation to consider transport/network factors such as MTU limitations.
The damaged-KLVunit rules are defined to apply regardless of the M-bit value of the lost packet itself, enabling very basic receivers to look solely at the M-bit to determine the outer boundaries of damaged KLVunits without needing to track lost-packet M-bit state.
The marker bit is used to demarcate KLVunit boundaries so that receivers can pass a KLVunit for parsing/decoding immediately upon receipt of the last RTP packet, rather than waiting for the next packet with a different timestamp to signal the end of a KLVunit.
The payload format uses only standard RTP headers and defines no payload headers, maintaining simplicity while still providing robust carriage. All forms of SMPTE ST 336 data can be carried without restriction on which KLV data keys are used.
Data items in application/smpte336m can be very diverse; receivers might only be capable of interpreting a subset of possible data items, and unrecognized items are skipped. Agreement on data items to be used is typically done out of band via an application profile.
The application/smpte336m media type is only defined for transfer via RTP (RFC 3550). Transport within other framing protocols is not defined.
This payload format has no configuration or optional format parameters, so there are no specific Offer/Answer or declarative SDP considerations when offering SMPTE ST 336 data over RTP.
An RTP packet payload SHALL contain one, and only one, KLVunit or a fragment thereof.
Receivers MAY drop damaged KLVunits entirely, since some implementations may be particularly limited in their capacity to handle them.
Receivers SHOULD place limits on resource allocation within the bounds set forth by any application profile in use, to prevent denial-of-service attacks via pathological data with large encoded data items.
Senders MUST set the RTP header marker bit (M) to '1' for any RTP packet that contains the final byte of a KLVunit. For all other packets, senders MUST set the marker bit to '0'.
The contents of a compound KLV item (sets, packs) MUST NOT be split across two KLVunits.
The mapping of the application/smpte336m media type and its parameters to SDP SHALL be done according to Section 3 of RFC 4855.
When a KLVunit spans multiple RTP packets, the KLVunit data MUST be sent in sequential byte order such that concatenating payloads in sequence-number order exactly reproduces the original KLVunit.
When a lost RTP packet is detected, the receiver MUST consider the first KLVunit received after the lost packet as damaged, including all packets up to and including the next one with the M-bit set to '1'.
When one KLVunit is placed in multiple RTP packets, the RTP timestamp of all packets comprising that KLVunit MUST be the same.
A KLV item consists of a Universal Label Key (fixed-length 16-byte SMPTE-administered Universal Label), a Length field, and a Value field, as defined in SMPTE ST 336. The Key identifies the data, the Length specifies the data length, and the Value is the data itself.
A KLVunit is a logical collection of all KLV items to be presented at a specific time, comprised of one or more KLV items. Multiple KLV items occur one after another with no padding or stuffing between items. Compound items (sets, packs) are allowed but must not be split across two KLVunits.
The media type application/smpte336m has one required parameter: 'rate', the RTP timestamp clock rate, typically chosen based on the sampling rate of the metadata being transmitted. No optional parameters are defined.
IANA registered the media type application/smpte336m and added it to the 'RTP Payload Format media types' registry. The type name is 'application', subtype 'smpte336m', with required parameter 'rate' for RTP timestamp clock rate.
Because SMPTE ST 336 encoded data item lengths are essentially unbounded, receivers must take care when allocating resources during processing. Pathological data can cause naive decoders to allocate large amounts of resources, resulting in denial-of-service threats.
Individual SMPTE ST 336 KLV items could convey active content in a particular application. Accepting active content from streams lacking authenticity or integrity protection risks attacks using spoofed packets; receivers incapable of decoding such items are not at risk since unknown items are skipped per SMPTE ST 336 rules.
SRTP (RFC 3711) is recommended as the security mechanism for this payload format to provide confidentiality, integrity protection, and source authentication. IPsec (RFC 4301) and TLS (RFC 5246, RTP over TCP) are also viable alternatives.
The first byte of the RTP packet payload is the first byte of a KLVunit, which is the first byte of a KLV Universal Label Key (16 bytes). No payload headers are defined; only standard RTP headers are used.