Subject: [payload] IETF Last Call comments on draft-edwards-payload-rtp-ancillary-06

From: Thomas Edwards <[email-masked]>
Date: Wed, 16 Nov 2016 05:29:01 +0000

There were a number of comments received during the IETF Last Call on draft-edwards-payload-rtp-ancillary-06.  Please see below for a list of comments, my responses, and my suggested draft changes.  If these changes are reasonable, I can update the I-D.

The most significant came from Chuck Meyer of Grass Valley who noticed that the payload format seemed a bit odd if multiple ANC packets were present.  He also (like many others in the broadcast industry) suggested the importance of word-aligning the start of all ANC data packets in the RTP payload for ease of FPGA implementation.  I suggested a payload format change to meet those requirements that was accepted by Chuck as well as Gerard Phillips of Snell Advanced Media, Andrew Bonney of BBC, and Leigh Whitcomb of Imagine Communications.

The Gen-Art review had several comments:

Comment: "Section 3.1: The text talks about what the presence of DID and SDID means. But, as they are optional, what does it mean if they are NOT present?"
Response: Will add text regarding interpretation of non DID_SDID parameters.
Draft change: "The absence of the DID_SDID parameter signals that in order to determine the DID and SDID of ANC packets in the payload, the DID and SDID fields of each ANC packet must be inspected."

Comment: “Section 3.2: I would suggest that the section is renamed to “SDP Considerations”, and becomes a level 1 section (i.e., “4 SDP Considerations”).”
Response: OK
Draft change: "Mapping to SDP" becomes level 1 section "SDP Considerations", also "Offer/Answer Model and Declarative Considerations" becomes level 1 section.

Comment: “Section 3.2: Is it allowed to carry both a “normal” video stream and the ANC RTP payload within the same m= line? If so, how are they related?
    Example:
    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
    m=video 50000 RTP/AVP 96 97
    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=rtpmap:97 smpte291/90000
    a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}"
Response: Per RFC 4566 regarding m-lines, “If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers.  When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.”  I believe there is no need to repeat RFC 4566 in this document.
Draft change: No change

Comment: "Section 3.2: Is it allowed to use two or more ANC RTP payloads (e.g., each using a different DID_SDID), either within a single m- line, or within different m- lines? If so, how are they related?"
Response: In a single m-line, the behavior is as specified in RFC 4566.  With different m-lines, multiple streams of ANC data can be grouped together with Lip Synchronization (LS) or other groupings.  I believe that this is defined by higher-order RTP and grouping protocols.
Draft change: No change

Comment: “Section 3.2: When I indicate DID_SDID, it is something I intend to SEND, or something I am willing to RECEIVE?"
Response: It depends how SDP is being used.  In an out-of-band or SAP implementation, it may be what kind of ANC data will be sent.  In an offer/answer model,
it might be what kind of ANC data can be received.  I believe that this is dependent on higher-order protocols beyond this RTP payload definition.
Draft change: No change

Comment: "Section 3.2:  If multiple DID_SDIDs are listed, can they be used in any order during the session? If so, it would be good to explicitly indicate that,
and note that the same payload type value will be used for all of them"
Response: Yes, there is no ordering implied by multiple DID_SDIDs.
Draft change: "Multiple DID_SDID parameters do not imply any particular ordering of the different types of ANC packets in the stream."

Comment: "Section 3.2:  Is there a possibility that the receiver does not understand DID_SDID, or specific DID_SDID values? If so, what shall it do?""
Response: I believe that this could apply to any RTP media type or specific sub-format described by media type parameters (such as sampling rate, frame rate, bandwidth, etc.) that a receiver does not understand, and is not defined within RTP.
Draft change: No change

Comment: "Section 3.2.1: The text says:

   ""The ANC RTP payload format will often be used in groupings with
   associated video streams.  Any legal SDP grouping mechanism could be
   used.""

   What is meant by the second sentence (“any legal SDP grouping)? Isn¹t the semantic depending on the type of grouping?"
Response: After consideration, I think it is best to limit this section to an example of LS grouping under RFC 6838 to be clear.
Draft change: Formerly: "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."
Change to: "To associate an ANC RTP stream with other media streams, 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.”

Comment: “Section 3.2.1: What if the SDP group contains two (or more) video m= lines. Is the ANC RTP payload then associated with all of them?”
Response: RFC 5888 states "When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship
between two or more of them.", however, "lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams."
Draft change: No change

Comment: "Section 3.2.1: Could you rename the section title to ""Grouping ANC Streams with Video Streams”?"
Response: After consideration, I think it is best to retitle to "Grouping ANC Streams with other Media Streams", as the grouped streams could include audio, 
video, ANC, etc.
Draft change: Retitle "Grouping ANC data RTP Streams with Associated Video Streams" to "Grouping ANC Streams with other Media Streams"

Comment: "Section 3.3: You should say something about updating the parameters in a sub-sequent offer (or within an answer to an sub-sequent offer). Are there
any restrictions?"
Response: There are no restrictions on updating parameters in a subsequent offer.
Draft change: Add: "There are no restrictions on updating DID_SDID parameters in a subsequent offer."

Comment: “Section 3.3: What does it mean if one sends a sub-sequent offer/answer without some/all parameters. Does it mean they are disabled?"
Response: Yes.  "The presence of the DID_SDID parameters signals that all ancillary data packets of this stream are of a particular type or types"
Draft change: No change

Comment: “Section 3.3: Is it allowed to include ANC RTP in an answer if the offer doesn’t contain it?"
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: No change

Comment: “Section 3.3:  Is it allowed to include DID_SDID in an answer if not included in the offer?"
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: Typo found - change "a all" to just "all" Offer/Answer Model section

Comment: “Section 3.3:   Can the DID_SDID values in the answer be different than the ones in the offer, or are there any restrictions?”
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: No change

The Security Directorate also had several comments:

Comment: “The [security considerations] section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data.  I'm OK with this assertion, except for the integrity check using Checksum_Word.  The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check.”
Response: Indeed, the nine bit checksum word does not provide sufficient coverage for a check against attack.
Draft change: To "Also the Checksum_Word should be checked against the ANC data packet to ensure that its data has not been damaged in transit" add ", "but the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack."

Comment: Abstract: Does RTP and SMPTE need to be expanded first?
Response: Agreed.
Draft change: Expand RTP and SMPTE in Abstract

Comment: Is SMPTE ST 291-1 a normative reference?
Response: I believe yes, due to specific definitions of ST 291-1 data fields specified in the payload, and DID/SDID info in the Media Type parameter.
Draft change: No change

Comment: s/an SDI/a SDI/
Response: SDI is an initialism.  The Chicago Manual of Style states "When an abbreviation follows an indefinite article, the choice of a or an is determined by the way the abbreviation would be read aloud."
Draft change: No change

Kjetil Oftedal also had several comments:

Comment: "C-field for packets without specified location
---
   An ANC data packet with the header fields Line_Number of 0x7FF and
   Horizontal_Offset of 0xFFF SHALL be considered to be carried without
   any specific location within the field or frame, and in such a case
   the ""C"" field SHALL be ignored.
---
Most if not all ANC packet specifications dictate which if it the packet is to be transmitted in the Y or C channel. It will be more generic if the C-bit is enforced in this case."
Response: "SMPTE ST 291-1 points out ""Receiving equipment shall detect the location of a packet only by its DID for a Type 1 packet and by its DID/SDID for a Type 2 packet.""  Thus unique identification of an ANC packet type can occur without reference to the Y or C location.  Some ANC types (such as SMPTE ST 12-2 ANC Time Code) do not specify Y or C placement.  

However I understand that a transmitter of this RTP payload may wish to send an ANC packet without a specific location in the frame, but would prefer that it be placed back into a Y or C channel in any legal location in SDI.   Removing the ""SHALL be ignored"" text allows for this behavior, and does not place undue burden on all-IP applications."
Draft change: Remove text: ", and in such a case the "C" field SHALL be ignored." 

Comment: "Support for any placement in vertical or horizontal area
---
   A value of 0xFFF (all bits in the field are '1') indicates that the ANC data
   is carried without any specific location within the line.
---
This does not separate between any placement in VANC or HANC space.  I will suggest that a second reserved value is added (0xFFE) for any placement within HANC, and 0xFFF is any kept as any placement within VANC."
Response: Agreed.
Draft change: "Add text to Line_Number: ""A value of 0x7FE indicates that the ANC data may be placed into any legal area of VANC.""
Add test to Horizontal_Offset: ""A value of 0xFFE indicates that the ANC data may be placed into any legal area of HANC."""

Comment: “"ANC packet transmission order and latency
---
   ANC data packets with headers that specify specific location within a
   field or frame SHOULD be sent in raster scan order, both in terms of
   packing position within an RTP packet and in terms of transmission
   time of RTP packets.
---
This implies that a full compliant receiver must have a full frame of latency when embedding to SDI as the packets does not have to be in order.  Implementation of receivers will be easier and the amount of buffering required will be lower if cable order ANC transmission is mandated."”
Response: This was a compromise reached between those concerned about ultra-low latency and those who were less concerned about SDI interop.  For example, one implementer wanted to order ANC packets based on DID & SDID.
Draft change: No change.

Comment: Multilink format support.  Solution for the missing signaling for multilink formats has not been included in the current draft, which is required to support 3G Level B Dual Link (1080p60), 12G SDI (4Kp60). The length field of the primary header could be replaced with a channel field, as this length field does not provide much more information than the length field present in the UDP header. Or this can be signaled in the SDP as previously suggested by Thomas Edwards.
Response: I suggest this is kept in an optional SDP parameter "LinkNumber"
Draft change: Add optional SDP Parameter "LinkNumber: This integer parameter specifies that ANC data in the stream comes from a specific link number (1-4) of SDI interfaces that use dual or quad link."
  
-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035