[AVT] Re: I-D ACTION:draft-ramalho-rgl-rtpformat-02.txt

[Colin Perkins <[e-mail]>]

On Tuesday, Sep 2, 2003, at 17:59 Europe/London, 
[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
> 	Title		: RTP Payload Format for RGL Codec
> 	Author(s)	: M. Ramalho
> 	Filename	: draft-ramalho-rgl-rtpformat-02.txt
> 	Pages		: 27
> 	Date		: 2003-9-2
> 	
> This document describes the RTP payload format and the storage mode
> format for the RGL Codec (Version 1.0.0) described in
> draft-ramalho-rgl-desc-01.txt [4] and documented fully at
> www.vovida.org [12]. The necessary details for the use of the RGL
> codec with SDP are included in this document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ramalho-rgl-rtpformat-02.txt

I have a number of comments on this draft, both technical and 
editorial. These are the technical comments, I'll send my editorial 
comments directly to the author:

The draft should state explicitly, probably in Section 3, that the RGL 
encoding process converts the sample based G.711 output to a frame 
based format.

On page 7 it is explained that some code points are "never used for 
real world signals". Does this mean that it is impossible for the codec 
to generate these code points, or can a determined attacker produce 
codec output including these code points by manipulating the input 
stream? If these code points can be produced by manipulating the input, 
does this affect the security/robustness of the payload format?

The discussion of the RTP header extension (X) bit in Section 4 seems 
to be the normal RTP usage. It may be simpler to state that the X bit 
is employed in the normal manner, according to the RTP profile in use.

Section 4 recommends that silence suppression is not used, because of 
the efficiency of the RGL codec at compressing silence. Whilst RGL may 
be efficient, bandwidth can still be saved by suppressing silence and 
not sending any packets. A more convincing rationale may be that RGL is 
effective at conveying "silent" periods, and that this "comfort noise" 
is valuable.

Section 4.2 limits a number of 8 bit fields to holding values in the 
range 0 to 251. This is acceptable, but it must also explain what 
receivers should do with packets containing the reserved values. If it 
is intended that the reserved values will be assigned in the future, a 
registry and procedures for assignment need to be specified.

Similarly, the Num_Frames field is defined with legal values ranging 
from 1-255. What should a receiver do with a packet where Num_Frames is 
zero? If zero is never a legal value, you might define the semantics of 
the field to be "number of frames minus one", making it impossible to 
signal an invalid value.

At the end of page 12, it is suggested that the number of RGL frames 
MUST be chosen such that the packet size does not exceed the MTU. This 
is a valid goal, but the MTU may not always be known - for example in 
multicast. Suggest changing this to a SHOULD.

Section 4.3 explains how incorrectly formatted packets are not 
presented to the RGL decoder. It would be helpful to clarify that these 
packets are still counted as being received for the purpose of RTCP.

Section 4.3 mentions that there are several code points reserved for 
future use. There needs to be a well-defined registration procedure for 
these code points, which can be managed through, for example, the IANA.

In the RGL Storage Mode, is there a reason why the sample rate is not 
stored in the file format?

The file format and the Type 2 frame format use the same headers, but 
in a different order (the frame format has a table of contents, the 
file format intermingles headers and data). If might ease 
implementation of recording/playback devices if the two formats were 
aligned.

In the storage mode, it's not clear if any RTP padding - as opposed to 
payload format specific padding - is removed when recording packets to 
a file. Recommend that such padding is removed.

The storage mode seems to support two different block types, depending 
on the size of the frames to be stored. Is this saving worth the 
complexity of having a more complex parser? Is the trade-off of size 
vs. complexity the same as for real-time transmission?

How does the storage format handle recording of data sent using silence 
suppression? This is different from the case where data is lost, so 
cannot be handled using erasure frames.

The SDP issues section defines the default ptime as 20ms, but 
recommends that 10ms is used. Why not make 10ms the default?

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


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt