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

[Richard Barnes <[e-mail]>]

Sure. I didn't mean to imply that we need a reference to the codec, in fact
the opposite.  I was looking for this document to tell me how to parse out
the fields I would feed into the black box of the codec.  They describe the
fields, but it seems to me that they need more detail in order for people
to know how to parse them out of the payload.

--Richard


On Mon, Apr 1, 2013 at 2:03 PM, Roni Even <[e-mail]> wrote:

> 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****
>