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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Tue, 29 Oct 2019 04:24:23 -0700

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.

---

From: <[email-masked]>
Date: Tue, 29 Oct 2019 15:11:21 -0400

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 <[email-masked]> 
Sent: Tuesday, October 29, 2019 7:24 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Ali Begen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)

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.)

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:

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Oct 2019 09:19:15 +0000

Hi Victor,

So I made this a comment, not a discuss so it is up to authors, WG and
responsible AD how to handle it. However, parsing from the end rather the front
of the RTP payload is unusual. I can't remebmer any other payload format that
has that requirement  (other than MELP). Therefore I do propose that you add a
sentence to state that explicit. 

At the same time I do think an implementer when they sit down to implement it
will realize it, and that is the large part of why I have this as a comment and
not a discuss. If I thought it was likely there would be a misstake I would have
this as a discuss. 

Cheers

Magnus

On Tue, 2019-10-29 at 15:11 -0400, [email-masked] wrote:
> 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)
> Cc: [email-masked]; Ali Begen <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> 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.)
> 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------