[payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

Thomas Edwards <Thomas.Edwards@fox.com> Fri, 12 May 2017 00:31 UTC

Return-Path: <Thomas.Edwards@fox.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA712EC8D for <payload@ietfa.amsl.com>; Thu, 11 May 2017 17:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5GjFiXSqMOB for <payload@ietfa.amsl.com>; Thu, 11 May 2017 17:31:34 -0700 (PDT)
Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335AB127333 for <payload@ietf.org>; Thu, 11 May 2017 17:26:29 -0700 (PDT)
Received: from pps.filterd (m0082295.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v4C0Lv4q017946 for <payload@ietf.org>; Thu, 11 May 2017 17:26:27 -0700
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00195501.pphosted.com with ESMTP id 2ad1nfr6n7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <payload@ietf.org>; Thu, 11 May 2017 17:26:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ixajro8H4/vVbiGpjHhUftt91wAsyv2yOnwcmBQ0Obc=; b=ptVT3Zs4veheIlAYBaXc0dqXPmbZrkMglD57+O2VigZMg0DmAB+XOYkzWJ05lswPLXzrfH4pemO7aZ3bB6G2N7UDeTMVJ+0OWpn++hLY42KyrYIuVuHPR4CFgTa0pjcl9dFwcgyjMSn81qqHkCLuA/M66iZkkrLVExJgTQWyiGI=
Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 00:26:24 +0000
Received: from CO1PR05MB457.namprd05.prod.outlook.com ([fe80::d838:d8c1:35d7:53f9]) by CO1PR05MB457.namprd05.prod.outlook.com ([fe80::d838:d8c1:35d7:53f9%27]) with mapi id 15.01.1084.015; Fri, 12 May 2017 00:26:23 +0000
From: Thomas Edwards <Thomas.Edwards@fox.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
Thread-Index: AQHSyrZiGvSczZmxek+HC40CeN/Tnw==
Date: Fri, 12 May 2017 00:26:23 +0000
Message-ID: <142B2248-5244-4179-8AFD-A5BF7CCD91ED@fox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fox.com;
x-originating-ip: [216.205.246.234]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 7:TUrwtReEnqpOk5trU3rPL6pVR3A9B+ecPI28DtcL01hmD7WOO8kx3lgE9eGOu44bffMy3/eceFMPZdLhUQWm+IkRTx729Z/4FzyMJFAIXu6rrJuxS6ssU4mTl7LOEa57CX1zKljpIm2QpCaiOF6PGXjEgffjAzTPE6/JJvG+w+pXCZwBYNL418KH+vv+5r9giirBjmaDNsmoOupOqOcQJ6wfjlRt11YzYCuSFY2agxt3S1s1k86MIn0xQx26aPR+eG/QpUzztidsZ8MxXScZG1vrNQMo2+YwBV6mg8lnsvEudpOoC6cNORY6cobU8p7DPuGmQ1c5pQ4UCnclltmklQ==
x-ms-office365-filtering-correlation-id: 92b1bf05-5775-4f6d-d3ce-08d498cd8549
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: <CO1PR05MB4604A91E2F8A5620C7F593094E20@CO1PR05MB460.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(50582790962513)(127952516941037)(21748063052155)(177823376758907);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703036)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CO1PR05MB460;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39860400002)(39850400002)(39450400003)(39840400002)(288314003)(3846002)(102836003)(6116002)(36756003)(2906002)(2351001)(50986999)(54356999)(189998001)(3660700001)(3280700002)(6916009)(53936002)(5250100002)(99286003)(33656002)(5640700003)(7736002)(2501003)(5660300001)(8676002)(110136004)(81166006)(66066001)(1730700003)(82746002)(38730400002)(6512007)(8936002)(6306002)(83716003)(6436002)(6486002)(54896002)(53946003)(478600001)(6506006)(86362001)(25786009)(2900100001)(72206003)(230783001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB457.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_142B2248524441798AFDA5BF7CCD91EDfoxcom_"
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 00:26:23.5878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_20:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705120005
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Ek_44guZPRC19B_eCe6BFLa5PiU>
Subject: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2017 00:31:40 -0000

I have recently uploaded the I-D draft-ietf-payload-rtp-ancillary-09

Key items:


1)       ANC data packets now identify which stream of a multi-stream interface they come from

2)       VPID Code added as optional Media Type parameter to identify type of interface

3)       Additional clarification of Field and Y/C data channel bits

4)       Removal of RTSP/SAP from Offer/Answer

5)       Removal of any normative words not intended to be normative

These changes should be backwards-compatible with -08 implementations.

Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

Comment source: Kjetil Oftedal <oftedal@gmail.com> Sat, 01 April 2017 09:46 UTC
[note on interlace use in multi-stream progressive interfaces]
297a298,302
>            Note that some multi-stream SDI interfaces may use multiple
>            interlaced signal streams to transmit progressive images, in
>            which case the "F" bits would refer to the field of the
>            interlaced stream used for transport of the ANC data packet.

Comment source: Roni Even <roni.even@huawei.com> Wed, 05 April 2017 08:07 UTC
[The procedure is not relevant for RTSP or SAP since it is not for declarative SDP only for SIP offer/answer when there is an answerer]

669a710,725
> 5.  Offer/Answer Model and Declarative Considerations
>
> 5.1.  Offer/Answer Model
>
>    Receivers might wish 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], the offeror MAY provide a list of ANC streams available
>    with specific DID_SDID parameters in the fmtp line.  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.  Or
>    the answerer MAY reject the offer.  There are no restrictions on
>    updating DID_SDID parameters in a subsequent offer.
...
677c733
< 5.  Offer/Answer Model and Declarative Considerations
---
> 5.2.  Declarative SDP Considerations
679,689c735,737
<    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 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.  There are no restrictions on
<    updating DID_SDID parameters in a subsequent offer.
---
>    For declarative use of SDP, nothing specific is defined for this
>    payload format.  The configuration given by the SDP MUST be used when
>    sending and/or receiving media in the session.

Comment source: John Fletcher <John.Fletcher@bbc.co.uk> Wed, 03 May 2017 14:57 UTC
[specify stream number]
130,131c130,131
<    of a link number, stream number, or image number of multi-link,
<    multi-stream, or multi-image SDI interfaces.
---
>    of the Video Payload ID (VPID) code of the source interface of ANC
>    data packets.

186c186
<        |C|   Line_Number       |   Horizontal_Offset   |    reserved   |
---
>        |C|   Line_Number       |   Horizontal_Offset   |S|  StreamNum  |
194c194
<        |C|   Line_Number       |   Horizontal_Offset   |    reserved   |
---
>        |C|   Line_Number       |   Horizontal_Offset   |S|  StreamNum  |

362,366c368,399
<    reserved: 8 bits
<            One octet is reserved between Horizontal_Offset and DID
<            fields, and contains "0" bits.  These reserved bits ensure
<            that the ANC data packet begins on a 32-bit word-aligned
<            boundary for ease of implementation.
---
>    S (Data Stream Flag): 1 bit
>            This field indicates whether the data stream number of a
>            multi-stream data mapping used to transport the ANC data
>            packet is specified.  If the S bit is '0', then the StreamNum
>            field provides no guidance regarding the source data stream
>            number of the ANC data packet.  If the S bit is '1', then the
>            StreamNum field carries information regarding the source data
>            stream number of the ANC data packet.
>
>    StreamNum: 7 bits
>            If the S (Data Stream Flag) bit is '1', then the StreamNum
>            field MUST carry identification of the source data stream
>            number of the ANC data packet.  If the data stream is
>            numbered, then the StreamNum field SHALL carry the number of
>            the source data stream minus one.  If the source multi-stream
>            interface does not have numbered data streams, the following
>            numbers SHALL be used in this field: '0' for link A data
>            stream, '1' for link B data stream.  For stereoscopic multi-
>            stream interface formats that do not have numbered streams,
>            the following numbers SHALL be used in this field: '0' for
>            left eye stream, '1' for right eye stream.
...
>            Note that in multi-link SDI connections, the physical
>            link that a particular stream utilizes is typically specified
>            by the interface standard.

522,530c547,568
...
<       LinkNumber:
<          This integer parameter specifies that ANC data in the stream is
<          associated with a specific link number, stream number, or image
<          number of multi-link, multi-stream, or multi-image SDI
<          interfaces.
---
...
>       VPID_Code:
>          This integer parameter specifies the Video Payload ID (VPID)
>          Code of the source interface of ANC data packets using the
>          value from byte 1 of the VPID as defined in SMPTE ST 352
>          [ST352].  The integer SHALL be made with bit 7 of VPID byte 1
...
>          being the most significant bit, and bit 0 of VPID byte 1 being
>          the least significant bit.  For example, 132 shall refer to
>          SMPTE ST 292-1, 720-line video payloads on a 1.5 Gbps (nominal)
>          serial digital interface.

594c633
<    o  The optional parameters LinkNumber and DID_SDID, when present, are
---
>    o  The optional parameters VPID_Code and DID_SDID, when present, are


625c656
<    If the optional parameter LinkNumber is present, it SHALL be present
---
>    If the optional parameter VPID_Code is present, it SHALL be present

633c664
<         a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};LinkNumber=3
---
>         a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};VPID_Code=132

640c679,680
<    The LinkNumber is 3.
---
>    The VPID_Code is 132 (referring to SMPTE ST 292-1, 720-line video
>    payloads on a 1.5 Gbps serial digital interface).

826a872,874
>    [ST352]    SMPTE, "ST 352:2013, Payload Identification Codes for
>               Serial Digital Interfaces", 2013.
Comment source: John Fletcher <John.Fletcher@bbc.co.uk> Thu, 20 April 2017 10:22 UTC
[clarity on C bit for interfaces without specific Y/C channels]
307,315c312,320
<            For HD signals, this flag, when set to "1", indicates that
<            the ANC data corresponds to the color-difference channel (C).
<            When set to "0", this flag indicates that the ANC data
<            corresponds to the luma (Y) channel.  For SD signals, this
<            flag SHALL be set to "0".  For ANC data packets that do not
<            originate from SDI sources, if the ANC data type definition
<            requires the use of the C or Y channel, the C flag SHALL
<            reflect that requirement, otherwise the C flag SHALL be set
<            to "0".
---
>            This flag, when set to "1", indicates that the ANC data
>            corresponds to the color-difference data channel (C).  When
>            set to "0", this flag indicates either that the ANC data
>            corresponds to the luma (Y) data channel, that the ANC data
>            source is from an SD signal, or that the ANC data source has
>            no specific luma or color-difference data channels.  However,
>            if the ANC data type definition specifically requires the use
>            of the C or Y data channel, the C flag SHALL reflect that
>            requirement.
[clearing up normative language]
90,91c92,93
<    corresponds to vertical and horizontal blanking periods required by
<    cathode ray tube type displays.  ANC can carry a range of data types,
---
>    corresponds to vertical and horizontal blanking periods of cathode
>    ray tube type displays.  ANC can carry a range of data types,

106,107d107
<    payload format is registered with SMPTE, an application document
<    describing the payload format is required, and the registered
117,118c117,118
<    ancillary data packet is identified by a registered data
<    identification word.
---
>    payload format is registered with SMPTE, it is identified by a
>    registered data identification word.

133,135c133,135
<    It should be noted that the ancillary data flag (ADF) word is not
<    specifically carried in this RTP payload.  The ADF may be specified
<    in a document defining an interconnecting digital video interface,
---
>    Note that the ancillary data flag (ADF) word is not specifically
>    carried in this RTP payload.  The ADF might be specified in a
>    document defining an interconnecting digital video interface,

325,326c330,331
<            indicates that the ANC data may be placed into any legal area
<            of VANC, specifically.
---
>            indicates that the ANC data is intended to be placed into any
>            legal area of VANC, specifically.

328,332d332
<            Note that the lines that are available to convey ANC data are
<            as defined in the applicable sample structure specification
<            (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656
<            [BT656]) and may be further restricted per SMPTE RP 168
<            [RP168].
340a341,346
>            Note that the lines that are available to convey ANC data are
>            as defined in the applicable sample structure specification
>            (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656
>            [BT656]) and possibly further restricted per SMPTE RP 168
>            [RP168].

355,356c361,362
<            indicates that the ANC data may be placed into any legal area
<            of HANC, specifically.
---
>            indicates that the ANC data is intended to be placed into any
>            legal area of HANC, specifically.

522,530c547,568
<          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.
...
---
>          The absence of the DID_SDID parameter signals that
>          determination of the DID and SDID of ANC packets in the payload
>          can only be achieved through direct inspection of the ANC data
>          packet fields.
...

539c577
<    the possible data items.  Some implementations may care about the
---
>    the possible data items.  Some implementations might care about the

541c579
<    implementations may not care.
---
>    implementations might not care.

546,547c584,585
<    professional video, especially those that must interoperate with
<    legacy serial digital interfaces (SDI).
---
>    professional video, especially those that interoperate with legacy
>    serial digital interfaces (SDI).

607c646
<    specified, then the ancillary data stream may potentially contain
---
>    specified, then the ancillary data stream might potentially contain

645,648c685,688
<    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.
---
>    can use the Lip Synchronization (LS) grouping defined in RFC 5888
>    [RFC5888], which states that media streams whose corresponding "m"
>    lines are grouped together using LS semantics are to be played back
>    in a synchronized manner.

715,721c763,769
<    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, but the Checksum_Word is unlikely to provide
<    a payload integrity check in case of a directed attack.
---
>    To avoid potential buffer overflow attacks, receivers SHOULD 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, but the Checksum_Word is unlikely to provide a payload
>    integrity check in case of a directed attack.

724,732c772
<    payload into a serial digital interface (SDI).  It may still be a
...
---
>    payload into a serial digital interface (SDI).  It might still be a


--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035