I am the assigned Gen-ART reviewer for:
draft-ietf-avt-rtp-g729-scal-wb-ext-06.txt
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments
you may receive.
---------------------------------------------------------------------
This draft is on the right track but has open issues, described in the
review. It does not appear to be quite ready for publishing as an RFC
at this time.
I have included below several comments and questions that should be
resolved or clarified.
Comments:
========
0. In general, I thought the layout of the document could use some work
to ensure that implementers more predictably knew everything that was
required of them. This version of the document required both a thorough
read and a certain amount of inferring to piece together what I believe
are the requirements.
1. In section 2, the third paragraph isn't a well-formed sentences and
leaves open some ambiguities such as who will be tuning the bandwidth.
2. In section 2, fourth paragraph, what is a graceful quality
improvement?
3. In section 2, last paragraph and again in section 6.2.1 (page 11),
there are sentences that start with "Anyways, ", which I don't think
makes sense.
4. In section 3, second paragraph, is it suggesting that this feature is
helpful when sharing a fixed bandwidth or suggesting that people should
share a fixed bandwidth? It reads like the latter.
5. In section 3, second paragraph, replace "It is described in the
following payload format (see
Section 5.2)" with "It is described in section 5.2."
6. In section 4, second paragraph, "The RTP timestamp clock frequency is
the same as the default sampling frequency, that is 16 kHz" implies a
significant relationship between the RTP timestamp and the default
sampling frequency, but isn't it just a coincidence they have the same
value? I would suggest replacing this sentence with something like "The
RTP timestamp clock frequency is 16 KHz" unless there is in fact a
relationship between these two values. If there is a relationship, I
would suggest explaining what it is.
7. In section 4, in fifth and sixth paragraph, if my understanding is
correct: A non-DTX implementation MUST do all zeros and DTX
implementation MAY do all zeros, but SHOULD set it to one. So, I guess
this M bit isn't meant to tell me whether DTX is used? (In a few pages
we do learn there is another field for this). Does the average reader
know under what circumstances the DTX implementation would chose to set
the M bit to zero?
8. In section 4, final paragraph it says "It is expected that the RTP
profile under which this payload format is being used will ...." which
seems too weak if it is required to get all this to work. Are there
specific requirements against the RTP profile used? Should the profile
be compliant to requirements in section 6.2?
9. In section 5.1, first paragraph it would be helpful to indicated that
the payload header consists of two fields - MBS and FT. The text just
indicates there is a header but the figure has no header, just the MBS
and FT fields and then the following section jumps in and starts talking
about the details of MBS and FT.
10. In section 5.1, first paragraph, it indicates that the header is
"generally followed by audio data representing one or more consecutive
frames at the same bit rate." My initial read of this was that
occasionally it doesn't contain audio data, but after reading the entire
document and briefly thinking perhaps it also could carry video (see
section 6.1, "Applications which use this media type"), I then ending up
on audio-only in section 8, second paragraph. So, this means that either
the 'generally' is incorrect or the variable in this sentence is
actually the "one or more consecutive frames at the same bit rate"?
11. In section 5.2, fifth paragraph we learn that we need to ignore
invalid values in an MBS but at this point have no idea what an invalid
value is or how one might learn more. Later in the document, we did
learn that an MBS can't exceed the maxbitrate field, but I think for the
offer-answer model, there may have been other restrictions. I may have
missed some. When to ignore a field seems important so it would be
better if this was clearer in the document.
12. In section 5.3, final paragraph, I have a similar comment around the
FT. It appears later on in the document that this also can't imply a
rate greater then the maxbitrate, but are there other invalid values?
13. In section 5.4, if FT=15, then there will be no audio frame in the
payload. Then what will there be? Is this an extension of my confusion
in point 10 or is this a case of sending only header information and no
payload?
14. In section 6, second paragraph, it mentions a mapping for SDP and
what to do if it isn't SDP or MIME, but what happens if it is MIME?
15. The definition of DTX in section 6.1 would have been useful earlier
in the document.
16. Suddenly in section 6.1, we start referring to sections in this
document using the expected RFC number. Why? I imagine this will be
confusing to the reader. Section 5.2 and section 5.2 in RFC XXXX will
seem different.
17. In section 6.1, the "Person & email address to contact for further
information" is listed as "[EMAIL PROTECTED]", will
this stand the test of time?
18. In section 6.2.1, it isn't explicitly stated how to state that you
'prefer' G.729.1. Only through the examples do you get that it was by
including the 98 in audio field, and presumably before the 18 to
indicated the preference over G.729. Is this something well-understood
by the average reader?
19. In section 7, first paragraph, replace "see Section 3", with
something like "see Section 3 for more detail".
20. In section 7, second paragraph, although it isn't explicitly stated,
it seems we are implying that a good method of congestion control is to
minimize the header-overhead of a session over time? It would be good to
explicitly state this. I don't know what is generally considered good
practice for discussions on congestion control, but this seems a bit
weak.
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
