1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>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
<span class="h1">RTP Payload Format for</span>
<span class="h1">Society of Motion Picture and Television Engineers (SMPTE)</span>
<span class="h1">ST 336 Encoded Data</span>
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).
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6597">http://www.rfc-editor.org/info/rfc6597</a>.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Downs & Arbeiter Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions, Definitions, and Acronyms ..........................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Media Format Background .........................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Payload Format ..................................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. RTP Header Usage ...........................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Payload Data ...............................................<a href="#page-5">5</a>
<a href="#section-4.2.1">4.2.1</a>. The KLVunit .........................................<a href="#page-5">5</a>
<a href="#section-4.2.2">4.2.2</a>. KLVunit Mapping to RTP Packet Payload ...............<a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. Implementation Considerations ..............................<a href="#page-6">6</a>
<a href="#section-4.3.1">4.3.1</a>. Loss of Data ........................................<a href="#page-6">6</a>
<a href="#section-4.3.1.1">4.3.1.1</a>. Damaged KLVunits ...........................<a href="#page-7">7</a>
<a href="#section-4.3.1.2">4.3.1.2</a>. Treatment of Damaged KLVunits ..............<a href="#page-9">9</a>
<a href="#section-5">5</a>. Congestion Control ..............................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Payload Format Parameters .......................................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Media Type Definition ......................................<a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Mapping to SDP ............................................<a href="#page-10">10</a>
<a href="#section-6.2.1">6.2.1</a>. Offer/Answer Model and Declarative Considerations ..10
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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 [<a href="#ref-SMPTE-ST336" title=""SMPTE ST 336:2007 Data Encoding Protocol Using Key- Length-Value"">SMPTE-ST336</a>], into the
Real-time Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
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.
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 <a href="#section-4">Section 4</a>. The media
type and IANA considerations are also described. This document
concludes with security considerations relevant to this payload
format.
<span class="grey">Downs & Arbeiter Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions, Definitions, and Acronyms</span>
The term "Universal Label Key" is used in this document to refer to a
fixed-length, 16-byte SMPTE-administered Universal Label (see
[<a href="#ref-SMPTE-ST298" title=""SMPTE ST 298:2009 Universal Labels for Unique Identification of Digital Data"">SMPTE-ST298</a>]) that is used as an identifying key in a KLV item.
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 [<a href="#ref-SMPTE-ST336" title=""SMPTE ST 336:2007 Data Encoding Protocol Using Key- Length-Value"">SMPTE-ST336</a>].
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Media Format Background</span>
[<a href="#ref-SMPTE-ST336" title=""SMPTE ST 336:2007 Data Encoding Protocol Using Key- Length-Value"">SMPTE-ST336</a>], "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 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.
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.
The Key of a KLV triplet (a Universal Label Key) is coded using a
fixed-length 16-byte SMPTE-administered Universal Label.
[<a href="#ref-SMPTE-ST298" title=""SMPTE ST 298:2009 Universal Labels for Unique Identification of Digital Data"">SMPTE-ST298</a>] further details the structure of 16-byte SMPTE-
administered Universal Labels. Universal Label Keys are maintained
in registries published by SMPTE (see, for example, [<a href="#ref-SMPTE-ST335" title=""SMPTE ST 335:2012 Metadata Element Dictionary Structure"">SMPTE-ST335</a>] and
[<a href="#ref-SMPTE-RP210" title=""SMPTE RP 210v12:2010 Data Element Dictionary"">SMPTE-RP210</a>]).
<span class="grey">Downs & Arbeiter Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
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.
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Payload Format</span>
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 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 <a href="#section-4.2.1">Section 4.2.1</a>). 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.
<span class="grey">Downs & Arbeiter Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. RTP Header Usage</span>
This payload format uses the RTP packet header fields as described in
the table below:
+-----------+-------------------------------------------------------+
| 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 |
| | (<a href="#section-6">Section 6</a>). |
| | |
| 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 [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Payload Data</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. The KLVunit</span>
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
[<a href="#ref-SMPTE-ST336" title=""SMPTE ST 336:2007 Data Encoding Protocol Using Key- Length-Value"">SMPTE-ST336</a>], 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.
<span class="grey">Downs & Arbeiter Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. KLVunit Mapping to RTP Packet Payload</span>
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.
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.
Additionally, when a KLVunit is fragmented across multiple RTP
packets, all RTP packets transporting the fragments of a KLVunit MUST
have the same timestamp.
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 <a href="#section-4.1">Section 4.1</a>).
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Implementation Considerations</span>
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Loss of Data</span>
RTP is generally deployed in network environments where packet loss
might occur. RTP header fields enable detection of lost packets, as
described in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. When transmitting payload data described by
this payload format, packet loss can cause the loss of whole KLVunits
or portions thereof.
<span class="grey">Downs & Arbeiter Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h5"><a class="selflink" id="section-4.3.1.1" href="#section-4.3.1.1">4.3.1.1</a>. Damaged KLVunits</span>
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
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 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'.
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').
<span class="grey">Downs & Arbeiter Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
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.
<span class="grey">Downs & Arbeiter Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h5"><a class="selflink" id="section-4.3.1.2" href="#section-4.3.1.2">4.3.1.2</a>. Treatment of Damaged KLVunits</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Congestion Control</span>
The general congestion control considerations for transporting RTP
data apply; see RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any applicable RTP profile, like
AVP [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>].
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Payload Format Parameters</span>
This RTP payload format is identified using the application/smpte336m
media type, which is registered in accordance with [<a href="./rfc4855" title=""Media Type Registration of RTP Payload Formats"">RFC4855</a>], and
using the template of [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>].
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Media Type Definition</span>
Type name: application
Subtype name: smpte336m
Required parameters:
rate: RTP timestamp clock rate. Typically chosen based on
sampling rate of metadata being transmitted, but other rates
can be specified.
Optional parameters: None
Encoding considerations: This media type is framed and binary; see
<a href="./rfc4288#section-4.8">Section 4.8 of [RFC4288]</a>.
Security considerations: See <a href="./rfc6597#section-8">Section 8 of RFC 6597</a>.
<span class="grey">Downs & Arbeiter Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
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.
Published specification: <a href="./rfc6597">RFC 6597</a>
Applications that use this media type: Streaming of metadata
associated with simultaneously streamed video and transmission of
[<a href="#ref-SMPTE-ST336" title=""SMPTE ST 336:2007 Data Encoding Protocol Using Key- Length-Value"">SMPTE-ST336</a>]-based media formats (e.g., Material Exchange Format
(MXF) [<a href="#ref-SMPTE-ST377" title=""SMPTE ST 377-1:2011 Material Exchange Format (MXF) - File Format Specification"">SMPTE-ST377</a>]).
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
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP ([<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]). Transport
within other framing protocols is not defined at this time.
Author:
J. Downs <jeff_downs@partech.com>
J. Arbeiter <jimsgti@gmail.com>
Change controller: IETF Payload working group delegated from the
IESG.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Mapping to SDP</span>
The mapping of the above defined payload format media type and its
parameters SHALL be done according to <a href="./rfc4855#section-3">Section 3 of [RFC4855]</a>.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Offer/Answer Model and Declarative Considerations</span>
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
[<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>] or in a declarative manner (e.g., SDP in the Real-Time
Streaming Protocol (RTSP) [<a href="./rfc2326" title=""Real Time Streaming Protocol (RTSP)"">RFC2326</a>] or the Session Announcement
Protocol (SAP) [<a href="./rfc2974" title=""Session Announcement Protocol"">RFC2974</a>]), there are no specific considerations.
<span class="grey">Downs & Arbeiter Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has registered application/smpte336m as specified in
<a href="#section-6.1">Section 6.1</a>. The media type has been added to the IANA registry for
"RTP Payload Format media types"
(<a href="http://www.iana.org/assignments/rtp-parameters">http://www.iana.org/assignments/rtp-parameters</a>).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>], 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.
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) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]
is recommended. Other mechanisms that may be used are IPsec
[<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] and Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] (RTP over
TCP), but other alternatives may exist as well.
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.
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
<span class="grey">Downs & Arbeiter Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC3551">RFC3551</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
<a href="./rfc3551">RFC 3551</a>, July 2003.
[<a id="ref-RFC4288">RFC4288</a>] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>,
December 2005.
[<a id="ref-RFC4855">RFC4855</a>] Casner, S., "Media Type Registration of RTP Payload
Formats", <a href="./rfc4855">RFC 4855</a>, February 2007.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC2326">RFC2326</a>] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.
[<a id="ref-RFC2974">RFC2974</a>] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", <a href="./rfc2974">RFC 2974</a>, October 2000.
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
<a href="./rfc3264">RFC 3264</a>, June 2002.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", <a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
<span class="grey">Downs & Arbeiter Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6597">RFC 6597</a> RTP Format for SMPTE ST 336 Data April 2012</span>
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
August 2008.
[<a id="ref-SMPTE-RP210">SMPTE-RP210</a>] Society of Motion Picture and Television Engineers,
"SMPTE RP 210v12:2010 Data Element Dictionary", 2010,
<<a href="http://www.smpte-ra.org/mdd/">http://www.smpte-ra.org/mdd/</a>>.
[<a id="ref-SMPTE-ST298">SMPTE-ST298</a>] Society of Motion Picture and Television Engineers,
"SMPTE ST 298:2009 Universal Labels for Unique
Identification of Digital Data", 2009,
<<a href="http://www.smpte.org">http://www.smpte.org</a>>.
[<a id="ref-SMPTE-ST335">SMPTE-ST335</a>] Society of Motion Picture and Television Engineers,
"SMPTE ST 335:2012 Metadata Element Dictionary
Structure", 2012, <<a href="http://www.smpte.org">http://www.smpte.org</a>>.
[<a id="ref-SMPTE-ST336">SMPTE-ST336</a>] Society of Motion Picture and Television Engineers,
"SMPTE ST 336:2007 Data Encoding Protocol Using Key-
Length-Value", 2007, <<a href="http://www.smpte.org">http://www.smpte.org</a>>.
[<a id="ref-SMPTE-ST377">SMPTE-ST377</a>] Society of Motion Picture and Television Engineers,
"SMPTE ST 377-1:2011 Material Exchange Format (MXF) -
File Format Specification", 2011,
<<a href="http://www.smpte.org">http://www.smpte.org</a>>.
Authors' Addresses
J. Downs (editor)
PAR Government Systems Corp.
US
EMail: jeff_downs@partech.com
J. Arbeiter (editor)
US
EMail: jimsgti@gmail.com
Downs & Arbeiter Standards Track [Page 13]
</pre>
|
