Skip to main content

RTP Payload for SMPTE ST 291 Ancillary Data
draft-ietf-payload-rtp-ancillary-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8331.
Author Thomas Edwards
Last updated 2016-12-08 (Latest revision 2016-10-05)
Replaces draft-edwards-payload-rtp-ancillary
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Doc Shepherd Follow-up Underway
Document shepherd Ali C. Begen
Shepherd write-up Show Last changed 2016-08-16
IESG IESG state Became RFC 8331 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Ben Campbell
Send notices to "Ali C. Begen" <acbegen@gmail.com>
IANA IANA review state IANA OK - Actions Needed
draft-ietf-payload-rtp-ancillary-06

   In this example, a dynamic payload type 112 is used for ancillary
   data.  The 90 kHz RTP timestamp rate is specified in the "a=rtpmap"
   line after the subtype.  The RTP sampling clock is 90 kHz.  In the
   "a=fmtp:" line, DID 0x61 and SDID 0x02 are specified (registered to
   EIA 608 Closed Caption Data by SMPTE), and also DID 0x41 and SDID
   0x05 (registered to AFD/Bar Data).

3.2.1.  Grouping ANC data RTP Streams with Associated Video Streams

   The ANC RTP payload format will often be used in groupings with
   associated video streams.  Any legal SDP grouping mechanism could be
   used.  Implementers may wish to use the Lip Synchronization (LS)
   grouping defined in RFC 5888 [RFC5888], which requires that "m" lines
   that are grouped together using LS semantics MUST synchronize the
   playout of the corresponding media streams.

   A sample SDP mapping for grouping ANC data with RFC 4175 video using
   LS semantics is as follows:

        v=0
        o=Al 123456 11 IN IP4 host.example.com
        s=Professional Networked Media Test
        i=A test of synchronized video and ANC data
        t=0 0
        a=group:LS V1 M1
        m=video 50000 RTP/AVP 96
        c=IN IP4 233.252.0.1/255
        a=rtpmap:96 raw/90000
        a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
        a=mid:V1
        m=video 50010 RTP/AVP 97
        c=IN IP4 233.252.0.2/255
        a=rtpmap:97 smpte291/90000
        a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
        a=mid:M1

3.3.  Offer/Answer Model and Declarative Considerations

   Receivers may with to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams 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]), the offerer may provide a list of ANC streams available
   with specific DID_SDID parameters in the fmtp line.  The answerer may
   respond with a all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer may reject the offer.

Edwards                   Expires April 8, 2017                [Page 11]
Internet-Draft       RTP Payload for Ancillary Data         October 2016

4.  IANA Considerations

   One media type (video/smpte291) has been defined and needs
   registration in the media types registry.  See Section 3.1

5.  Security Considerations

   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 such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585] RTP/SAVP [RFC3711] or RTP/SAVPF
   [RFC5124].  However, as "Securing the RTP Protocol Framework: Why RTP
   Does Not Mandate a Single Media Security Solution" [RFC7202]
   discusses, it is not an RTP payload format's responsibility to
   discuss or mandate what solutions are used to meet the basic security
   goals like confidentiality, integrity and source authenticity for RTP
   in general.  This responsibility lays on anyone using RTP in an
   application.  They can find guidance on available security mechanisms
   and important considerations in Options for Securing RTP Sessions
   [RFC7201].  Applications SHOULD use one or more appropriate strong
   security mechanisms.  The rest of this security consideration section
   discusses the security impacting properties of the payload format
   itself.

   To avoid potential buffer overflow attacks, receivers should take
   care to validate that the ANC data packets in the RTP payload are of
   the appropriate length (using the Data_Count field) for the ANC data
   type specified by DID & SDID.  Also the Checksum_Word should be
   checked against the ANC data packet to ensure that its data has not
   been damaged in transit.

   Some receivers will simply move the ANC data packet bits from the RTP
   payload into a serial digital interface (SDI).  It may still be a
   good idea for these "re-embedders" to perform the above mentioned
   validity tests to avoid downstream SDI systems from becoming confused
   by bad ANC data packets, which could be used for a denial of service
   attack.

   "Re-embedders" into SDI should also double check that the Line_Number
   and Horizontal_Offset leads to the ANC data packet being inserted
   into a legal area to carry ancillary data in the SDI video bit stream
   of the output video format.

6.  References

Edwards                   Expires April 8, 2017                [Page 12]
Internet-Draft       RTP Payload for Ancillary Data         October 2016

6.1.  Normative References

   [BT1120]   ITU-R, "BT.1120-8, Digital Interfaces for HDTV Studio
              Signals", January 2012.

   [BT1700]   ITU-R, "BT.1700, Characteristics of Composite Video
              Signals for Conventional Analogue Television Systems",
              February 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <http://www.rfc-editor.org/info/rfc3551>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
              <http://www.rfc-editor.org/info/rfc4855>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <http://www.rfc-editor.org/info/rfc5124>.

Edwards                   Expires April 8, 2017                [Page 13]
Internet-Draft       RTP Payload for Ancillary Data         October 2016

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888,
              DOI 10.17487/RFC5888, June 2010,
              <http://www.rfc-editor.org/info/rfc5888>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <http://www.rfc-editor.org/info/rfc6838>.

   [ST291]    SMPTE, "ST 291-1:2011, Ancillary Data Packet and Space
              Formatting", 2011.

6.2.  Informative References

   [BT656]    ITU-R, "BT.656-5, Interfaces for Digital Component Video
              Signals in 525-Line and 625-Line Television Systems
              Operating at the 4:2:2 Level of Recommendation ITU-R
              BT.601", December 2007.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326,
              DOI 10.17487/RFC2326, April 1998,
              <http://www.rfc-editor.org/info/rfc2326>.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
              October 2000, <http://www.rfc-editor.org/info/rfc2974>.

   [RFC4175]  Gharai, L. and C. Perkins, "RTP Payload Format for
              Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
              September 2005, <http://www.rfc-editor.org/info/rfc4175>.

   [RFC5371]  Futemma, S., Itakura, E., and A. Leung, "RTP Payload
              Format for JPEG 2000 Video Streams", RFC 5371,
              DOI 10.17487/RFC5371, October 2008,
              <http://www.rfc-editor.org/info/rfc5371>.

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
              <http://www.rfc-editor.org/info/rfc7201>.

Edwards                   Expires April 8, 2017                [Page 14]
Internet-Draft       RTP Payload for Ancillary Data         October 2016

   [RFC7202]  Perkins, C. and M. Westerlund, "Securing the RTP
              Framework: Why RTP Does Not Mandate a Single Media
              Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
              2014, <http://www.rfc-editor.org/info/rfc7202>.

   [RFC7273]  Williams, A., Gross, K., van Brandenburg, R., and H.
              Stokking, "RTP Clock Source Signalling", RFC 7273,
              DOI 10.17487/RFC7273, June 2014,
              <http://www.rfc-editor.org/info/rfc7273>.

   [RP168]    SMPTE, "RP 168:2009, Definition of Vertical Interval
              Switching Point for Synchronous Video Switching", 2009.

   [SMPTE-RA]
              SMPTE Registration Authority, LLC, "SMPTE ST 291 Ancillary
              Data Identification Word Assignments for Registered DIDs",
              2011, <http://www.smpte-ra.org/
              smpte-ancillary-data-smpte-st-291>.

   [ST125]    SMPTE, "ST 125:2013, SDTV Component Video Signal Coding
              4:4:4 and 4:2:2 for 13.5 MHz and 18 MHz Systems", 2013.

   [ST2038]   SMPTE, "ST 2038:2008, Carriage of Ancillary Data Packets
              in an MPEG-2 Transport Stream", 2008.

   [ST259]    SMPTE, "ST 259:2008, SDTV Digital Signal/Data - Serial
              Digital Interface", 2008.

   [ST274]    SMPTE, "ST 274:2008, 1920 x 1080 Image Sample Structure,
              Digital Representation and Digital Timing Reference
              Sequences for Multiple Picture Rates", 2008.

   [ST292]    SMPTE, "ST 292-1:2012, 1.5 Gb/s Signal/Data Serial
              Interface", 2012.

   [ST296]    SMPTE, "ST 296:2012, 1280 x 720 Progressive Image 4:2:2
              and 4:4:4 Sample Structure - Analog and Digital
              Representation and Analog Interface", 2012.

Author's Address

Edwards                   Expires April 8, 2017                [Page 15]
Internet-Draft       RTP Payload for Ancillary Data         October 2016

   Thomas G. Edwards
   FOX
   10201 W. Pico Blvd.
   Los Angeles, CA  90035
   USA

   Phone: +1 310 369 6696
   Email: thomas.edwards@fox.com

Edwards                   Expires April 8, 2017                [Page 16]