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

[Richard Barnes <[e-mail]>]

Dear Authors,

Any update on these issues?

Thanks,
--Richard


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

> Hi Richard,****
>
> These fields are not part of the RTP header but part of the iSAC payload
> header and I agree that it will be better to clarify them.****
>
> Roni****
>
> ** **
>
> *From:* Richard Barnes [mailto:[e-mail]]
> *Sent:* 01 April, 2013 9:47 PM
> *To:* Roni Even
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04****
>
> ** **
>
> 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****
>
> ** **
>