Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

["Roni Even" <[e-mail]>]

Hi Richard,

As a general comment, for RTP payload specifications we do not require a
normative reference to the codec. We only require enough information that
will allow an RTP receiver to parse the information and move it to the
decoder that can be a black box. This allows us to publish RTP payload
specification also for codecs whose specifications are not publically
available.

Still in this case more information can be supplied.

 

As for the comments the authors should address them

 

Roni Even

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: [e-mail]
Cc: [e-mail]
Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

 

Overall, this document looks in pretty good shape.  A couple of comments I
would like to get resolved before IETF LC:

 

Section 3.1., "Consult source code for details"

If the details are only specified in the source code, then the source needs
to be a normative reference.  And I would prefer to avoid that  :)  Better
to specify here how the BEI and FL fields are encoded.   Alternatively, if
the codec really does expect a combined BEI/FL field, you could specify such
a field here, opaque to the RTP layer.  However, you would at least need to
say how the recipient knows where this field starts and stops.

 

Section 3.2., "The length of the encoded data is variable and depends on the
signal characteristics and the target bit rate."

However, there's nothing in this section that tells a recipient how to
determine what this length is.  

 

Section 3.3., "... verifying the CRC checksum ..."

Please specify which CRC function is to be applied, and how the CRC value
field is formatted.

 

Section 3.3., "If this value would exceed 255 at encoding..."

It sounds like the LEN field is a single octet unsigned integer.  Please
state that explicitly. 

 

Section 9.2. Informative References.

Better path to source code would be
"webrtc/modules/audio_coding/codecs/isac"

 

Thanks,

--Richard