Re: [AVTCORE] Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)

<victor.demjanenko@vocal.com> Tue, 29 October 2019 19:11 UTC

Return-Path: <victor.demjanenko@vocal.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB921209D5 for <avt@ietfa.amsl.com>; Tue, 29 Oct 2019 12:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 5RjbXpM48Za3 for <avt@ietfa.amsl.com>; Tue, 29 Oct 2019 12:11:29 -0700 (PDT)
Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 5207E120968 for <avt@ietf.org>; Tue, 29 Oct 2019 12:11:29 -0700 (PDT)
X-ASG-Debug-ID: 1572376283-092fd3147403f90001-6kZpOq
Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id 4Vt17ODktYHoVZfo (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2019 15:11:23 -0400 (EDT)
X-Barracuda-Envelope-From: victor.demjanenko@vocal.com
X-Barracuda-Apparent-Source-IP: 72.236.255.15
Received: from HERTELLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id EFBE4B5BC60; Tue, 29 Oct 2019 15:11:22 -0400 (EDT)
From: victor.demjanenko@vocal.com
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-payload-tsvcis@ietf.org, 'Ali Begen' <ali.begen@networked.media>, avtcore-chairs@ietf.org, avt@ietf.org, victor.demjanenko@vocal.com
References: <157234826341.6618.6097209580438306622.idtracker@ietfa.amsl.com>
In-Reply-To: <157234826341.6618.6097209580438306622.idtracker@ietfa.amsl.com>
Date: Tue, 29 Oct 2019 15:11:21 -0400
X-ASG-Orig-Subj: RE: Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)
Message-ID: <016801d58e8c$a6a1e0d0$f3e5a270$@vocal.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQILy3BOQVYlNKaepWP1dEL8hy/PKKcFgEwA
X-Barracuda-Connect: host105.olm1.com[72.236.255.15]
X-Barracuda-Start-Time: 1572376283
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at olm1.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.77675 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/_MRR1rhjbG1A5YX4dEfE0aumQ2A>
Subject: Re: [AVTCORE] Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 19:11:32 -0000

Hi Magnus,

Let me address the comment you make.  Yes indeed you need to parse from the bottom up one frame at a time.  This had to be done with RFC8130 for MELP payloads already.  Keep in mind that TSVCIS coder frames consist of two portions, a fixed size MELP 2400 and variable size TSVCIS.  Its is permitted for the TSVCIS portion to vary in size within a single RTP payload.  That would allow the VDR speech coder to act as it should (if enabled to do so).  In practice, TSVCIS payload would likely always be a fixed size.  

Language had been added to make it clear that other MELP rates are not to be mixed.  That is consistent with RFC8130 and prevents complexities such as different timestamp advances for MELP frames of different rates (600, 1200 and 2400).  

> (now)
>    TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS
>    parameter octet counts.  Its packed parameter octet count (length) is
>    indicated in the trailing byte(s).  All MELPe frames in a single RTP
>    packet MUST be of the same coder bitrate.  For all MELPe coder
>    frames, the coder rate bits in the trailing byte identify the
>    contents and length as per Table 1.

I hope this is satisfactory.

Victor

-----Original Message-----
From: Magnus Westerlund via Datatracker <noreply@ietf.org> 
Sent: Tuesday, October 29, 2019 7:24 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen <ali.begen@networked.media>; avtcore-chairs@ietf.org; ali.begen@networked.media; avt@ietf.org
Subject: Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)

Magnus Westerlund has entered the following ballot position for
draft-ietf-payload-tsvcis-04: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the discusses and comments.

I leave this comment, as something that could have been more explicit about decoding, however one skilled in the art will figure it out.

        A. Section 3.3:
           TSVCIS coder frames in a single RTP packet MAY be of different coder
   bitrates.  With the exception for the variable length TSVCIS
   parameter frames, the coder rate bits in the trailing byte identify
   the contents and length as per Table 1.

        If I understand this correctly in an RTP payload that contain mulyiplr
        bit-rate frames the safest way of decoding this payload is to work from
        the end of the payload towards the start identifying a frame at a time.
        Then after having figured out how many frames actually are present, one
        can calculate the timestamp value for each frame.