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

[Magnus Westerlund <[e-mail]>]

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, [e-mail] 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)
> >    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 <[e-mail]> 
> Sent: Tuesday, October 29, 2019 7:24 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Ali Begen <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> 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.
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------