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 protected]>
Sent: Monday, September 30, 2019 10:19 AM
To: The IESG <[email protected]>
Cc: [email protected]; Ali Begen <[email protected]>; [email protected]; [email protected]; [email protected]
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 <[email protected]>"
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 d
evice. (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.)
_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.