Re: [AVT] Working group last call: draft-ietf-avt-rtp-uemclip-02.txt

[Speaking as an individual only]

On 21 Dec 2007, at 15:20, Colin Perkins wrote:
> This is to announce a working group last call on the RTP Payload  
> Format for the UEMCLIP Speech Codec <draft-ietf-avt-rtp- 
> uemclip-02.txt>. Please send any final comments on this draft to  
> the mailing list by 18 January 2008. If no substantive issues are  
> raised by that time, we intend to ask the IESG to publish this as a  
> Proposed Standard RFC.

I have a number of comments on this draft, which I believe it would  
be useful to clarify:

Please expand the acronym UEMCLIP in the document title, to conform  
to RFC Editor guidelines.

Section 2 (1st paragraph): Transcoding is only an issue when  
interoperating with a narrowband terminal through a gateway device,  
when there is no possibility of negotiating a common (narrowband)  
codec. The text should be clarified to explain that this is an  
unusual scenario, and that most interoperability scenarios will  
negotiate a common codec, and so not use transcoding.

Section 3 (4th paragraph) states "this information SHOULD be  
exchanged", but says nothing about what to do if the information is  
not exchanged. The draft should either explain what to do when the  
information is not exchanged, or change the SHOULD to a MUST.

Section 3.1: Can you please clarify if the timestamp rate is fixed  
for the duration of a session, as the maximum sampling rate of the  
chosen mode set?

Section 3.2: The RTP transport protocol doesn't specify an MTU,  
rather the size of RTP packets should not exceed the path MTU.

Section 3.3.1: What is the purpose of the ID field? It would seem to  
be redundant with the RTP payload type, and so can be removed.

Section 3.3.1.2: What is the purpose of the Check Bit? It would seem  
that rather than setting a bit to indicate that the payload should be  
ignored, an MCU should simply not send the packet. The resulting gap  
in the RTP sequence number space will inform the receiver of the  
missing data, and trigger packet loss concealment.

Section 4: This section should mention that an RTP device that is  
transcoding between UEMCLIP and G.711 is an RTP translator in the  
sense of RFC 3550, and that all the requirement of that RFC for  
translators apply. In particular, a transcoding device of this sort  
MUST rewrite RTCP packets, not just the RTP media packets.

Section 5: Cannot a UEMCLIP sender reduce its bandwidth by reducing  
the number of layers transmitted? This would seem useful for  
congestion control.

Section 6.1: The sampling rate ("rate") is a required media type  
parameter, and should be added with a reference to section 6.2.1.

Section 6.1 ("Interoperability considerations"): This media format is  
not interoperable with G.711 u-law. Rather, it may be readily  
transcoded to G.711 u-law. Please clarify.

Section 6.2 ("Payload Type"): This draft cannot mandate that a  
dynamic payload type be chosen, since that is the role of an RTP  
Profile. The discussion of the RTP Payload Type in section 3.1 is  
sufficient; there is no need to further explain it here.

Section 6.3.2: Please expand the examples to be complete, valid, SDP  
files.

-- 
Colin Perkins
http://csperkins.org/