[AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-payload-tsvcis-03: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. Section 3.3:
           A TSVCIS RTP packet consists of zero or more TSVCIS coder frames
   (each consisting of MELPe and TSVCIS coder data) followed by zero or
   one MELPe comfort noise frame.  The presence of a comfort noise frame
   can be determined by its rate code bits in its last octet.

I am missing a quite important word in this paragraph. Because I assume that
the frame actually are required to be consecuitive frames in time order from
oldest to newest?

2. Section 4.1:
           Change controller: IETF Payload working group delegated from the
      IESG.

IESG should we adjust this immediately to say IETF, although this is the
currently recommended text in RFC 8088. Or are we only adjusting the working
group?


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

        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.

        B. Section 4.4:
           In the Offer/Answer model [RFC3264], "bitrate" is a bidirectional
   parameter.  Both sides MUST use a common "bitrate" value or values.
   The offer contains the bitrates supported by the offerer, listed in
   its preferred order.  The answerer MAY agree to any bitrate by
   listing the bitrate first in the answerer response.  Additionally,
   the answerer MAY indicate any secondary bitrate or bitrates that it
   supports.  The initial bitrate used by both parties SHALL be the
   first bitrate specified in the answerer response.

         For example, if offerer bitrates are "2400,600" and answer bitrates
   are "600,2400", the initial bitrate is 600.  If other bitrates are
   provided by the answerer, any common bitrate between the offer and
   answer MAY be used at any time in the future.  Activation of these
   other common bitrates is beyond the scope of this document.

        I am a bit surprised to see bit-rate as  bidirectional parameter here.
        In most use cases where RTP opperates each direction can simply express
        what they accept, and the media sender towards that receiver will
        simply provide what the receiver part has declared as acceptable. Can
        you please provide to me a bit more motivation why the use of
        bidirectional is needed?

        C. Section 3 and 5: Marker bit definition.
        The usage of the M bit
   SHOULD be as specified in the applicable RTP profile -- for example,
   [RFC3551], where [RFC3551] specifies that if the sender does not
   suppress silence (i.e., sends a frame on every frame interval), the
   M bit will always be zero.

        Section 5:
           A primary application of TSVCIS is for radio communications of voice
   conversations, and discontinuous transmissions are normal.  When
   TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may
   cease and resume frequently.  RTP synchronization source (SSRC)
   sequence number gaps indicate lost packets to be filled by PLC, while
   abrupt loss of RTP packets indicates intended discontinuous
   transmissions.

        I would have expected this format that is clearer on its usage of DTX
        that it would talk about that marker bit will be = 1 after each DTX
        period when one no longer transmitts comfort noise only.