Draft: draft-ietf-avt-rtp-g729-scal-wb-ext-06 Reviewer: Sharon Chisholm Review Date: Wednesday 6/28/2006 8:34 AM CST IETF LC Date: 7/05/2006 Summary: 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 "aurelien.sollaud@francetelecom.com", 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.