idnits 2.17.1 draft-ietf-payload-rtp-ancillary-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BT1120' -- Possible downref: Non-RFC (?) normative reference: ref. 'BT1700' -- Possible downref: Non-RFC (?) normative reference: ref. 'ST291' -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 A/V Transport Payloads Working Group T. Edwards 3 Internet-Draft FOX 4 Intended status: Standards Track October 5, 2016 5 Expires: April 8, 2017 7 RTP Payload for SMPTE ST 291 Ancillary Data 8 draft-ietf-payload-rtp-ancillary-06 10 Abstract 12 This memo describes an RTP Payload format for SMPTE Ancillary data, 13 as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used 14 along with professional video formats to carry a range of ancillary 15 data types, including time code, Closed Captioning, and the Active 16 Format Description (AFD). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 8, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 3 55 2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5 56 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 57 3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 58 3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 10 59 3.2.1. Grouping ANC data RTP Streams with Associated Video 60 Streams . . . . . . . . . . . . . . . . . . . . . . . 11 61 3.3. Offer/Answer Model and Declarative Considerations . . . . 11 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 6.2. Informative References . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 This memo describes an RTP Payload format for the Society of Motion 72 Picture and Television Engineers (SMPTE) Ancillary data (ANC), as 73 defined by SMPTE ST 291-1 [ST291]. ANC data is transmitted in the 74 ancillary space of serial digital video interfaces, the space outside 75 of the active video region of images intended for users to view. 76 Ancillary space roughly corresponds to vertical and horizontal 77 blanking periods required by cathode ray tube type displays. ANC can 78 carry a range of data types, including time code, Closed Captioning, 79 and the Active Format Description (AFD). 81 ANC is generally associated with the carriage of metadata within the 82 bit stream of a Serial Digital Interface (SDI) such as SMPTE ST 259 83 [ST259], the standard definition (SD) Serial Digital Interface (with 84 ANC data inserted as per SMPTE ST 125 [ST125]), or SMPTE ST 292-1 85 [ST292], the 1.5 Gb/s Serial Digital Interface for high definition 86 (HD) television applications. 88 ANC data packet payload definitions for a specific application are 89 specified by a SMPTE Standard, Recommended Practice, Registered 90 Disclosure Document, or by a document generated by another 91 organization, a company, or an individual (an Entity). When a 92 payload format is registered with SMPTE, an application document 93 describing the payload format is required, and the registered 94 ancillary data packet is identified by a registered data 95 identification word. 97 This memo describes an RTP payload that supports ANC data packets 98 regardless of whether they originate from an SD or HD interface, or 99 if the ANC data packet is from the vertical ancillary space (VANC) or 100 the horizontal ancillary space (HANC), or if the ANC packet is 101 located in the luma (Y) or color-difference (C) channel. Sufficient 102 information is provided to enable the ANC data packets at the output 103 of the decoder to be restored to their original locations in the 104 serial digital video signal raster (if that is desired). Optional 105 Media Type parameters allow for signaling of carriage of one or more 106 types of ANC data as specified by Data Identification (DID) or 107 Secondary Data Identification (SDID) words. 109 It should be noted that the ancillary data flag (ADF) word is not 110 specifically carried in this RTP payload. The ADF may be specified 111 in a document defining an interconnecting digital video interface, 112 otherwise a default ADF is specified by SMPTE ST 291-1 [ST291]. 114 This ANC payload can be used by itself, or used along with a range of 115 RTP video formats. In particular, it has been designed so that it 116 could be used along with RFC 4175 [RFC4175] "RTP Payload Format for 117 Uncompressed Video" or RFC 5371 [RFC5371] "RTP Payload Format for 118 JPEG 2000 Video Streams." 120 The data model in this document for the ANC data RTP payload is based 121 on the data model of SMPTE ST 2038 [ST2038], which standardizes the 122 carriage of ANC data packets in an MPEG-2 Transport Stream. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. RTP Payload Format for SMPTE ST 291 Ancillary Data 132 The format of an RTP packet containing SMPTE ST 291 Ancillary Data is 133 shown below: 135 0 1 2 3 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |V=2|P|X| CC |M| PT | sequence number | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | timestamp | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | synchronization source (SSRC) identifier | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Extended Sequence Number | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | ANC_Count |C| Line_Number | Horizontal_Offset | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | DID | SDID | Data_Count | R | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | User_Data_Words... 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Checksum_Word | word_align | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | (next ANC data packet)... 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: SMPTE Ancillary Data RTP Packet Format 159 RTP packet header fields SHALL be interpreted as per RFC 3550 160 [RFC3550], with the following specifics: 162 Timestamp: 32 bits 163 The timestamp field is interpreted in a similar fashion to 164 RFC 4175 [RFC4175]: 166 For progressive scan video, the timestamp denotes the 167 sampling instant of the frame to which the ancillary data in 168 the RTP packet belongs. RTP packets MUST NOT include ANC 169 data from multiple frames, and all RTP packets with ANC data 170 belonging to the same frame MUST have the same timestamp. 172 For interlaced video, the timestamp denotes the sampling 173 instant of the field to which the ancillary data in the RTP 174 packet belongs. RTP packets MUST NOT include ANC data from 175 multiple fields, and all RTP packets belonging to the same 176 field MUST have the same timestamp. 178 If the sampling instant does not correspond to an integer 179 value of the clock, the value SHALL be truncated to the next 180 lowest integer, with no ambiguity. Section 3.1 describes 181 recommended timestamp clock rates. 183 Marker bit (M): 1 bit 184 The marker bit set to "1" indicates the last ANC RTP packet 185 for a frame (for progressive scan video) or the last ANC RTP 186 packet for a field (for interlaced video). 188 2.1. Payload Header Definitions 190 The ANC RTP payload header fields are defined as: 192 Extended Sequence Number: 16 bits 193 The high order bits of the extended 32-bit sequence number, 194 in network byte order. This is the same as the Extended 195 Sequence Number field in RFC 4175 [RFC4175]. 197 Length: 16 bits 198 Number of octets of the ANC RTP payload, beginning with the 199 "C" bit of the first ANC packet data, as an unsigned integer 200 in network byte order. 202 ANC_Count: 8 bits 203 This field is the count of the total number of ANC data 204 packets carried in the RTP payload, as an unsigned integer in 205 network byte order. A single ANC RTP packet payload cannot 206 carry more than 255 ANC data packets. 208 If more than 255 ANC data packets need to be carried in a 209 field or frame, additional RTP packets carrying ANC data MAY 210 be sent with the same RTP timestamp but with different 211 sequence numbers. ANC_Count of 0 indicates that there are no 212 ANC data packets in the payload (for example, for an RTP 213 packet with the marker bit set indicating the last ANC RTP 214 packet in a field/frame, even if that RTP packet carries no 215 actual ANC data packets.) 217 For each ANC data packet in the payload, the following ANC data 218 packet header fields MUST be present: 220 C: 1 bit 221 For HD signals, this flag, when set to "1", indicates that 222 the ANC data corresponds to the color-difference channel (C). 223 When set to "0", this flag indicates that the ANC data 224 corresponds to the luma (Y) channel. For SD signals, this 225 flag SHALL be set to "0". 227 Line_Number: 11 bits 228 This field contains the line number (as defined in ITU-R 229 BT.1700 [BT1700] for SD video or ITU-R BT.1120 [BT1120] for 230 HD video) that corresponds to the location of the ANC data 231 packet in an SDI raster as an unsigned integer in network 232 byte order. A value of 0x7FF (all bits in the field are '1') 233 SHALL indicate that the ANC data is carried without a 234 specific line location within the field or frame. 236 Note that the lines that are available to convey ANC data are 237 as defined in the applicable sample structure specification 238 (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656 239 [BT656]) and may be further restricted per SMPTE RP 168 240 [RP168]. 242 Horizontal_Offset: 12 bits 243 This field defines the location of the ANC data packet in an 244 SDI raster relative to the start of active video (SAV) as an 245 unsigned integer in network byte order. A value of 0 means 246 that that within the original SDI signal, the Ancillary Data 247 Flag (ADF) of the ANC data packet begins immediately 248 following SAV. For HD, this is in units of luma sample 249 numbers as specified by the defining document of the 250 particular image (e.g., SMPTE 274M [ST274] for 1920 x 1080 251 active images, or SMPTE ST 296 [ST296] for 1280 x 720 252 progressive active images). For SD, this is in units of 253 (27MHz) multiplexed word numbers, as specified in SMPTE ST 254 125 [ST125]. A value of 0xFFF (all bits in the field are 255 '1') indicates that the ANC data is carried without any 256 specific location within the line. 258 Note that HANC space in the digital blanking area will 259 generally have higher luma sample numbers than any samples in 260 the active digital line. 262 An ANC data packet with the header fields Line_Number of 0x7FF and 263 Horizontal_Offset of 0xFFF SHALL be considered to be carried without 264 any specific location within the field or frame, and in such a case 265 the "C" field SHALL be ignored. 267 For each ANC data packet in the payload, immediately after the ANC 268 data packet header fields, the following data fields MUST be present, 269 with the fields DID, SDID, Data_Count, User_Data_Words, and 270 Checksum_Word representing the 10-bit words carried in the ANC data 271 packet, as per SMPTE ST 291-1 [ST291]: 273 DID: 10 bits 274 Data Identification Word 276 SDID: 10 bits 277 Secondary Data Identification Word. Used only for a "Type 2" 278 ANC data packet. Note that in a "Type 1" ANC data packet, 279 this word will actually carry the Data Block Number (DBN). 281 Data_Count: 10 bits 282 The lower 8 bits of Data_Count, corresponding to bits b7 283 (MSB) through b0 (LSB) of the 10-bit Data_Count word, contain 284 the actual count of 10-bit words in User_Data_Words. Bit b8 285 is the even parity for bits b7 through b0, and bit b9 is the 286 inverse (logical NOT) of bit b8. 288 R: 2 reserved bits 289 R is a field of two reserved bits that MUST be set to zero. 291 User_Data_Words: integer number of 10 bit words 292 User_Data_Words (UDW) are used to convey information of a 293 type as identified by the DID word or the DID and SDID words. 294 The number of 10-bit words in the UDW is defined by the 295 Data_Count field. 297 Checksum_Word: 10 bits 298 The Checksum_Word can be used to determine the validity of 299 the ANC data packet from the DID word through the UDW. It 300 consists of 10 bits, where bits b8 (MSB) through b0 (LSB) 301 define the checksum value and bit b9 is the inverse (logical 302 NOT) of bit b8. The checksum value is equal to the nine 303 least significant bits of the sum of the nine least 304 significant bits of the DID word, the SDID word, the 305 Data_Count word, and all User_Data_Words in the ANC data 306 packet. The checksum is initialized to zero before 307 calculation, and any end carry resulting from the checksum 308 calculation is ignored. 310 word_align: bits as needed to complete 32-bit word 311 Word align contains enough "0" bits as needed to complete the 312 last 32-bit word of ANC packet's data in the RTP payload. If 313 an ANC data packet in the RTP payload ends aligned with a 314 word boundary, there is no need to add any word alignment 315 bits. Word align should be used even for the last ANC data 316 packet in an RTP packet. 318 When reconstructing an SDI signal based on this payload, it is 319 important to place ANC data packets into the locations indicated by 320 the ANC payload header fields Line_Number and Horizontal_Offset, and 321 also to follow the requirements of SMPTE ST 291-1 [ST291] Section 7 322 "Ancillary Data Space Formatting (Component or Composite Interface)", 323 which include rules on the placement of initial ANC data into allowed 324 spaces as well as the contiguity of ANC data packet sequences within 325 those spaces in order to assure that the resulting ANC data packets 326 in the SDI signal are valid. 328 Senders of this payload SHOULD transmit available ANC data packets as 329 soon as practical to reduce end-to-end latency, especially if 330 receivers will be embedding the received ANC data packet into an SDI 331 signal emission. One millisecond is a reasonable upper bound for the 332 amount of time between when an ANC data packet becomes available to a 333 sender and the emission of an RTP payload containing that ANC data 334 packet. 336 ANC data packets with headers that specify specific location within a 337 field or frame SHOULD be sent in raster scan order, both in terms of 338 packing position within an RTP packet and in terms of transmission 339 time of RTP packets. 341 3. Payload Format Parameters 343 This RTP payload format is identified using the video/smpte291 media 344 type, which is registered in accordance with RFC 4855 [RFC4855], and 345 using the template of RFC 6838 [RFC6838]. 347 Note that the Media Type Definition is in the "video" tree due to the 348 expected use of SMPTE ST 291 Ancillary Data along with video formats. 350 3.1. Media Type Definition 352 Type name: video 354 Subtype name: smpte291 356 Required parameters: 358 Rate: RTP timestamp clock rate. When an ANC RTP stream is to be 359 associated with an RTP video stream, the RTP timestamp rates 360 SHOULD be the same to ensure that ANC data packets can be 361 associated with the appropriate frame or field. Otherwise, a 90 362 kHz rate SHOULD be used. 364 Note that techniques described in RFC 7273 [RFC7273] can provide a 365 common reference clock for multiple RTP streams intended for 366 synchronized presentation. 368 Optional parameters: 370 DID_SDID: Data identification and Secondary data identification 371 words. 373 The presence of the DID_SDID parameters signals that all ancillary 374 data packets of this stream are of a particular type or types, 375 i.e., labeled with a particular DIDs and SDIDs. DID and SDID 376 values of SMPTE Registered ANC packet types can be found on the at 377 the SMPTE Registry for Data Identification Word Assignments 378 [SMPTE-RA] web site. 380 "Type 1" ANC packets (which do not have SDIDs defined) SHALL be 381 labeled with SDID=0x00. 383 DID and SDID values can be registered with SMPTE as per SMPTE ST 384 291-1 [ST291]. 386 Encoding considerations: This media type is framed and binary; see 387 Section 4.8 of RFC 6838 [RFC6838]. 389 Security considerations: See Section 5 of [this RFC] 391 Interoperability considerations: Data items in smpte291 can be very 392 diverse. Receivers might only be capable of interpreting a subset of 393 the possible data items. Some implementations may care about the 394 location of the ANC data packets in the SDI raster, but other 395 implementations may not care. 397 Published specification: [this RFC] 399 Applications that use this media type: Devices that stream real-time 400 professional video, especially those that must interoperate with 401 legacy serial digital interfaces (SDI). 403 Additional Information: 405 Deprecated alias names for this type: N/A 407 Magic number(s): N/A 409 File extension(s): N/A 411 Macintosh file type code(s): N/A 413 Person & email address to contact for further information: T. 414 Edwards , IETF Payload Working Group 415 417 Intended usage: COMMON 418 Restrictions on usage: This media type depends on RTP framing, and 419 hence is only defined for transfer via RTP RFC 3550 [RFC3550]. 420 Transport within other framing protocols is not defined at this time. 422 Author: T. Edwards 424 Change controller: The IETF PAYLOAD working group, or other party as 425 designated by the IESG. 427 3.2. Mapping to SDP 429 The mapping of the above defined payload format media type and its 430 parameters SHALL be done according to Section 3 of RFC 4855 431 [RFC4855]. 433 o The type name ("video") goes in SDP "m=" as the media name. 435 o The subtype name ("smpte291") goes in SDP "a=rtpmap" as the 436 encoding name, followed by a slash ("/") and the required rate 437 parameter. 439 o The optional DID_SDID parameters go in the SDP "a=fmtp" attribute 440 as a semicolon-separated list of parameter=value pairs. 442 DID and SDID values SHALL be specified in hexadecimal with a "0x" 443 prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the 444 fmtp line shall be: 446 TwoHex = "0x" 1*2(HEXDIG) 447 DidSdid = "DID_SDID={" TwoHex "," TwoHex "}" 448 FormatSpecificParameters = DidSdid *(";" DidSdid) 450 For example, EIA 608 Closed Caption data would be signalled with the 451 parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not 452 specified, then the ancillary data stream may potentially contain 453 ancillary data packets of any type. 455 Multiple DID_SDID parameters may be specified (separated by 456 semicolons) to signal the presence of multiple types of ANC data in 457 the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example, 458 signals the presence of EIA 608 Closed Captions as well as AFD/Bar 459 Data. 461 A sample SDP mapping for ancillary data is as follows: 463 m=video 30000 RTP/AVP 112 464 a=rtpmap:112 smpte291/90000 465 a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05} 467 In this example, a dynamic payload type 112 is used for ancillary 468 data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" 469 line after the subtype. The RTP sampling clock is 90 kHz. In the 470 "a=fmtp:" line, DID 0x61 and SDID 0x02 are specified (registered to 471 EIA 608 Closed Caption Data by SMPTE), and also DID 0x41 and SDID 472 0x05 (registered to AFD/Bar Data). 474 3.2.1. Grouping ANC data RTP Streams with Associated Video Streams 476 The ANC RTP payload format will often be used in groupings with 477 associated video streams. Any legal SDP grouping mechanism could be 478 used. Implementers may wish to use the Lip Synchronization (LS) 479 grouping defined in RFC 5888 [RFC5888], which requires that "m" lines 480 that are grouped together using LS semantics MUST synchronize the 481 playout of the corresponding media streams. 483 A sample SDP mapping for grouping ANC data with RFC 4175 video using 484 LS semantics is as follows: 486 v=0 487 o=Al 123456 11 IN IP4 host.example.com 488 s=Professional Networked Media Test 489 i=A test of synchronized video and ANC data 490 t=0 0 491 a=group:LS V1 M1 492 m=video 50000 RTP/AVP 96 493 c=IN IP4 233.252.0.1/255 494 a=rtpmap:96 raw/90000 495 a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10 496 a=mid:V1 497 m=video 50010 RTP/AVP 97 498 c=IN IP4 233.252.0.2/255 499 a=rtpmap:97 smpte291/90000 500 a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05} 501 a=mid:M1 503 3.3. Offer/Answer Model and Declarative Considerations 505 Receivers may with to receive ANC data streams with specific DID_SDID 506 parameters. Thus when offering ANC data streams using the Session 507 Description Protocol (SDP) in an Offer/Answer model [RFC3264] or in a 508 declarative manner (e.g., SDP in the Real-Time Streaming Protocol 509 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 510 [RFC2974]), the offerer may provide a list of ANC streams available 511 with specific DID_SDID parameters in the fmtp line. The answerer may 512 respond with a all or a subset of the streams offered along with fmtp 513 lines with all or a subset of the DID_SDID parameters offered. Or 514 the answerer may reject the offer. 516 4. IANA Considerations 518 One media type (video/smpte291) has been defined and needs 519 registration in the media types registry. See Section 3.1 521 5. Security Considerations 523 RTP packets using the payload format defined in this specification 524 are subject to the security considerations discussed in the RTP 525 specification [RFC3550], and in any applicable RTP profile such as 526 RTP/AVP [RFC3551], RTP/AVPF [RFC4585] RTP/SAVP [RFC3711] or RTP/SAVPF 527 [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP 528 Does Not Mandate a Single Media Security Solution" [RFC7202] 529 discusses, it is not an RTP payload format's responsibility to 530 discuss or mandate what solutions are used to meet the basic security 531 goals like confidentiality, integrity and source authenticity for RTP 532 in general. This responsibility lays on anyone using RTP in an 533 application. They can find guidance on available security mechanisms 534 and important considerations in Options for Securing RTP Sessions 535 [RFC7201]. Applications SHOULD use one or more appropriate strong 536 security mechanisms. The rest of this security consideration section 537 discusses the security impacting properties of the payload format 538 itself. 540 To avoid potential buffer overflow attacks, receivers should take 541 care to validate that the ANC data packets in the RTP payload are of 542 the appropriate length (using the Data_Count field) for the ANC data 543 type specified by DID & SDID. Also the Checksum_Word should be 544 checked against the ANC data packet to ensure that its data has not 545 been damaged in transit. 547 Some receivers will simply move the ANC data packet bits from the RTP 548 payload into a serial digital interface (SDI). It may still be a 549 good idea for these "re-embedders" to perform the above mentioned 550 validity tests to avoid downstream SDI systems from becoming confused 551 by bad ANC data packets, which could be used for a denial of service 552 attack. 554 "Re-embedders" into SDI should also double check that the Line_Number 555 and Horizontal_Offset leads to the ANC data packet being inserted 556 into a legal area to carry ancillary data in the SDI video bit stream 557 of the output video format. 559 6. References 560 6.1. Normative References 562 [BT1120] ITU-R, "BT.1120-8, Digital Interfaces for HDTV Studio 563 Signals", January 2012. 565 [BT1700] ITU-R, "BT.1700, Characteristics of Composite Video 566 Signals for Conventional Analogue Television Systems", 567 February 2005. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 575 with Session Description Protocol (SDP)", RFC 3264, 576 DOI 10.17487/RFC3264, June 2002, 577 . 579 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 580 Jacobson, "RTP: A Transport Protocol for Real-Time 581 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 582 July 2003, . 584 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 585 Video Conferences with Minimal Control", STD 65, RFC 3551, 586 DOI 10.17487/RFC3551, July 2003, 587 . 589 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 590 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 591 RFC 3711, DOI 10.17487/RFC3711, March 2004, 592 . 594 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 595 "Extended RTP Profile for Real-time Transport Control 596 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 597 DOI 10.17487/RFC4585, July 2006, 598 . 600 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 601 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 602 . 604 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 605 Real-time Transport Control Protocol (RTCP)-Based Feedback 606 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 607 2008, . 609 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 610 Specifications: ABNF", STD 68, RFC 5234, 611 DOI 10.17487/RFC5234, January 2008, 612 . 614 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 615 Protocol (SDP) Grouping Framework", RFC 5888, 616 DOI 10.17487/RFC5888, June 2010, 617 . 619 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 620 Specifications and Registration Procedures", BCP 13, 621 RFC 6838, DOI 10.17487/RFC6838, January 2013, 622 . 624 [ST291] SMPTE, "ST 291-1:2011, Ancillary Data Packet and Space 625 Formatting", 2011. 627 6.2. Informative References 629 [BT656] ITU-R, "BT.656-5, Interfaces for Digital Component Video 630 Signals in 525-Line and 625-Line Television Systems 631 Operating at the 4:2:2 Level of Recommendation ITU-R 632 BT.601", December 2007. 634 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 635 Streaming Protocol (RTSP)", RFC 2326, 636 DOI 10.17487/RFC2326, April 1998, 637 . 639 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 640 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 641 October 2000, . 643 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 644 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 645 September 2005, . 647 [RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload 648 Format for JPEG 2000 Video Streams", RFC 5371, 649 DOI 10.17487/RFC5371, October 2008, 650 . 652 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 653 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 654 . 656 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 657 Framework: Why RTP Does Not Mandate a Single Media 658 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 659 2014, . 661 [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. 662 Stokking, "RTP Clock Source Signalling", RFC 7273, 663 DOI 10.17487/RFC7273, June 2014, 664 . 666 [RP168] SMPTE, "RP 168:2009, Definition of Vertical Interval 667 Switching Point for Synchronous Video Switching", 2009. 669 [SMPTE-RA] 670 SMPTE Registration Authority, LLC, "SMPTE ST 291 Ancillary 671 Data Identification Word Assignments for Registered DIDs", 672 2011, . 675 [ST125] SMPTE, "ST 125:2013, SDTV Component Video Signal Coding 676 4:4:4 and 4:2:2 for 13.5 MHz and 18 MHz Systems", 2013. 678 [ST2038] SMPTE, "ST 2038:2008, Carriage of Ancillary Data Packets 679 in an MPEG-2 Transport Stream", 2008. 681 [ST259] SMPTE, "ST 259:2008, SDTV Digital Signal/Data - Serial 682 Digital Interface", 2008. 684 [ST274] SMPTE, "ST 274:2008, 1920 x 1080 Image Sample Structure, 685 Digital Representation and Digital Timing Reference 686 Sequences for Multiple Picture Rates", 2008. 688 [ST292] SMPTE, "ST 292-1:2012, 1.5 Gb/s Signal/Data Serial 689 Interface", 2012. 691 [ST296] SMPTE, "ST 296:2012, 1280 x 720 Progressive Image 4:2:2 692 and 4:4:4 Sample Structure - Analog and Digital 693 Representation and Analog Interface", 2012. 695 Author's Address 696 Thomas G. Edwards 697 FOX 698 10201 W. Pico Blvd. 699 Los Angeles, CA 90035 700 USA 702 Phone: +1 310 369 6696 703 Email: thomas.edwards@fox.com