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

[<[e-mail]>]

Hi Magnus, Barry,

Thanks for the review.  Our comments are below marked with a "v->" leader.

Regards,

Victor & Dave

-----Original Message-----
From: Magnus Westerlund via Datatracker <[e-mail]> 
Sent: Monday, September 30, 2019 10:19 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Ali Begen <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Magnus Westerlund's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)

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?

v-> The concept (and phrasing I believe) was taken from the G.729/G.729B frame packing.  I'm not sure what additional word (or wording change) would make this clearer.  The idea is that a comfort noise frame will always be the last frame in a packet and may follow other regular coder frames.  Wording/rewording suggestions are welcome.

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?

v-> So what should the exact replacement test be?

"	Change controller: IETF"
Or
"	Change controller: IETF <[e-mail]>"
Or
Something else?


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

v-> Yes you are absolutely correct.  This was permitted with MELP Payload (RFC 8130).  It is unlikely that different coder bit rates would be mixed in one RTP packet.  Its repetition here is as a result that TSVCIS is a superset of MELPe.

        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?

v-> This convention was in RFC 8130 (MELP payload).  It has to do with bandwidth restrictions (typically on the outsides of the offerer and answerer).  Suppose a link (after the answerer) is limited to 600bps.  The answerer would prefer 600bps but could transcode 2400 to 600 bps (with effort on its side).  The offerer can send/receive either and maybe wants to send 2400 so that it can encode the voice once for multiple independent RTP paths.  It will however accept 600 bps for its receiver.  Now in this example, the preferred encoding is 600 bps for both directions.  So the bitrate parameter is bidirectional in the sense that each side gives its capabilities and suggestion based on the ordering and the answerer can restrict or indicate a preferred ordering in case it is the least capable device.   (For a call established in the reverse direction, the offerer would say the same 600, 2400 and I would expect a more capable device as an answerer to say 600, 2400 to match.)

        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.

v-> Agreed,  Should we add the following:

" Resumption of voice transmission SHOULD be indicated by the RTP marker bit (M) set to 1."

Should the SHOULD be a MUST?

(We have customers with intentionally bad behavior with respect to the M bit no matter how much we protest.)