Subject: Re: CNG

From: [email-masked]
Date: Fri, 5 Nov 1999 09:07:20 -0500

The primary need for a CN or CNG packet is for G711 which has (even for
5ms) a relatively large voice packet.  Therefore, even a relatively large
CN packet would allow a significant data reduction.  This means that, after
the energy info, a large type or version field could be attached allowing
a variety of algorithms, each more complex than the one before, to be
announced without significantly diiminshing the usefulness of the packet
for
data reduction.  It seems to me that this means we don't have to agonize
too much or too long on the issue, just come up with one or two relatively
simple algorithms of a spectral nature that some early adopters can agree
on and start reaping the data reduction benefits.

---

From: Stephen Casner <[email-masked]>
Date: Mon, 8 Nov 1999 19:18:23 -0800 (Pacific Standard Time)

On Fri, 5 Nov 1999 [email-masked] wrote:

> CN packet would allow a significant data reduction.

True.  The main value of VAD is not sending any packets at all, except
perhaps for a comfort noise packet of some kind at the start of
silence and occasionally during the silence.

>  This means that, after
> for data reduction.

Here I don't agree.  Interoperability is a key requirement, and
allowing a plethora of algorithms would most likely impair
interoperability.  For H.323, one would probably need/want to
negotiate compatibility of the comfort noise payload format.
Negotiating the payload type to be used seems like the right way to do
that.  It would be harder to negotiate the embedded version value you
suggest.  If the requirement for negotiation is valid, then there
would be no additional freedom to create new methods via that path
than through dynamic RTP payload type binding to new algorithm
descriptors (in whatever for is used for H.323 negotiation).

							-- Steve