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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Mon, 30 Sep 2019 07:18:44 -0700

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.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Sep 2019 12:12:13 -0400

> currently recommended text in RFC 8088. Or are we only adjusting the working

What we decided in our discussion was to say "IETF", to give the
working group mailing list as the contact information (so in this
case, <[email-masked]>), and to ask the RFC Editor to remove the contact
information after IANA puts it in the registry.

(In this case, the Payload working group doesn't exist any more.)

Sorry I missed this in my own review, and thanks for catching it.

Barry

---

From: <[email-masked]>
Date: Mon, 30 Sep 2019 17:17:41 -0400

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 <[email-masked]> 
Sent: Monday, September 30, 2019 10:19 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Ali Begen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Magnus Westerlund's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and 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.)

1. Section 3.3:

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:

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 <[email-masked]>"
Or
Something else?

        A. Section 3.3:

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:

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

        Section 5:

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Sep 2019 18:54:41 -0400

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

Please bear with us on this, as we're just sorting this out within the
IESG and with IANA and the RFC Editor.

I think we probably want to do it like this:

       Change controller: IETF, contact <[email-masked]>

And then when the RFC is published it will just say "Change
controller: IETF", and IANA will have put the contact information in
the registry, or someplace where IANA can give it to people when they
need it (depending upon their GDPR concerns).  But you don't have to
worry about this part -- you'll just see the final edited version
during the "AUTH48" phase.

Barry