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

[Richard Barnes <[e-mail]>]

Since Real Soon Now has turned into Not Very Soon At All, I'm moving this
one back to Active.  When you guys are ready to get around to it, please
re-request publication.
--Richard


On Thu, Jun 13, 2013 at 8:45 AM, Harald Alvestrand <[e-mail]>wrote:

>  On 05/28/2013 08:34 PM, Richard Barnes wrote:
>
> Dear Authors,
>
>  Any update on these issues?
>
>
> Working on it, but as you know from other discussions, there isn't exactly
> a lack of things to work on at the moment - it dropped off my queue, and
> I'm picking it up again now.
>
> We'll get back to you Real Soon Now.
>
>
>  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
>>
>>
>>
>
>
>
> _______________________________________________
> payload mailing [e-mail]://www.ietf.org/mailman/listinfo/payload
>
>
>