Re: [codec] possible issues to track

[Jean-Marc Valin <[e-mail]>]

Michael Knappe wrote:
>> - clarify requirement about bit-exactness
> [MEK] we will need to specify whether our final reference code is fully bit
> exact, or whether some or all elements can be bit compatible. We should also
> specify whether any portions of said algorithms could be 'upgradeable' (e.g.
> Having a stock PLC algorithm that could be replaced with a better PLC in the
> future)

There is already some text addressing that, but it's part of the guidelines
rather than the requirements. I guess it's possible to move it to the
requirements, but I'm undecided as to whether it's a good idea or not.
See section 4 of the guidelines draft: "Requirements Conformance" in
http://tools.ietf.org/html/draft-valin-codec-guidelines-04

It addresses bit-exactness, PLC, future improvements, ... Let me know what
you think.

>> - mention DTMF in requirements
> [MEK] some simple talk-off tests should be done to determine if in-band DTMF
> (and potentially other call progress tones) are carried in-band without
> sufficient degradation as to cause a DTMF detector misread.

Definitely agree here; that was an omission from the current draft. More
precisely, we should probably select a minimum bit-rate after which DTMF
should be handled. I'm not sure we want to mandate that DTMF work down to 6
kb/s, but at 20 kb/s it should definitely work. Where we put the bar is an
open question.

> - multi-channel carriage: not sure if we mentioned this during the WG
> session, but we need to decide if we will support any kind of joint channel
> coding (current consensus so far is to keep all channels separable). We also
> should also reference multi-channel packing within RTP (RFC 3551 sec 4.1).

Well, any codec always has the option of doing independent channels
(provided that the RTP payload format supports it). On top of that, I tend
to think that "joint coding" is a nice-to-have feature -- as long as it
improves the coding efficiency of course.

Cheers,

	Jean-Marc