Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-03.txt

[Colin Perkins <csp at csperkins.org>]

Matthew,

On 18 May 2005, at 06:42, Matthew Romaine wrote:
> As noted below, there is a new revision of the ID outlining a  
> payload for ATRAC content.  Key changes include clarifying the SDP  
> parameters and Offer/Answer exchange.

These changes are a definite improvement.

> An auxiliary data section has also been added.

The auxiliary data section was introduced in the -02 revision. I  
think the presence of this section is a mistake: it's better to  
signal extensions in the signalling protocol, rather than allowing  
undocumented auxiliary data. We don't typically allow such undefined  
extension fields in RTP payload formats.

> Would appreciate any comments from the community.  We have most of  
> the draft implemented, so whatever else needs to happen before last  
> call I'm ready to address.

I have a few details, in addition to the major issue noted above:

In section 4.2 it's stated that "ATRAC frames may be of fixed or  
variable octet sizes". It might be clearer to explain that "ATRAC  
frames may be of fixed or variable length", to avoid the implication  
that the size of the octet varies.

In section 5.1, "defined out-of-bounds" should read "defined out-of- 
band".

In section 5.2.1, it should be sufficient to say "The ATRAC family  
payload header is two octets" rather than "The ATRAC family header is  
a scant two octets. This should make processing very simple".

In section 5.2.1, would it make sense for FrgNo to start from 0 for  
the first fragment, for consistency with NFrames?

The FrOff field is introduced in section 5.2.1, but not explained  
until section 5.2.3. You should include a reference from section  
5.2.1 forward to section 5.2.3.  That said, I recommend the FrOff  
field is removed, as it can be inferred from the RTP timestamp and  
the number of ATRAC frames included in each packet.

In section 5.2.4, it would be clearer to say "This section MUST NOT  
be empty" rather than "This section is never empty".

In section 5.2.4.1, it is stated that redundancy "SHOULD NOT" be used  
in the event of fragmentation. In what circumstances is redundancy  
useful with fragmentation? You either need to explain those  
circumstances, or  to note that redundancy "MUST NOT" be used with  
fragmentation and that the Frame Offset field MUST be ignored.

In section 6, it would be clearer if the full headers were included  
with the examples. We have no need for brevity here.

In section 7.1, it is stated that if maxRedundantFrames is not used,  
a value of 15 "SHOULD" be assumed. You either need to explain when  
other values are assumed, or change this to a "MUST". (Similar in  
section 7.2)

In section 7.1, the last two sentences of the definition of maxptime  
can be removed. Also, is there a reason why this is not defined as  
"MUST be a multiple of the frame size" for this codec? (We can be  
more specific than the general definition here)

In section 7.3, please include some explanation for the table.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt