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

[Magnus Westerlund <[e-mail]>]

On Mon, 2019-09-30 at 17:17 -0400, [e-mail] wrote:
> 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.

I would suggest: 

A TSVCIS RTP packet payload consists of zero or more consecutive TSVCIS coder
frames (each consisting of MELPe and TSVCIS coder data), with the oldest frame
first, 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.



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

RFC 8130 said that different rates was not allowed. So this is a change for
TSVCIS. Which raises two questions. 

1. Is it obvious that to be fool proof one must process the payload from the end
towards the begining? If that is not given then the process should be described.
I am not a good measure if this is necessary or not considering how many payload
formats I have reviewed. 

2. Are cases when TSVCIS needs to be backwards compatible with RFC8130, i.e. any
gateway scenarios where one like to use the TSVCIS format in one domain, then
gateway into anohter domain that uses the RFC8130 format. This works fine if one
assumes that the gateway can repacketize the payload, including splitting one
TSVCIS payload into multiple payloads and RTP packets. But there clearly is the
need to restrict the modes for backwards compatibility also. 

Considering that no payload format parameters have been defined to ensure such
restriction, I would guess this aspect can be ignored. 


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

Okay, considering that RFC8130 made this choice and if there has not been any
issues with it, then I will not argue for any change. 

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

I think adding this to the Section 3 text work fine. 
> 
> Should the SHOULD be a MUST?

I think SHOULD is sufficient. The MUST will not be better followed than the
SHOULD. And not marking packets after DTX with m=1 may only impact the senders
voice quality as it can affect the jitterbuffer handling. 

Cheers

Magnus Westerlund 


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