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

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

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